DO-178C (with EUROCAE ED-12C) is the de facto international standard for the development and certification of software used in airborne systems and equipment. Published in December 2011 as the revision of DO-178B, it provides objectives and activities for planning, development, verification, configuration management, quality assurance, and certification liaison to demonstrate that airborne software satisfies its requirements with an acceptable level of confidence commensurate with its safety impact.
DO-178C is jointly maintained by RTCA (Radio Technical Commission for Aeronautics, United States) and EUROCAE (European Organisation for Civil Aviation Equipment). It is recognized by certification authorities such as FAA (via AC 20-115D) and EASA (via AMC 20-115D) and used worldwide across civil aviation domains and increasingly in other safety-critical sectors.
Key ideas
- Safety-driven assurance levels: Five Software Development Assurance Levels (DAL A–E) based on the contribution of software to potential failure conditions:
- Level A: Catastrophic failure condition
- Level B: Hazardous/Severe-Major failure condition
- Level C: Major failure condition
- Level D: Minor failure condition
- Level E: No safety effect
- Objectives-based, process-focused framework: Defines objectives, activities, and evidence rather than prescriptive methods; applicants show compliance through plans, standards, reviews, analyses, tests, and traceability.
- Lifecycle data and traceability: End-to-end, bidirectional traceability from system requirements to software requirements, design, code, tests, and verification results; controlled lifecycle data as certification evidence.
- Verification rigor proportional to level: Reviews, analyses, requirements-based testing, structural coverage analysis (up to Modified Condition/Decision Coverage for Level A), robustness testing, and independence criteria align with the assigned software level.
- Complementary guidance via supplements: Technology-specific supplements provide accepted means tailored to modern practices without reducing DO-178C objectives.
- Tool qualification: DO-330 defines the qualification of software tools used to develop or verify airborne software when their output is not fully verified in subsequent activities.
DO-178C document family
- DO-178C / ED-12C — Core guidance and objectives for airborne software development and verification
- DO-330 / ED-215 — Software Tool Qualification Considerations (tool qualification levels TQL-1 to TQL-5)
- DO-331 / ED-218 — Model-Based Development and Verification
- DO-332 / ED-217 — Object-Oriented Technology and Related Techniques
- DO-333 / ED-216 — Formal Methods Supplement
- DO-248C / ED-94C — Supporting Information for DO-178C and DO-278A (clarifications and FAQs)
- DO-326A / ED-202A — Airworthiness Security Process Specification
- DO-356A / ED-203A — Airworthiness Security Methods and Considerations
Typical structure and compliance artifacts
- Planning: Plan for Software Aspects of Certification (PSAC), Software Development Plan, Verification Plan, Configuration Management Plan, Software Quality Assurance Plan
- Standards: Requirements, design, and coding standards; verification standards/procedures
- Development and verification: High-level and low-level requirements, software architecture and detailed design, source code, integration, requirements-based tests, robustness tests, structural coverage analysis (statement, decision, MC/DC as applicable)
- Configuration management and quality assurance: Baselines, change control, problem reporting, SQA audits/records, independence of verification activities according to level
- Certification liaison and data: Accomplishment Summary (SAS), compliance matrices, conformance review findings and resolutions, tool qualification data where applicable
Quality Attributes Required or Emphasized
The standard centers on assurance of software used in safety-critical aviation, driving rigorous engineering and evidence. It directly and indirectly affects the following attributes:
Attribute | Relevance in DO-178C |
---|---|
Safety | Core purpose: ensure software does not introduce unacceptable safety risk; assurance level (A–E) derived from system safety assessment governs rigor. |
Reliability | Requirements-based development, verification, and robustness testing reduce software contribution to failures. |
Integrity | Data/control integrity via requirements, design constraints, partitioning assumptions, and verification of interfaces and data coupling/control coupling. |
Traceability | Mandatory bidirectional traceability across requirements, design, code, tests, results, and problem reports. |
Testability | Strong emphasis on verification including requirements-based tests and structural coverage up to MC/DC for Level A. |
Auditability | Defined lifecycle data, reviews, SQA records, and certification artifacts enable authority audits and findings resolution. |
Maintainability | Change control, configuration management, clear standards, and impact analysis preserve assurance after modification. |
Modularity | Architectural decomposition with clear interfaces supports independent verification and containment of changes. |
Robustness | Robustness testing and analyses (including handling of abnormal inputs and conditions) are required to show software resilience. |
Fault Isolation | Assumes and supports partitioning/freedom from interference at the system level (e.g., with ARINC 653/DO-297 contexts) to prevent unintended interactions. |
Compliance | Conformance demonstrated via objectives, plans, standards, checklists, and certification data. |
Reproducibility | Controlled processes and configuration baselines enable repeatable builds and consistent verification results. |
Analysability | Required for systematic reviews, analyses, and structural coverage assessment to understand software behavior and verify objectives. |
Correctness | Central to requirements-based development; verification demonstrates that software correctly implements its requirements. |
Predictability | Deterministic behavior essential for safety-critical systems; timing analysis and worst-case execution time often required. |
Cyber-security | While DO-178C is not a security standard, it coordinates with DO-326A/DO-356A for airworthiness security when threats could affect safety. |
References
Official and Authoritative
- RTCA: DO-178C – Software Considerations in Airborne Systems and Equipment Certification: https://www.rtca.org/product/do-178c-electronic/
- FAA: Aircraft Certification Software and Airborne Electronic Hardware (policy and training resources): https://www.faa.gov/aircraft/air_cert/design_approvals/air_software
- FAA Advisory Circular AC 20-115D: Recognition of RTCA DO-178C
- EUROCAE: ED-12C (European equivalent to DO-178C): https://www.eurocae.net/
- EASA: AMC 20-115D (Acceptable Means of Compliance for DO-178C/ED-12C)
Related Standards and Documents
- ARP4754A — Guidelines for Development of Civil Aircraft and Systems (system-level processes)
- DO-254 / ED-80 — Design Assurance Guidance for Airborne Electronic Hardware
- DO-278A / ED-109A — Software Integrity Assurance Considerations for CNS/ATM Systems (ground systems)
- DO-297 — Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations
- ARINC 653 — Avionics Application Software Standard Interface (partitioning for safety)