# NOVA Mobility Assistive System: Developed and Remotely Controlled with IOPT-Tools
## 4 NOVA Mobility Assistive System
### Development Approach  
To create networks of NWBs and NWCs, it is necessary to develop the NWBs controllers with the required Wi-Fi communication nodes, complemented, or not, by other communication technologies. When considering the selected technologies, all of NWBs using those technologies must have similar network communication nodes (in the NWCP, NWBP, and NWBC modules), regardless of the NWB type, information, and specific behavior (for example: a crosswalk light sign or a pedestrian detection sensor). These communication nodes (their implementation code) can be previously developed and included in a library, to be used in the NWCP, NWBP, and NWBC modules generation. Currently, IOPT-Tools automatically generated code does not include these modules; however, as these are very similar, they can be manually included.  
The DBCs module of each NWB must be developed according to the intended behavior for its infrastructure element, for example, to control a traffic light sign or the speed limit displayed in a variable message road sign. Such signs are safety-critical systems, given that their malfunction can cause road accidents. The behavior of each NWB depends not only on its data, but also on its neighbors' data. This means that each NWB may have a singular behavior. These unbounded number of NWB behaviors, associated with the fact that these NWBs are usually safety-critical systems, justifies the use of model-driven development approaches, supported by model-checking tools (to ensure proper specifications) and automatic code generators (to avoid manual codification errors and accelerate the development). In order to develop DBC modules, it is proposed the model-driven development approach presented in Figure 4, supported by design automation tools (the IOPT-nets and IOPT-Tools are presented in Section 2).  
The development approach proposed in this paper includes the following steps:  
1. specify the DBCs module through a set of IOPT-net models (in the IOPT model editor), which includes the models of the sub-systems that control: * NWCP, NWBP, and NWBC modules; and, * the NWB dynamic behavior, for example, to control the lights of a traffic light sign;
2. simulate the created/updated models in the IOPT simulator tools, and update the created models, if required;
3. using the IOPT model-checking tools: write a set of queries about the models; generate their state-spaces, check the queries result to verify if the models have the desired proprieties; and update the created models, if necessary;
4. using the IOPT to C code generation tool: automatically generate the implementation code, which includes the DBCs module and an HTTP server that supports the remote control and monitoring (implements the RCMSP module); and,
5. during tests: monitor and influence the controllers' execution through the IOPT debugger tool; update the created models, if necessary, and repeat the previous steps.  
Each NWB must have a database to store its own data and data from its neighbors. To allow data storage from fixed, temporary, or even from moving NWBs, the NWBDB module of each NWB  
Figure 4: Development approach using the Input-Output Place-Transition (IOPT) framework.  
should allow the storage of data of \"all\" types of NWBs. This means that all NWBs may have similar NWBDB modules, enabling their replication. IOPT-Tools are not required to develop NWBDB modules; however, in each NWB, the interface between the DBCs module and the NWBDB module should be automatically generated. Currently, this generation is not supported, but it is intended to be.