DO-178C, officially titled Software Considerations in Airborne Systems and Equipment Certification, serves as the foundational standard for aerospace safety. It is the primary standard used by certification authorities like the Federal Aviation Administration (FAA), which regulates civil aviation in the United States, and European Union Aviation Safety Agency (EASA) which does the same in the European Union.
The standard establishes processes that minimise the risk that software failures could compromise aircraft safety. In essence: it mandates rigorous demonstration that the software executes its intended functions precisely, and solely those functions.
So, what are its operational mechanics, its scope of coverage, and the compliance considerations essential for manufacturers?
Designed to be traceable
While DO-178C is the standard used by certification authorities to approve software-based aerospace systems, Software Assurance Levels (SAL) are assigned to software components based on the safety assessment process and hazard analysis, defining the level of criticality applied to each software component.
DO-178C is based on the idea that you cannot ‘test’ quality into a product at the end. Instead, safety must be designed into every step of the development life cycle. It focuses heavily on being traceable, meaning every line of code must be linked back to a specific requirement, and every requirement must be tested.
The rigor of the process depends on how critical the software is to the safety of the flight. This is known as the Design Assurance Levels (DAL) and ranges from level A – catastrophic – to level E – no effect. For example, systems such as flight controls and autopilot are DAL A, braking systems are DAL B, flight management systems are DAL C, maintenance data recorders are DAL D, and in-flight entertainment systems are DAL E.
Replacing DO-178B
DO-178C (released in 2011) replaced the older DO-178B. While the core processes remained similar, “C” added four critical supplements to address modern technology. These are; DO-330: Software Tool Qualification, DO-331: Model-Based Development and Verification, DO-332: Object-Oriented Technology, and DO-333: Formal Methods.
DO-330 governs software tool qualification. Should a tool be employed to automate a process, such as a compiler or a code generator, a defect within that tool carries the potential to introduce an error into the flight software. DO-330 establishes the rigorous process for demonstrating that the tools utilised possess a level of reliability commensurate with the code they generate.
Historically, engineers would document requirements in natural language (such as English) before implementing the corresponding code, typically in C. With the adoption of DO-331, which governs Model-Based Development (MBD), the specification can now be formulated as a visual, mathematical model, utilising tools like Simulink. This model serves as the definitive specification and, in certain instances, is employed to automatically generate the resultant code.
Features in languages such as C++, Ada, and Java, including inheritance, polymorphism, and dynamic memory allocation, present risks within a cockpit environment due to their potential to introduce unpredictable software behavior. DO-332 addresses this by stipulating ‘Local Type Consistency’ rules and stringent requirements governing the usage of these features to ensure the execution path remains deterministic and amenable to testing.
Finally, DO-333 represents the pinnacle of verification standards. Rather than relying solely on testing the code with various inputs to identify failures, this standard employs mathematical logic to formally prove the code’s correctness. While testing can merely demonstrate the existence of defects, formal methods offer a mathematical proof of the absence of certain critical errors, such as a divide-by-zero calculation, within the codebase.
Requirements for certification
Achieving certification under rigorous standards such as DO-178C for airborne software constitutes a comprehensive, document-intensive undertaking. A project is obligated to generate a substantial volume of documentation, which serves as undeniable evidence of compliance with the defined safety objectives. This documentation must span the entirety of the software development lifecycle and encompass several critical domains:
The Plan for Software Aspects of Certification (PSAC) is a foundational document that functions as the project’s contract with the certification authorities. It meticulously details the overall strategy for software development, delineating how the project team intends to interpret and satisfy the DO-178C objectives. Furthermore, it establishes the scope, life cycle processes, standards, and the specific artifacts designated for review.
Then, the requirements documentation phase necessitates the meticulous definition of the software’s intended behavior. This is typically divided into high-level requirements (HLRs) and Low-Level Requirements (LLRs).
HLRs define what the system is required to accomplish from an operational and safety perspective, frequently being derived directly from system requirements. They describe the functional, performance, and safety-critical behaviors of the software. LLRs detail how the software shall be structured and implemented to successfully satisfy the HLRs. They must be directly traceable to the source code and specify the internal design, interfaces, and algorithms.
Next, the verification and validation phase is arguably the most resource-intensive, particularly for the highest level of safety criticality. Verification is crucial to prove the software meets requirements and has no unwanted features. Verification methods in DO-178C include reviews and analysis, which encompasses static analysis of the code, control flow analysis, and data flow analysis. It also includes testing, which involves thorough testing conducted across unit, integration, and system levels, and finally Modified Condition/Decision Coverage (MC/DC) analysis.
MC/DC is a mandatory and highly stringent verification technique for Design Assurance Level A software. It stipulates that every condition within a decision in the code must be demonstrated to independently affect the outcome of that decision. This rigorous coverage requirement provides assurance that every logical path and gate within the code functions correctly and independently, furnishing the highest level of confidence against logic errors, and the effort involved in attaining 100% MC/DC is a principal driver of cost and schedule.
Next, Configuration Management (CM) and Quality Assurance (QA) are essential processes to ensure the integrity and control of the entire development process. Configuration Management is a vital system for maintaining traceability and version control, ensuring that only the exact version of the source code, object code, executable module, requirements, design, and test cases that have been fully tested and verified are approved for operational use (i.e., “flown”), which effectively eliminates the risk of deploying an untested or improperly modified version. Meanwhile, Quality Assurance monitors the entire software life cycle to ensure that all planned processes, standards, and procedures, as stipulated in the PSAC, are correctly and consistently adhered to.
The level of rigor mandated by DAL A (Catastrophic failure condition) is so extreme that the effort, expenditure, and time necessary for the verification of the code, specifically the achievement of MC/DC, frequently surpasses the resources allocated to the initial writing of the code itself. This difference highlights the extremely high bar for proving the software is safe and reliable for the most critical functions on an aircraft.
Why does it matter?
The inherent complexity of contemporary fly by wire aircraft mandates an exceptionally rigorous and structured methodology for software development. This requirement is satisfied by DO-178C. Without this standard, it would be extremely difficult to securely and reliably manage the complex, integrated software that controls essential aircraft functions like flight surfaces, engine thrust, navigation, and surveillance.
DO-178C imposes an unparalleled degree of discipline upon engineering teams throughout the entirety of the software lifecycle. It necessitates a stringent process encompassing planning, development, verification, and configuration management. This comprehensive framework is specifically engineered to eliminate, or at least mitigate to an acceptable level, the risks associated with software anomalies. It ensures that every single line of code is demonstrably traceable to a specific high-level requirement and is subjected to exhaustive testing. This preventative measure stops unexpected code, a hidden dependency, or an undocumented feature from causing a catastrophic system failure or loss of life.
While the precise number of lives saved by DO-178C is immeasurable, its profound impact on aviation safety is incontrovertible. It is globally recognised and accepted by regulatory bodies, including the FAA and EASA, as the international de facto benchmark for certifying the safety and airworthiness of all software employed in civil airborne systems. Its implementation directly prevents potential catastrophic failures in mission critical systems such as primary flight control computers, sophisticated navigation suites, including GPS and Flight Management Systems, and advanced surveillance technology like Traffic alert and Collision Avoidance System. By enforcing this superior level of quality and rigour, DO-178C fundamentally underpins public confidence in the safety of air travel.
With expertise spanning electrical, electronic, software engineering, and business development, Andrew brings a unique, system-level understanding of safety-critical design. This ensures that WHIS solutions are grounded in real-world engineering challenges, giving customers confidence that performance, safety, and precision are built in from the start.
