What is DO-178?

DO-178C, or "Software Considerations in Airborne Systems and Equipment Certification", is a guideline developed by RTCA for ensuring the safety and reliability of software used in airborne systems. It provides a framework for planning, developing, verifying, and certifying software to meet FAA and EASA regulatory requirements. The standard defines five software levels (A to E), based on the severity of potential failure, with Level A requiring the most rigorous assurance processes.

What is the purpose of DO-178C?

DO-178C defines the objectives and processes that software must meet to be certified for use in airborne systems, such as:

Flight control systems
Navigation
Display systems
Communication modules

What are the variants of DO-178?

DO-178C: Current version
DO-178B: Previous version, widely used before 2012
There is not a lot of differences between the B and C versions. The real change that comes with the C version is the companion documents created at the same time. Those supplements include:
- DO-330: Software Tool Qualification Considerations
- DO-331: Model-Based Development and Verification
- DO-332: Object-Oriented Technology and Related Techniques
- DO-333: Formal Methods
A detailed explanation of those companion documents is given below.

What are the differences between DO-178C and DO-178B?

DO-178B and DO-178C are both standards for the development of aviation software, but DO-178C includes several updates and enhancements to reflect advancements in software development technologies and methodologies since the publication of DO-178B. The overall structure of both standards is similar.

Key differences can be found here.

What are the different Software Levels of DO-178C?

The guideline defines five levels of criticality, called DAL or Design Assurance Levels, based on the potential impact of a software failure. :

DAL A: Software failure could lead to a catastrophic failure condition for the aircraft, typically resulting in multiple fatalities. The most stringent level of assurance is required, with extensive verification and validation, including 100% coverage of all structural code coverage metrics like Modified Condition/Decision Coverage (MC/DC).

DAL B: Failure could lead to a hazardous or severe-major failure condition, potentially causing a large reduction in safety margins or serious injury. While still demanding, the verification requirements are slightly less stringent than Level A, but still require high levels of coverage and thorough testing.

DAL C: Failure could lead to a major failure condition, affecting the aircraft's operational capability and possibly leading to discomfort or minor injury to occupants. The requirements include less comprehensive verification activities compared to Levels A and B, but still necessitate significant assurance that the software performs as intended.

DAL D: Failure could lead to a minor failure condition, slightly affecting the aircraft's operational capability without significantly reducing safety. The verification and validation efforts are reduced compared to higher criticality levels but must ensure that the software does not adversely affect aircraft operation or safety.

DAL E: Failure has no effect on aircraft operational capability or safety. The least stringent level, Level E software requires the least amount of verification and validation, primarily to ensure that the software does not impact higher criticality software or aircraft operations.

The determination of the software criticality level is an integral part of the certification process and influences the entire lifecycle of the software development process, from the initial planning stages through to certification by regulatory authorities such as the FAA or EASA. This classification ensures that the level of effort and scrutiny applied to the software is commensurate with the potential safety impact, optimizing resources while ensuring the safety and reliability of airborne software systems.

What is the purpose of DO-330?

DO-330 was developed to provide clear, structured guidance for the qualification of software tools used in the development of airborne systems, resolving past inconsistencies from DO-178B. Originally created as a supplement, it evolved into a standalone document applicable across multiple standards, including DO-178C, DO-278A, DO-200A, DO-254, and ARP4754A. It comprehensively addresses all three tool qualification criteria from DO-178C.

The guidance in DO-330 focuses on planning and executing a tool qualification process, especially when the tool is used to develop or verify airborne software. It introduces Tool Qualification Levels (TQLs) based on the tool's impact and usage, with TQL 5 (lowest) to TQL 1 (highest). Qualification involves defining Tool Operational Requirements (TORs) and verifying them through a Tool Qualification Plan (TQP). Supporting data and criteria are detailed in tool-specific Annex A tables in DO-331.

A key part of DO-330 is its handling of Commercial-Off-The-Shelf (COTS) tools. These are treated differently depending on whether the developer or the user is responsible for meeting objectives. DO-330 provides role-based guidance to support tool qualification, ensuring a flexible but structured path to certifying both custom-built and off-the-shelf tools used in aviation software development.

What is the purpose of DO-331?

DO-331 is a critical supplement guiding Model-Based Development (MBD) and Verification in safety-critical software. It defines a "model" as an abstract representation of system aspects, used for analysis, verification, simulation, or code generation. The supplement addresses MBD's benefits while providing guidance on concerns like system-to-software allocation and direct software implementation. It emphasizes the importance of robust development standards, symbol libraries, and rigorous processes for verification and traceability throughout the MBD lifecycle.

A central focus of DO-331 is the complex challenge of managing model granularity and ensuring comprehensive traceability, especially between high-level (specification) and low-level (design) requirements. To guarantee system integrity and verifiability, it mandates bidirectional traceability: high-level requirements must trace down to system-level requirements, and all system-level requirements must be allocated to software requirements, which in turn must trace back to the originating model. This stringent requirement ensures that every piece of code is explicitly represented by a specification or design model.

Furthermore, DO-331 significantly expands the core elements of verification to integrate modern MBD practices. This includes model coverage analysis, a technique crucial for detecting unintended functions or behaviors within the design model, and simulation, which provides compelling evidence of compliance with specified requirements and assesses the model's accuracy. New objectives related to simulation cases and procedures have been added to provide more detailed guidance and solidify the verification process.

What is the purpose of DO-332?

DO-332 provides essential guidance for the application of Object-Oriented Techniques (OOTs) and related techniques (RTs) within software development, particularly concerning safety-critical systems. OOTs, as defined in this supplement, encompass class and object definition/manipulation, typing and type safety (including the Liskov Substitution Principle), hierarchical encapsulation, polymorphism, and function passing, closure, and dispatch. Related techniques covered include inheritance, parametric polymorphism, type conversion, method-level exception handling, and dynamic memory management.

The supplement delves into the potential pitfalls and vulnerabilities associated with using OOT/RTs. It highlights that the complexities introduced by OOT, such as inheritance creating intricate traceability relationships between requirements and subclasses, can significantly complicate assurance and verification. Specific object-oriented language features like constructors, destructors, in-line checks, and implicit type conversion can also add complexity to object code mapping. Behavior captured in models (e.g., UML) necessitates robust traceability mechanisms, and the supplement emphasizes explicitly addressing these items in traceability planning.

DO-332 places particular emphasis on requirements related to dynamic memory allocation, a complex topic with challenges like ambiguity, fragmentation starvation, deallocation starvation, memory exhaustion, and premature deallocation. It states that successful allocation of sufficient memory for every request must be verified, and calculations of memory usage must be accurate to prevent leakage problems. While verification objectives for OOT aspects are generally modest, two new objectives are introduced at levels A and B: verifying local-type consistency and ensuring robust dynamic memory management. Ultimately, the key to effectively dealing with OOT is a thorough understanding of how it impacts traditional DO-178C topics.

What is the purpose of DO-333?

DO-333 defines and guides the use of Formal Methods (FMs), which are mathematically based techniques for software specification, development, and verification in digital systems. FMs offer unambiguous system descriptions, precise communication, and strong verification evidence, including consistency, accuracy, compliance with properties (e.g., freedom from deadlocks), and analysis of WCET and stack usage.

The application of FMs involves modeling and analysis, built upon a mathematically precise foundation. The supplement clarifies when model analysis constitutes a Formal Method, tying it to model-based development for assurance. FMs can analyze models for correctness, either fully or alongside other verification techniques, and formal analysis methods include deductive methods, model checking, and abstract interpretation.

DO-333 details how FMs integrate with DO-178C objectives, allowing formal analysis to satisfy various verification goals. It enables augmentation of WCET, stack, and state transition analyses. Key for FM verification is focusing on analysis methods, transformations, and crediting formal proof. Four new objectives (FM1-FM9) are introduced, replacing core test objectives and focusing on FM cases, procedure correctness, results accuracy, coverage of both High-Level (HLR) and Low-Level Requirements (LLR), requirement completeness, and detection of unintended dataflow or dead code.