DO-178C Traceability

DO-178C is the software assurance standard that airborne systems are certified against. At its core sits one idea that certification authorities test again and again: traceability. Every safety-relevant behavior in the software must be traceable back to a requirement, and every requirement must be traceable forward to the code and tests that implement and verify it. This page explains what that chain looks like, what bidirectional traceability means in practice, how the Design Assurance Levels scale the effort, and where teams most often get into trouble.

If you are certifying avionics software, traceability is not paperwork you produce at the end. It is the connective tissue that lets an auditor follow any requirement to its implementation and back again, and it is one of the first things a Designated Engineering Representative or authority will probe.

DO-178C, titled Software Considerations in Airborne Systems and Equipment Certification, is published by RTCA. Its identical European counterpart is ED-12C, published by EUROCAE. The two documents share the same objectives and content, so a project compliant with one is compliant with the other. Both the FAA in the United States and EASA in Europe recognize DO-178C / ED-12C as the accepted means of compliance for the software of airborne systems.

DO-178C is objective based rather than prescriptive. Instead of dictating a single development process, it defines a set of objectives that the software life cycle must satisfy, and leaves the applicant free to choose how to meet them. The applicant then produces evidence, in the form of life cycle data, that each applicable objective has been achieved. Traceability data is one of the central pieces of that evidence.

For a broader view of certification in this domain, including the hardware counterpart, see our overview of Aerospace & Defense engineering and the companion article Aerospace certifications DO-178C & DO-254.

The rigor DO-178C demands is not the same for all software. It is scaled by the Design Assurance Level (DAL), sometimes called the software level. The DAL is assigned based on the severity of the failure condition that the software could contribute to, as determined by the system safety assessment. There are five levels, from A (the most critical) to E (the least):

The key principle is that the number of applicable objectives, and the degree of independence required to satisfy them, increase with criticality. The highest levels require essentially the full set of objectives; lower levels progressively relax both the count and the independence expectations. A large share of the additional objectives at Levels A and B concern verification and structural coverage, which is exactly where thorough traceability pays off.

DO-178C traceability follows the software as it is refined from an abstract need into executable, verified code. The chain typically runs through these layers:

1. System requirements allocated to software. These come from the system level and define what the software must do.
2. High-level requirements (HLR). The software requirements derived from the system requirements: what the software shall do, without fixing the internal design.
3. Low-level requirements (LLR) and software architecture. The detailed requirements from which source code can be written directly, together with the architecture that organizes them.
4. Source code. The implementation, developed from the low-level requirements.
5. Test cases, procedures and results. The verification evidence that shows the requirements are met, including the results of running the tests and the associated coverage analysis.

Each link in this chain must be documented. A high-level requirement traces down to the low-level requirements that decompose it; each low-level requirement traces to the code that implements it; each requirement traces to the test cases that verify it and to the results of running those tests. Read the other way, every line of code and every test should trace back up to a requirement that justifies its existence.

Bidirectional traceability means the trace links can be followed in both directions, and that both directions are complete:

• Forward (top-down): from each higher-level item to the lower-level items that satisfy it. This demonstrates that every requirement is implemented and verified. If a requirement has no downward trace, it has not been realized.
• Backward (bottom-up): from each lower-level item to the higher-level item that justifies it. This demonstrates that nothing unintended was added. If code or a test has no upward trace, it may be unintended function (often called dead or extraneous code or requirements), which is a finding in itself.

Bidirectionality matters because the two directions catch different problems. Forward traceability catches omissions: requirements that were never implemented or never tested. Backward traceability catches additions: behavior that exists in the code but was never called for by any requirement. Both are safety concerns in an airborne system, and DO-178C explicitly expects the trace data to support analysis in both directions. When a requirement changes, complete bidirectional links are also what make impact analysis tractable: you can see immediately which design elements, code units and tests are affected.

Traceability is verified, not just declared. DO-178C verification combines reviews, analyses and testing, and traceability underpins all three.

• Reviews of the high-level and low-level requirements confirm, among other properties, that they trace correctly to their parent items.
• Reviews of the source code confirm that it traces to and is consistent with the low-level requirements.
• Requirements-based testing confirms that the software meets its requirements; the trace from requirements to test cases shows that the test set is complete.
• Structural coverage analysis (statement, decision, and at Level A Modified Condition/Decision Coverage) is performed on the results of requirements-based tests. Coverage that is not exercised may point to shortcomings in the requirements, in the tests, or to unintended code, closing the loop back to traceability.

The higher the DAL, the more of this verification must be performed with independence, meaning by someone other than the author of the item being verified.

DO-178C is accompanied by four technology supplements. They do not replace the core standard; they explain how its objectives apply when a particular technique is used, and they carry their own traceability expectations.

• DO-330, Software Tool Qualification Considerations. When a tool automates, replaces or reduces a DO-178C process (for example a tool that generates code or that performs verification), the tool itself may need to be qualified. DO-330 defines how, with a rigor that depends on the tool's impact.
• DO-331, Model-Based Development and Verification. Addresses how objectives apply when models are used as requirements or design, and how traceability extends to and from those models.
• DO-332, Object-Oriented Technology and Related Techniques. Addresses the specific verification concerns of object-oriented and related techniques, such as inheritance and dynamic dispatch.
• DO-333, Formal Methods. Explains how formal methods (mathematically based specification and verification) can be used to satisfy verification objectives, including where a proof can substitute for testing.

Whichever supplements apply, the underlying traceability obligation does not go away: models, generated artifacts and formal specifications all still need to trace to and from the surrounding life cycle data.

Many teams begin tracing DO-178C artifacts in word-processor documents and spreadsheets, and many discover late in the program that this does not scale. The recurring problems are:

• Stale links. A requirement is edited or renumbered, and the trace references pointing at it are not updated. The matrix still looks complete but points at the wrong version.
• One-directional coverage. Forward links are maintained but backward links are neglected, so unintended code and orphan tests go unnoticed until an audit.
• No change impact. When a high-level requirement changes, there is no automatic way to see every downstream low-level requirement, code unit and test affected, so the reverification scope is guessed rather than known.
• Version skew across files. Requirements, design, code and test data live in separate files under separate revisions, and keeping the trace consistent across all of them becomes a manual, error-prone reconciliation.
• Evidence assembled at the end. Traceability is reconstructed for the certification package rather than maintained continuously, which is exactly when gaps and inconsistencies surface with the least time to fix them.

The alternative is to hold requirements, design, code references and test artifacts as linked items in a single connected model, so that a trace link is a live relationship rather than a copied identifier. Bidirectional queries and change impact then come for free, and the certification evidence is a report generated from the model rather than a document assembled by hand.