What Is DO-178C? A Guide to Airborne Software Certification

A flight control computer fails in a way nobody tested for, and the investigation traces the fault back to a low-level requirement that engineers implemented but never verified against a test case. 

For teams developing airborne software, DO-178C translates that safety concern into software assurance objectives, and Design Assurance Levels (DALs) scale that rigor to the safety risk so that certification evidence matches the potential failure effect.

This guide covers what DO-178C requires, how DAL assignments set verification rigor, the traceability backbone auditors expect, and where certification programs most often run into trouble.

What Is DO-178C?

DO-178C is the primary guidance for showing that airborne software satisfies its requirements with confidence proportional to its safety impact. 

It is also an acceptable means of compliance for the software aspects of airborne systems in type certification, under Federal Aviation Administration (FAA) Advisory Circular (AC) 20-115D. The combined DO-178C/ED-12C document is published by the Radio Technical Commission for Aeronautics (RTCA) with the European Organization for Civil Aviation Equipment (EUROCAE).

History and Evolution of DO-178

The standard has moved from prescriptive process rules toward objective-based assurance. DO-178B defined objectives, renamed software levels A through E, and introduced bidirectional traceability, requirements-based testing, and tool qualification.

DO-178C kept broad compatibility with DO-178B while clarifying expectations around Modified Condition/Decision Coverage (MC/DC), low-level requirements, and trace data as lifecycle evidence. The shorthand “DO-178B/C” still appears when a requirement, artifact, or process applies under either version.

DO-178C Supplements and Related Standards

The main supplements published alongside DO-178C extend the core guidance to specific techniques. Each supplement describes a technology, defines its scope within airborne software, and lists the added or alternative objectives that apply when teams use that technology:

• DO-330 software tool qualification: A domain-independent document that provides an acceptable tool qualification process. DO-254, DO-200, and International Organization for Standardization (ISO) 26262 can use the same process beyond aviation.
• DO-331 model-based development and verification: Guidance for using model-based development tools while avoiding pitfalls inherent in some modeling methods.
• DO-332 object-oriented technology: Additional objectives for design, implementation, and verification when using object-oriented programming. These objectives address dynamic memory allocation, as well as inheritance and polymorphism.
• DO-333 formal methods: Criteria for theorem provers and model checkers, as well as abstract interpretation tools used to verify complex systems.

RTCA and EUROCAE also released DO-248C as supporting information rather than a technical supplement. We confirm which supplements apply to planning documents, since none of them function as stand-alone documents.

DO-178C and ISO 26262

DO-178C applies to aerospace software assurance, while ISO 26262 applies to electrical and electronic systems in road vehicles. DO-178C assigns DALs based on the severity of failure effects, while ISO 26262 assigns Automotive Safety Integrity Levels (ASILs) based on severity, exposure, and controllability.

No normative cross-walk maps a DAL to an ASIL, and a component certified at one level cannot be claimed as equivalent at another without separate evidence. The standards share concepts such as requirements-based testing, structural coverage analysis, traceability, static analysis, and tool qualification, but their artifacts, terminology, and authorities remain distinct.

Design Assurance Levels (DAL A Through E)

The Design Assurance Level (DAL) determines which DO-178C objectives apply to a given piece of software. The DAL comes from the system safety assessment process under ARP 4761 and ARP 4754A, not from the software itself, and DO-178C then maps each level to a specific set of objectives.

A component’s failure effect severity sets the DAL and the required rigor. A catastrophic failure condition requires the most stringent level, while software with no safety effect carries no objectives at all.

Attribute	DAL A	DAL B	DAL C	DAL D	DAL E
Failure Condition	Catastrophic	Hazardous	Major	Minor	No Safety Effect
Relative Objective Burden	Highest	High	Moderate	Low	None
Independence Expectations	Highest	High	Limited	Minimal	None

What Independence Means

When teams assign verification with independence, someone other than the artifact’s author reviews it. When an objective must be satisfied with independence, the engineer reviewing a requirement or source code cannot be the one who wrote it, and the team must document that separation. At DAL A and DAL B, a dedicated reviewer typically breaks that author-reviewer link rather than a second pass by the same person.

Structural Coverage by Level

Coverage expectations tighten sharply as the DAL increases, moving from no requirement at DAL E to full structural coverage at DAL A. Level A requires statement, decision, and MC/DC coverage at 100 percent. Level B requires statement and decision coverage, Level C requires statement coverage only, and Levels D and E require none. MC/DC requires each condition within a decision to independently affect the outcome. That added rigor can make coverage work costly when teams find complex logic, object-oriented code, or code paths that lack clear requirement traceability.

Core Processes in DO-178C

DO-178C is objective-oriented, tying objectives to software life cycle processes rather than exact methods. Every process needs well-defined entry and exit criteria, with documentation showing how the project met them. Planning data covers the Plan for Software Aspects of Certification (PSAC) and the supporting development, verification, configuration management, and quality assurance plans.

Development and Integral Processes

Development processes produce software through requirements, design, coding, and integration, while integral processes run alongside development to build confidence in the outputs, including verification, configuration management, and quality assurance.

Verification demonstrates that the software performs as intended through reviews, analyses such as data flow and control flow examination, and testing that compares defined inputs to expected outputs. Configuration management tracks every version of every developed item, while quality assurance confirms the processes and outputs conform to the established plans and standards.

Certification Liaison

Through certification liaison, the team and certification authority align on software assurance objectives. The PSAC defines which objectives apply to the assigned DAL, supports early certification authority review, and serves as the authority’s primary reference.

When cybersecurity threats could affect safety, DO-178C coordinates with the DO-326A guidance, the airborne security process specification that covers where safety and security intersect.

Software certification fits within a Type Certificate (TC) or a Supplemental Type Certificate (STC) approval for the aircraft or system. The software evidence supports the broader aircraft or system approval.

Requirements Traceability in DO-178C

DO-178C requires documented bidirectional connections, called traces, between certification artifacts. Forward traceability confirms that every requirement is implemented and tested, and backward traceability confirms that every line of code and every test is justified by a requirement. We rely on that pairing to catch extraneous code before it becomes an audit finding.

The standard centers on bidirectional links between system requirements and high-level requirements, high-level and low-level requirements, low-level requirements and source code, high-level requirements and test cases, and low-level requirements and test cases. Most teams track these connections in a requirements traceability matrix, where a single low-level requirement traces up to its high-level requirement, down to the implementing source code, and across to the verifying test cases.

DO-178C made trace data more explicit as lifecycle evidence and expanded attention to traceability across test results, procedures, and cases. When a requirement changes mid-program, teams have to walk the chain and identify every affected artifact, and a missed link can become an audit gap.

Common Challenges in DO-178C Compliance

DO-178C programs can run into traceability, coverage, documentation, and tool-qualification issues during certification work. The challenges below are the common traceability challenges teams face most often, including missing trace links and stale verification results:

• Structural coverage analysis: Achieving MC/DC at DAL A is difficult and costly, and object-oriented code complicates coverage of destructors, templated classes, and private members.
• Dead and deactivated code: DO-178C terminology treats code that is not traceable to a requirement as extraneous, and uncovered code triggers an iterative review, analysis, and verification cycle to resolve.
• Documentation burden: Inadequate documentation at any phase, or incomplete planning data across the process plans, can contribute to budget overruns.
• Tool qualification: A tool that replaces a DO-178C process and whose output is not manually verified can require qualification under DO-330, with rigor scaling according to the tool’s use and assurance impact.

Broken artifact links connect several of these failure modes, especially when teams manage requirements in spreadsheets and lose links between components. A tool doesn’t require qualification if its output is independently verified.

How to Prepare for DO-178C Certification

Preparation starts before any code is written. Establishing the software level early sets downstream rigor, because the assigned DAL determines which objectives apply and how deep structural coverage must go.

Submitting the PSAC early lets the certification authority resolve issues like partitioning and software level assignment before they become expensive. The plan should identify which supplements apply, describe how each will be used, and show how lifecycle links will remain current through verification results. Programs that follow verification and validation best practices from the start keep ownership, review status, and configuration data current throughout development, rather than reconciling manual exports the week before a milestone.

Certification authorities review compliance through the Stages of Involvement (SOI) across planning and development, verification, and final certification review. Involving Designated Engineering Representatives (DERs) in change classification and documenting results in the Software Accomplishment Summary (SAS) and Software Configuration Index (SCI) keeps the program aligned with its plans. A DER sample should point to the current lifecycle data for whichever requirement they select.

What Does DO-178C Certification Involve?

DO-178C certification places software approval within the aircraft or system certification. The evidence supports a TC, an STC, an amended type certificate, an amended STC, or a Technical Standard Order authorization for the product carrying it.

A DER or certification authority reviews life cycle data to assess compliance, inspect documents, interview personnel, witness activities, and sample data through the SOI process. Artifacts include the PSAC at planning, requirements and design data during development, test cases and coverage analysis during verification and the SAS and SCI at final review.

We’ve seen developers show compliance through evidence that DO-178C objectives were met, but compliance and certification are not the same thing. The authority makes the certification decision that the evidence supports airworthiness for the aircraft or system.

How Jama Connect Supports DO-178C

Producing a certification evidence package from exports, spreadsheets, and manual trace reports tends to surface the same problems: missing trace links, stale verification results, and unexplained uncovered code. Jama Connect® keeps certification artifacts and relationships connected as the program evolves, detailed in Jama Connect techniques for airborne systems.

With Live Traceability™ running across the V-model, we can see when a requirement, test, or verification result needs attention. That keeps the support story focused on the audit problem: auditors can review current relationships throughout the development process.

Build DO-178C Evidence Before the Audit

Audit readiness comes down to keeping evidence coherent while the software changes, so reviewers get the program’s actual working record instead of a reconstruction project assembled the week before a milestone.

Jama Connect keeps that working record connected as changes occur, so you’re not rebuilding trace links from exports when the audit date moves up. Start a free 30-day trial of Jama Connect to see how it works with your own certification data.

Frequently Asked Questions About DO-178C

How does DO-178C relate to DO-254?

DO-178C covers airborne software while DO-254 covers airborne electronic hardware. When a system requirement is allocated to software, DO-178C objectives apply, and when it lands on complex hardware, DO-254 takes over instead. Teams managing both scopes need bidirectional traceability that holds across those allocations so software and hardware evidence stay connected.

Is DO-178C the same as DO-200C?

DO-178C covers software design assurance, while DO-200C governs the processing of aeronautical data, such as navigation databases. Both are RTCA standards, but DO-200C applies to data that can sit outside the embedded airborne software lifecycle while still influencing aviation safety. Keeping those scopes distinct helps teams avoid treating data assurance and software assurance as the same work.

Is there DO-178C certification training available?

Yes. Training is available through standards bodies, FAA’s DER recurrent training program, and industry consultancies that run introductory and advanced workshops. Jama Software® offers training and consulting for Jama Connect and airborne-systems workflows, but its public materials do not identify a standalone DO-178C certification-training course delivered by Jama itself. Course content can span the DO-178C processes, our MBSE webinar with CATIA, tool qualification, and the related supplements.

What is the difference between DO-178C compliance and certification?

Teams demonstrate compliance with current plans, requirements traces, verification results, configuration records, and quality assurance evidence for the assigned DAL. Before an SOI review, we confirm that traceability evidence stays current alongside verification results rather than being reconstructed after the fact.

The authority makes the certification decision for the aircraft or system carrying the software, with the code covered inside that product approval. Jama Connect can help organize the working record before the authority reviews the artifacts and recommends approval as part of a TC or STC.

This article was authored by Mario Maldari and published on July 30, 2026.