systems engineering//functional safety//DO-178C

DO-178C is the standard under which airborne software is developed and certified, published by RTCA in 2011 (with EUROCAE as ED-12C) as the successor of DO-178B, and accepted by aviation authorities as the means of showing that flight software is fit to fly. It is used by every team writing avionics, from a flight control computer to an engine controller, and increasingly by drone makers seeking certification for flight over people. Its central idea is a **design assurance level** (DAL) assigned to each piece of software according to the worst effect its failure could have on the aircraft: A for catastrophic, B hazardous, C major, D minor, E no safety effect.

DO-178C is the standard under which airborne software is developed and certified, published by RTCA in 2011 (with EUROCAE as ED-12C) as the successor of DO-178B, and accepted by aviation authorities as the means of showing that flight software is fit to fly. It is used by every team writing avionics, from a flight control computer to an engine controller, and increasingly by drone makers seeking certification for flight over people. Its central idea is a design assurance level (DAL) assigned to each piece of software according to the worst effect its failure could have on the aircraft: A for catastrophic, B hazardous, C major, D minor, E no safety effect.

The level decides how many objectives must be met and how independently. At every level the core is traceability: high-level requirements trace to low-level requirements, those to source code, and every requirement to the tests that verify it, with no code that traces to nothing. What rises with the level is the rigour of review and the depth of structural coverage the tests must reach.

At level A the tests must achieve MC/DC coverage, modified condition/decision coverage: every condition inside every decision must be shown to independently change that decision's outcome. A branch if (a && b) needs tests where flipping only a, and then only b, flips the result. It catches logic that ordinary branch coverage passes by, and it is a large part of why level A testing costs far more than commercial practice.

The standard certifies a process and its evidence rather than a product's measured failure rate, because software has no random failures to count: its faults are design faults, present from the start. Level C asks for statement coverage, level B for decision coverage, level A for MC/DC.

Supplements cover what the core document leaves open: model-based development, object-oriented technology, formal methods and the qualification of tools whose output is not verified separately (a code generator, a static analyser), so that a tool can carry part of the evidence.

It fits the V-model closely, and inherits its weakness with learned components: a neural network has no requirement-to-code trace, so machine learning in avionics is approached through separate guidance and through architectures where a verified monitor bounds what the learned part can do.

Among the functional safety standards it is the aviation counterpart of ISO 26262 for cars and IEC 61508 for industry; hardware in airborne electronics has its own companion standard, DO-254.

For an engineer outside aviation, the transferable parts are its traceability discipline and its insistence that the level of evidence follow the severity of failure.