Transitioning to DO-178C and ARP4754A for UAV software development using model-based design

Story

July 27, 2012

Few applications place more importance on verification, or prescribe more process guidance, than aviation. The FAA and its European equivalent, EASA, provide guidance using standards such as ARP4754 for aircraft systems and DO-178B for flight software. These standards are often used outside of civil aviation, in whole or in part, for applications including military aircraft and land vehicles. Adoption for UAV programs is rapidly growing because of the FAA’s recent decision to require UAS and OPA certification via FAA Order 8130.34A. UAV systems are heterogeneous, and not restricted just to flight software. Therefore, other standards are used such as DO-254 for hardware and DO-278 for ground and space software.

However, these standards are more than a decade old and are showing their age. For example, they lacked guidance on modern development and verification practices such as model-based design, object-oriented technologies, and formal methods, at least until the nascent DO-178C standard was developed. So the FAA and EASA have worked with aircraft manufacturers, suppliers, and tool vendors to update standards based on modern technologies (Table 1). Rather than significantly modify the standards, they created technology supplement documents.

The impact of the new standards to UAV developers using model-based design is especially significant. Before describing this, an introduction to model-based design is appropriate.

 

Table 1

(Click graphic to zoom by 1.9x)

 

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.

 

Figure 1: Example system model used for UAVs with controller and plant

(Click graphic to zoom by 1.9x)

 

 

Figure 2: Example software model used for UAV control laws

(Click graphic to zoom by 1.9x)

 

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.

An in-the-loop testing strategy is often used as itemized below and summarized in Table 2:

1. Simulation test cases are derived and run on the model using Model-In-the-Loop (MIL) testing.

2. Source code is verified by compiling and executing it on a host computer using Software-In-the-Loop (SIL) testing.

3. Executable object code is verified by cross-compiling and executing it on the embedded processor or an instruction set simulator using Processor-In-the-Loop (PIL) testing.

4. Hardware implementation is verified by synthesizing HDL and executing it on an FPGA using FPGA-In-the-Loop (FIL) testing.

5. The embedded system is verified and validated using the original plant model using Hardware-In-the-Loop (HIL) testing.

 

Table 2

(Click graphic to zoom by 1.9x)

 

A requirements-based test approach with test reuse for models and code is explicitly described in ARP4754A, DO-178C, and DO-331, the model-based design supplement to DO-178C.

Transitioning to new standards using model-based design

ARP4754A

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

When using model-based design with ARP4754A and DO-178C, additional verification capabilities are often needed beyond in-the-loop testing described in Table 2. These including requirement tracing, model standard checking, model-to-code structural equivalence checking, and robustness analysis using formal methods. For UAVs, rigorous verification that includes multiple verification technologies is paramount given their autonomous nature and system complexity.

DO-178C

Not surprisingly, one of the first changes new in DO-178C is an explicit mention of ARP4754A in Section 2: System life-cycle processes can be found in other industry documents (for example, SAE ARP4754A).

Clarification updates aside, such as the one noted earlier, DO-178C does not differ significantly from DO-178B, at least at first glance. In fact, a casual reader might miss an item mentioned in Section 1.4: How to Use this Document: One or more supplements to this document exist and extend the guidance in this document to a specific technique… if a supplement exists for a specific technique, the supplement should be used …

In other words, the standard’s big changes are captured in the supplemental documents, such as RTCA DO-331, Model-Based Development and Verification Supplement to DO-178C and DO-278A.

Pertinent to this discussion, a long-standing issue with DO-178B for practitioners of model-based design is the uncertainty in mapping DO-178B objectives to model-based design artifacts. Addressing this mapping was a main goal of the DO-178C Sub-Group (SG-4) focused on model-based design. No single mapping sufficed, so several mappings are provided in DO-331. Some include the concept of a Specification model, which is a model separate from that of the one used for design and code generation. The other concept is a Design model, which serves as the detailed requirements used to generate code.

The essence of a Design model is the following:

1. A model can be used for design (system and/or software) and should be developed using requirements external to the model (for example, a textual document or requirements database).

2. Source code can be generated directly from the design model (by hand or automatically).

Of course, with 125 pages, DO-331 has a lot more to offer than described here. One approach noted in the standard is that a model used initially for system design can be elaborated on and reused for software design and code generation. This ties ARP 4754A and DO-178C together quite nicely for UAV system and software developers using model-based design.

For example, the controller shown as a component in the system model in Figure 1 and by itself as a software model in Figure 2 is:

• Used during system design
• Reused as an entry point for software design
• Elaborated on during detailed software design (for example, by discretizing continuous time blocks and changing double-precision data to single-precision or fixed-point)
• Used as input for embedded code generation

The test cases for system requirement validation likewise are reused on the model, source code, and executable object code to perform functional testing and collect coverage metrics.

While not advocating for any particular mapping, the use and reuse of models for systems and software design along with code generation have long provided UAV system developers using MathWorks products of Simulink and Embedded Coder with streamlined processes. It is nice to see that this same approach is now clearly acknowledged as an acceptable means to certification by the governing standards. MathWorks provides verification tool qualification kits and workflow guidance regarding the use of model-based design for DO-178.

Tom Erkkinen is the Embedded Application and Certification Manager at MathWorks. He is leading a corporate initiative to foster industry adoption of code generation technologies. His team participated in the DO-178C SG-4 working group focused on model-based design. Contact him at [email protected].

MathWorks 248-596-7943 www.mathworks.com/aerospace-defense/standards/do-178c.html