DO-178B

DO-178B, titled Software Considerations in Airborne Systems and Equipment Certification, is the RTCA standard that governed civil aviation software certification from 1982 until its supersession by DO-178C in 2011. It defines five levels of software criticality — from Level E (no safety effect) to Level A (catastrophic failure) — and prescribes objectives for software planning, development, verification, and configuration management that must be satisfied before an aircraft can receive type certification. For decades, DO-178B was the de facto global standard for aviation software, influencing not only the Federal Aviation Administration (FAA) and European Union Aviation Safety Agency (EASA) but also military standards and, indirectly, the safety culture of other high-integrity industries.

The Structure of Assurance

DO-178B's core innovation was not technical but organizational: it transformed software certification from an activity performed at the end of development into a property that must be demonstrated across the entire lifecycle. The standard requires traceability from system requirements to software requirements to source code to object code to test cases. Every line of code must be justified by a requirement; every requirement must be verified by a test; every test must be documented. This traceability discipline was radical in an era when most software was written, tested, and shipped without formal verification.

The five criticality levels impose progressively stricter objectives. Level A software — flight control systems, engine control, landing gear — must satisfy 66 objectives including structural coverage analysis (statement, decision, and modified condition/decision coverage, known as MC/DC), data coupling analysis, and formal verification of requirements. Level E software — passenger entertainment systems — satisfies only a handful. The standard does not mandate specific languages, tools, or methodologies. It mandates evidence. The certifying authority does not verify the software; it verifies that the developer has verified the software, and that the verification is documented, repeatable, and complete.

Limitations and the Path to DO-178C

DO-178B's silence on specific technologies became a liability as software grew more complex. The standard was written for sequential programs on single processors. It did not address model-based development, object-oriented programming, formal methods, or multi-core processors. When Airbus developed the A380 using model-based design and auto-generated code, certifiers had to invent interpretive guidance that DO-178B itself did not provide. When the Boeing 787 introduced multi-core flight computers, the standard had no framework for analyzing partition independence or interference channels between cores.

These gaps motivated DO-178C, which retains DO-178B's core structure but adds technology supplements for model-based development (DO-331), object-oriented software (DO-332), formal methods (DO-333), and multi-core processors. The formal methods supplement is particularly significant: it permits the substitution of mathematical proof for some testing objectives, enabling technologies like SPARK and the Alt-Ergo prover to satisfy certification requirements through verification rather than exhaustive test execution. The Airbus A350 was among the first programs to exploit this path, using SPARK for flight control software and achieving Level A certification with a substantially reduced testing burden.

Influence Beyond Aviation

DO-178B's influence extends far beyond aircraft. The standard shaped IEC 61508, the generic functional safety standard for industrial systems, and its automotive derivative ISO 26262. It informed the safety case methodology used in nuclear power plant control systems and railway signaling. It established the principle — now taken for granted in safety-critical engineering — that software assurance is a matter of process discipline and evidence, not merely of code quality.

But the standard also entrenched a particular epistemology of software correctness: that confidence comes from exhaustive testing of every path through the code. This epistemology, while effective for small, sequential programs, struggles with systems whose complexity emerges from interaction rather than from individual component behavior. A formally verified component in a multi-core environment may still fail due to cache interference, timing anomalies, or emergent deadlock — phenomena that DO-178B's coverage-based verification does not capture. The shift toward formal methods in DO-178C represents a recognition that testing alone cannot assure the properties that matter most in modern systems.

The transition from DO-178B to DO-178C is often framed as a technical update — new supplements for new technologies. This framing misses the deeper shift. DO-178B encoded an empiricist epistemology: we know software is correct because we have tested it exhaustively. DO-178C encodes a rationalist epistemology: we know software is correct because we have proved it mathematically. The former assumes that correctness is a property of individual execution paths. The latter assumes that correctness is a property of the program's logical structure. The aviation industry is moving from one to the other not because testing has failed, but because the systems have grown too complex for testing to succeed. This is not a minor regulatory revision. It is a change in what we believe knowledge of software to be.