What is DO-178B?
DO-178B, officially RTCA DO-178B / EUROCAE ED-12B and titled Software Considerations in Airborne Systems and Equipment Certification, is a software certification standard for airborne systems on commercial aircraft. Published in December 1992 (and revised as DO-178C in December 2011), DO-178B contains guidance for the planning, development, and verification of airborne software. The guidance comprises several elements:
- A series of objectives keyed to the various software life cycle processes,
- The specified activities for accomplishing these objectives, and
- The required artifacts (life cycle data) that serve as evidence that the objectives have been met.
The intent behind DO-178B is to achieve a degree of confidence in a software component proportional to the component’s criticality, i.e., the impact of a software anomaly on the continued safe operation of the aircraft. Criticality is reflected in the component’s software level:
Level | Failure Condition | Effect of Anomaly | Example |
A | Catastrophic | Prevent Continued safe flight and landing | Fly-by-wire |
B | Hazardous/Severe-Majore | Serious or potentially fatal injuries to a small number of occupants | Fuel management |
C | Major | Discomfort to occupants, possibly including injuries | Pilot/ATC communication |
D | Minor | Some inconvenience to occupants | Flight data recorder |
E | (Not relevant) | No effect on aircraft operational capability or pilot workload | Entertainment system |
The number of objectives, and the rigor required for showing that they have been satisfied, depend on the software level. For example, at Level A there are 66 objectives to be achieved. Different system components may be at different software levels, provided that absence of interference can be demonstrated.
DO-178B identifies a number of software life cycle processes, with associated objectives, activities, and life cycle data:
- Software Planning Process
- Integral Processes
- Software Verification
- Software Configuration Management
- Software Quality Assurance
- Certification Liaison
- Software Development Processes
- Software Requirements
- Software Design
- Software Coding
- Integration
A major emphasis of DO-178B is on software verification, which consists of reviews, analyses, and tests. Testing needs to be based on the software requirements, and coverage must be demonstrated in multiple senses:
- All requirements must be covered (i.e., for each requirement there must be some test that checks that the requirement is met), and
- The requirements-based tests must completely cover the source code structure (i.e., there can be no “dead” code that is present but does not correspond to a requirement)
DO-178B places different demands on structural coverage based on the software level. For Level C, only statement coverage needs to be shown. For Level B, both statement and decision coverage need to be shown. (Decision coverage implies, among other things, that Boolean expressions need to be exercised with tests for both True and False outcomes.) Level A further requires Modified Condition/Decision Coverage (MC/DC), which entails additional tests for subexpressions of Boolean expressions.
Supplementing its guidance keyed to the various software life cycle processes, DO-178B includes “Additional Considerations” for several topics:
- The use of previously developed software,
- The requirements for qualifying a tool, when DO-178B processes are “eliminated, reduced or automated … without [the tool’s] output being verified” as otherwise specified in the document
- The use of alternative methods to satisfy DO-178B objectives, for example formal methods
DO-178B is more of a correctness standard than a safety standard; i.e., it is focused on demonstrating that the software meets its requirements as opposed to satisfying specific safety properties. The safety analysis is performed as part of the system life cycle processes, for example following SAE Aerospace Recommended Practice standards ARP 4754A and ARP 4761. These processes determine the software level and any safety requirements allocated to software, which then serve as input to the software life cycle processes defined in DO-178B.
DO-178B is not really specific to aviation and could, in principle, be applied to other high-integrity domains. The document does not dictate any particular development process or approach to hazard assessment. DO-178B also says very little about programming languages, but objectives such as source code accuracy and consistency are best met by languages such as Ada with strong data typing and other features amenable to static analysis / early error detection.
A variety of additional official material relates to DO-178B:
- RTCA DO-248B / EUROCAE ED-94B, Final Report for Clarification of DO-178B/ED-12B, comprising a list of errata, a FAQ section, and several discussion papers
- Certification Authority Software Team (CAST) Papers, offering detailed discussions of various subjects treated in DO-178B