What is DO-178C?
RTCA DO-178C / EUROCAE ED-12C is an update to the DO-178B/ED-12B standard that governs the certification of software for airborne systems in commercial aircraft. The revision made relatively modest changes to the “core” guidance, but produced four significant new documents:
- Software Tool Qualification Considerations (RTCA DO-330 / EUROCAE ED-215)
- “Overriding supplements” for specialized development methods
- Model-Based Development and Verification (RTCA DO-331 / EUROCAE ED-218)
- Object-Oriented Technology and Related Techniques (RTCA DO-332 / EUROCAE ED-217)
- Formal Methods (RTCA DO-333 / EUROCAE ED-216)
The resulting standards, published in December 2011, preserve the original DO-178B intent of providing an objectives-based approach to obtaining “a level in confidence in safety that complies with airworthiness requirements”, and extend the guidance to account for major technological advances that have taken root since the publication of DO-178B in the early 1990s.
Changes to DO-178B
The revision effort began in late 2004 under the auspices of a joint committee – RTCA Special Committee #205 (SC-205) and EUROCAE Working Group #71 (WG-71) – and had several goals, including the following:
- To correct errors and clarify confusing content in DO-178B
- To accommodate software technologies and standards that had matured and come into practice since the publication of DO-178B
- To take into account the supplementary material supporting DO-178B, including Certification Authorities Software Team (CAST) papers and Issues Papers (IPs)
Although there was some initial discussion to change the nature of the document to be more “product” versus “process” based”, by requiring safety case analyses, the consensus decision was to keep the changes to the minimum that were necessary, and to not make certification more difficult or less difficult than with DO-178B. The DO-178B standard has been successful in practice, and radical changes in direction were not considered necessary or appropriate.
The modifications to the “core guidance” are relatively minor. A detailed discussion may be found in Frédéric Pothon’s paper DO-178C/ED-12C versus DO-178B/ED-12B: Changes and Improvements << http://www.adacore.com/uploads/technical-papers/DO178C-ED12C-Changes_and_Improvements-Sep2012.pdf>>. Sample updates include:
- An expanded treatment of the information flow between system and software life cycle processes
- A new verification objective at Level A when the object code is not traceable to the source code
- A new variety of MC/DC (“masking” MC/DC), which can account for strongly coupled conditions
Tool Qualification
A major product of the DO-178C effort is a new document, Software Tool Qualification Considerations (DO-330/ED-215). This is not strictly a supplement, since it is domain independent and can be used in conjunction with other high-integrity standards besides DO-178C. The DO-178B concepts of verification tool and development tool have been replaced by three tool qualification criteria:
|
DO-178B Concepts | DO-178C / DO-330 Criteria | |
| Development tool | Criterion 1 | Output is part of airborne software Tool could insert an error |
|
Verification tool
| Criterion 2 | Tool could fail to detect an error and is used to reduce other development or verification activities |
| Criterion 3 | Tool could fail to detect an error | |
Criterion 2 is new and corresponds to a situation such as using a static analysis tool for source code review (for example to demonstrate the absence of recursion) and then using those results to justify the removal of stack checks in the compiled code.
DO-178C defines five Tool Qualification Levels (TQLs) based on the software level and the tool criterion:
|
Tool Qualification Level Determination | |||
| Software Level | Criterion | ||
| 1 | 2 | 3 | |
| A |
TQL-1
| TQL-4 | TQL-5 |
| B | TQL-2 | TQL-4 | TQL-5 |
| C | TQL-3 | TQL-5 | TQL-5 |
| D | TQL-4 | TQL-5 | TQL-5 |
DO-330 defines the specific guidance for each TQL, using the same structure as DO-178C. The tool user must provide qualification artifacts, including material supplied by the tool developer (in particular the Tool Operational Requirements, which documents the operational environment, expected functional behavior, and other aspects). The qualification activities for TQL-1 through TQL-4 are roughly equivalent to the certification activities for Levels A through D, respectively. TQL-5 corresponds to a verification tool under DO-178B.
Technology Supplements
Since the publication of DO-178B in 1992, a number of software engineering methodologies have matured and offer benefits (and also raise issues) for developers of airborne systems. A major part of the DO-178C effort was devoted to analyzing the issues surrounding three specific technologies and preparing supplements that adapt and extend the core DO-178C guidance as appropriate. A particular focus in these supplements is on the verification process.
- Model-Based Development and Verification (RTCA DO-331 / EUROCAE ED-218)
In model-based development, a system’s requirements, design architecture, and/or behavior are specified with a precise (and typically graphical) modeling language, processed by tools that automatically generate code and in some instances also test cases. Using a qualified modeling tool offers a number of advantages, including a shortened/simplified life cycle and a precise (and understandable) specification of requirements. However, model-based development also introduces a number of challenges, such as the merging of system and software life cycle processes, more complicated traceability, and the question of what coverage analysis means in the context of model-based development. The guidance in DO-331 addresses these issues.
- Object-Oriented Technology and Related Techniques (RTCA DO-332 / EUROCAE ED-217)
Object Orientation – a design approach in which a system’s architecture is based on the kinds of entities that the system deals with, and their relationships – has been a mainstay in software development for several decades since it can ease the task of extending a system when new requirements need to be met. However, the programming features that give Object Oriented Technology (OOT) its expressive power – inheritance, polymorphism, and dynamic binding – raise a number of significant technical issues. In brief, the dynamic flexibility provided by OOT is in conflict with the DO-178B and DO-178C requirements to statically demonstrate critical program properties; the guidance in DO-332 addresses this issue and others. A noteworthy feature of DO-332 is its introduction of a new verification objective for type substitutability, reflecting the advantages of using inheritance solely for type specialization.
- Formal Methods (RTCA DO-333 / EUROCAE ED-216)
With the advances in proof technology and hardware speed, the use of formal (i.e., mathematically based) methods in software verification has moved from the research labs into more widespread practice, especially at the higher levels of safety and security criticality. Formal methods can be used to prove program properties ranging from a demonstration that run-time errors will not occur, to a proof that a module’s implementation complies with its formally specified requirements.
Formal methods were identified in DO-178B as an alternative means of compliance, but there was no common understanding of how they would fit in with the other objectives. DO-333 addresses this issue and indicates how formal methods can complement or replace other verification activities, most notably certain types of requirements-based testing.
For Further Information
L. Rierson. Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance. CRC Press, 2013
F. Pothon. DO-178C/ED-12C versus DO-178B/ED-12B: Changes and Improvements.www.adacore.com/uploads/technical-papers/DO178C-ED12C-Changes_and_Improvements-Sep2012.pdf
AdaCore. High-Integrity Object-Oriented Programming in Ada; June 2013.