DO-178C is the standard that airborne software must satisfy to be accepted on a type-certified aircraft. If code runs on something that flies with people aboard, a certification authority expects the software to have been developed against DO-178C, and the evidence to prove it. It is, alongside its avionics companions, one of the most demanding software processes in any industry, and it is the aviation counterpart to the domain safety standards other sectors know well.
The heart of DO-178C is the Design Assurance Level, or DAL. Rather than treating all software the same, the standard asks a prior question: if this software fails, how bad is the worst credible outcome? The answer, derived from the system safety assessment, places the software into one of five levels. Level A software is that whose failure could be catastrophic, contributing to the loss of the aircraft. Level B failures are hazardous, Level C major, Level D minor, and Level E software has no effect on safety at all. The DAL is not a badge of quality pride; it is a measured statement of consequence, and everything that follows scales from it.
What scales is the number of objectives the program must satisfy. DO-178C is organized around objectives spanning planning, development, verification, configuration management, and quality assurance. Level A programs must satisfy the full set with independence on many of them; lower levels satisfy progressively fewer. This is the standard being honest about proportionality: the assurance effort should match the risk, and a Level A flight control law is held to a far higher bar than a Level D maintenance display.
Two demands sit at the center of the verification effort and define the daily reality of a DO-178C program. The first is requirements-based testing: verification is driven from the requirements, and every requirement must be shown to be tested. The second is structural coverage analysis, which asks whether the testing actually exercised the code. At the higher levels the coverage bar rises from statement coverage to decision coverage and, at Level A, to Modified Condition/Decision Coverage, or MC/DC, a rigorous criterion that each condition in a decision has been shown to independently affect the outcome. Gaps between requirements, code, and tests are not paperwork nuisances here; they are certification blockers.
All of this rests on traceability. DO-178C expects bidirectional traceability from system requirements to high-level software requirements, down to low-level requirements and design, into source code, and across to the test cases and results that verify each one. When a requirement changes late in a program, the team must be able to identify every downstream artifact affected and re-verify it. Maintained by hand across thousands of requirements and tests, that trace is where avionics programs bleed schedule.
DO-178C does not stand alone. It shares its DNA with the functional safety family that governs other high-consequence domains, and a team that understands one recognizes the others quickly. Its structure mirrors the criticality-scaling logic of IEC 62304 in medical software, ISO 26262 in automotive, and EN 50128 in rail, and it shares the requirements-driven, evidence-heavy discipline common to all of them.
This is precisely the kind of program where methodology-native tooling changes the economics. Hitt Hosting SE maintains the traceability matrix as first-class data, flags downstream artifacts as suspect when a requirement changes, and keeps requirements-to-test coverage visible in real time rather than reconstructed in a spreadsheet before an audit. The certification evidence a DO-178C program has to produce is a byproduct of working this way, not a separate scramble at the end.