Introduction to model-based design
With model-based design, UAV engineers develop and simulate system models comprised of hardware and software using block diagrams and state charts, as shown in Figures 1 and 2. They then automatically generate, deploy, and verify code on their embedded systems. With textual computation languages and block diagram model tools, one can generate code in C, C++, Verilog, and VHDL languages, enabling implementation on MCU, DSP[], FPGA[], and ASIC hardware. This lets system, software, and hardware engineers collaborate using the same tools and environment to develop, implement, and verify systems. Given their auto-nomous nature, UAV systems heavily employ closed-loop controls, making system modeling and closed-loop simulation, as shown in Figures 1 and 2, a natural fit.
Testing actual UAV systems via ground-controlled flight tests is expensive. A better way is to test early in the design process using desktop simulation and lab test benches. With model-based design, verification starts as soon as models are created and simulated for the first time. Tests cases based on high-level requirements formalize simulation testing. A common verification workflow is to reuse the simulation tests throughout model-based design as the model transitions from system model to software model to source code to executable object code using code generators and cross-compilers.
Transitioning to new standards using model-based design
ARP4754A addresses the complete aircraft development cycle from requirements to integration through verification for three levels of abstraction: aircraft, systems, and item. An item is defined as a hardware or software element having bounded and well defined interfaces. According to the standard, aircraft requirements are allocated to system requirements, which are then allocated to item requirements.
The fact that ARP4754A addresses allocation of system requirements to hardware and software components is significant to UAV developers, especially suppliers. Some suppliers might have claimed that UAV subsystem development was beyond the scope of the original ARP4754, even for complex subsystems containing hardware and software, but not anymore. ARP4754A also more clearly refers to DO-178 and DO-254 for item design. In fact, the introductory notes for ARP4754A acknowledge that its working groups coordinated with RTCA special committees to ensure that the terminology and approach being used are consistent with those being developed for the DO-178B update [DO-178C].
Given the high coupling among systems, hardware, and software for UAVs, it is helpful that the governing standards now clarify relationships between systems and hardware/software subsystems.
ARP4754A recommends the use of modeling and simulation for several process-integral activities involving requirements capture and requirements validation.
ARP4754A Table 6 recommends (R) analysis, modeling and simulation (tests) for validating requirements at the highest Development Assurance Levels (A and B). For Level C, modeling is listed as one of several recommendations. While ARP4754 made similar recommendations, ARP4754A provides more insight and states that a representative environment model, such as the plant model shown in Figure 1, is an essential part of a system model.
Also noted in ARP4754A is that a graphical representation or model can be used to capture system requirements. The standard now notes that a model can be reused for software and hardware design.
If engineers use models to capture requirements, ARP4754A recommends engineers consider the following:
1. Identify the use of models/modeling
2. Identify the intended tools and their usage during development
3. Define modeling standards and libraries
refer to:
http://mil-embedded.com/articles/transitioning-do-178c-arp4754a-uav-using-model-based-design/
