With the FAA and EASA adopting aviation standards such as DO-178C and ARP4754A,
UAV software developers should familiarize themselves with these standards,
particularly when transitioning to model-based design.
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.
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.
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.
refer to:
http://mil-embedded.com/articles/transitioning-do-178c-arp4754a-uav-using-model-based-design/
_reg.jpg)
