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

Every line of code running on a commercial aircraft went through a certification process before it was cleared to fly. DO-178C is the standard that defines what that process looks like. It specifies the objectives teams must meet and the evidence they need to produce. Recognized by the Federal Aviation Administration (FAA), European Union Aviation Safety Agency (EASA), and Transport Canada as the primary means of evaluating airborne software, DO-178C shapes engineering decisions throughout the entire certification lifecycle.

For engineers and program managers preparing for certification, understanding DO-178C early helps prevent costly rework later in the lifecycle. This guide covers how the standard evolved, what each Design Assurance Level requires, how the core processes interact, and where teams commonly run into compliance challenges.

What Is DO-178C?

DO-178C, formally titled Software Considerations in Airborne Systems and Equipment Certification, provides three types of guidance for airborne software. It defines objectives for software lifecycle processes, activities that satisfy those objectives, and descriptions of evidence that prove those objectives have been met.

The standard doesn’t prescribe how to build software. It specifies what teams must demonstrate, with rigor scaled to the severity of failure consequences. That objectives-based approach makes the framework adaptable across development methodologies and technologies, which is one reason it’s lasted as long as it has.

History and Evolution of DO-178

DO-178 went through several iterations before arriving at the objectives-based framework teams use today. The original 1982 version defined three unnumbered assurance levels, DO-178A refined them into a numbered system in 1985, and DO-178B introduced the most significant shift in December 1992 by moving to an objectives-based framework with five levels (A through E).

DO-178C then added a modular document architecture. The core document remained similar to DO-178B, while new guidance went into companion documents released alongside the core standard.

DO-178C Supplements and Related Standards

The SC-205 committee placed most new guidance into companion documents instead of revising the core standard. Four technology supplements are the most directly relevant to DO-178C certification:

• DO-330: Governs qualification of tools used in the software lifecycle. Introduces Tool Qualification Levels (TQL 1-5) scaled by criterion type and the software’s assurance level.
• DO-331: Applies when teams use model-based development methods. Provides guidance on obtaining certification credit for model-based verification.
• DO-332: Covers object-oriented technology (OOT) and related techniques.
• DO-333: Allows formal methods such as theorem proving and model checking to complement or replace dynamic testing.

FAA Order 8110.49A confirms that references to DO-178C include use of these supplements and DO-330 where applicable. DO-178C also connects to ARP 4761 for safety assessment, ARP 4754A for system-level development assurance, and DO-254 for airborne electronic hardware.

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.

How Failure Conditions Map to Software Levels

Each DAL maps to a defined failure condition severity established during the Functional Hazard Assessment (FHA). The table below shows the relationship between DAL, failure condition, and potential consequence.

A formal FHA is required for DAL assignment, and the same function can receive a different DAL across aircraft depending on architecture and redundancy. That’s why safety assessment needs to happen at the system level before software teams can determine their compliance path.

What Each Level Requires

The jump in effort between DALs is uneven, and some transitions affect cost and schedule far more than others. The following table breaks down the objective counts and structural coverage requirements at each level.

The transition from DAL D to DAL C introduces the largest increase in objectives and is one of the most consequential steps for cost and schedule planning. Going from DAL B to DAL A adds only two total objectives but brings 12 additional independence requirements, which creates significant organizational constraints around who can review what.

Core Processes in DO-178C

DO-178C organizes software lifecycle activities into planning, development, and integral processes that include verification, configuration management, quality assurance, and certification liaison. These processes run concurrently, which means teams need to coordinate across all of them throughout the program.

Planning

The Plan for Software Aspects of Certification (PSAC) is the primary planning document that anchors the certification approach. It’s typically prepared early in the initial software planning phase to align certification expectations and reduce risk, though neither DO-178C nor AC 20-115C explicitly require that all planning be completed before development begins.

The PSAC sets the agreement on certification strategy, tools, commercial off-the-shelf (COTS) software, supplement applicability, and schedule. Four additional plans cover the lifecycle model (Software Development Plan), verification approach (Software Verification Plan), version control (Software Configuration Management Plan), and process compliance (Software Quality Assurance Plan).

Software Development

Development follows a structured decomposition from system requirements down to code. System requirements decompose into Software High-Level Requirements (HLRs), then Low-Level Requirements (LLRs), and finally source code. Any derived requirements that can’t be traced to a higher-level parent must be identified and fed back into the safety assessment process through ARP 4754A.

Software Verification

Verification in DO-178C is requirements-based, meaning all test cases must trace to a documented requirement. Structural coverage analysis then confirms that testing exercised the code at the depth required by the assigned DAL. It’s common for DO-178C projects to spend more hours on testing than on coding, and verification typically represents the largest share of the project budget.

Configuration Management

Configuration management controls baselines, version control, change management, and artifact tracking across the lifecycle. Formal reviews depend on controlled lifecycle data, and any gap in configuration management can undermine the integrity of every other process.

Quality Assurance

Software Quality Assurance (SQA) in DO-178C has an active enforcement function. QA confirms that project plans and standards comply with DO-178C and that the development team follows them throughout the program. Even DAL D software requires configuration management, quality assurance, and Designated Engineering Representative (DER) liaison.

Certification Liaison

Certification liaison covers gaining PSAC approval and providing compliance substantiation to the certification authority. This typically happens through desk reviews, on-site reviews, or FAA Form 8110-3 from a software DER.

Requirements Traceability in DO-178C

Bidirectional traceability is the evidence base for showing that software meets its approved requirements and contains no undocumented behavior. Teams use it to confirm that every allocated requirement has been implemented and tested, and that no software behavior exists without an approved requirement behind it.

DO-178C requires trace data as explicit development process outputs. Those outputs must document the linkages from HLRs through LLRs and from LLRs through source code. At the final Stage of Involvement (SOI #4), auditors may request that teams reproduce test results from a specific baseline and review lifecycle artifacts associated with that baseline. Traceability gaps, whether they involve requirements without test cases, orphaned code, or tests without results, are findings that must be resolved before certification can proceed.

Common Challenges in DO-178C Compliance

DO-178C programs often struggle with the combined weight of evidence production, coordination, and traceability control. Three problem areas come up more than any others.

Managing Documentation and Artifact Volume

Documentation volume alone can become a schedule risk on certification programs. A single software component can take substantial time to certify and can generate large volumes of lifecycle data along the way. Five plans must be completed before development starts, and four SOI reviews are mandatory gating events, so delays at any SOI cascade through the entire program timeline.

Maintaining Traceability Across Disconnected Tools

When traceability chains span multiple tools, manual cross-referencing introduces gaps that stay invisible until an auditor samples them. A requirement can change in one system while the linked test case in another system still reflects the old version, and nobody catches it until a formal review or, worse, a defect surfaces in the field. That kind of disconnect between design changes and certification documentation is exactly what bidirectional traceability is meant to prevent.

Balancing Cost, Schedule, and Rigor

DO-178C compliance adds measurable cost and schedule pressure, even on well-run programs. One estimate puts the cost increase at 25% to 40% above a Capability Maturity Model Integration (CMMI) Level 2-3 baseline under optimal conditions, and a peer-reviewed Constructive Cost Model (COCOMO) II study found that standard estimation models underestimated actual effort by about 40%. Teams that don’t account for this overhead in their initial planning often find themselves absorbing it later as unplanned rework.

How to Prepare for DO-178C Certification

The strongest DO-178C programs reduce rework by making planning, verification, and traceability decisions early. Here’s what that looks like.

Start Planning Early and Define Your PSAC First

The PSAC should come first because it sets the certification strategy the rest of the program must follow. It’s typically drafted and submitted before significant development work begins so that the team and the certification authority agree on approach, scope, and tooling early. A good PSAC identifies all tools, declares supplement applicability (DO-331, DO-332, DO-333), classifies tools by DO-330 criteria, and establishes the traceability approach from the start.

Automate Verification and Regression Testing

Because verification consumes the largest share of program effort, the software environment and test suite should be designed upfront to collect structural coverage during functional testing. Building coverage collection into the test environment from the start is far more efficient than retrofitting it later and helps teams avoid expensive rework when coverage gaps surface close to an SOI milestone.

Use Qualified, Integrated Tools for Traceability

When a tool automates lifecycle activities or replaces manual work in a way that affects certification credit, teams need to address tool qualification under DO-330. The qualification plan, including Tool Operational Requirements, Tool Qualification Plan, and Tool Qualification Accomplishment Summary, should be established early and referenced in the PSAC. Requirements management tools that maintain bidirectional trace links across the required relationships help close the gaps that typically surface during SOI audits. Jama Connect, for example, provides Live Traceability across requirements, tests, and risk items, with pre-built frameworks aligned to DO-178C.

Bringing DO-178C Traceability Under Control

DO-178C success depends on keeping planning, verification, and traceability aligned from the first baseline through final audit. Documented compliance issues, including vague requirements and missed traceability links, are often associated with upstream process gaps that compound through the lifecycle. The standard gives teams flexibility in how they develop software, but it demands rigorous evidence that requirements are implemented, testing is complete, and trace links are current.

Teams preparing for SOI audits or managing traceability across multi-tier supply chains face a common challenge in keeping trace links current as requirements, tests, and baselines change. Jama Connect® helps teams maintain bidirectional traceability across changing project data. Start a free 30-day trial.

Frequently Asked Questions About DO-178C

What is the difference between DO-178B and DO-178C?

DO-178C was published alongside a standalone tool qualification document (DO-330) and three technology supplements for model-based development (DO-331), object-oriented technology (DO-332), and formal methods (DO-333). The core standard also made bidirectional traceability an explicit requirement, refined Level E handling, and removed certain Level D objectives related to low-level requirements and source code.

Is DO-178C compliance legally required?

The legal obligation comes from applicable 14 CFR airworthiness regulations, with DO-178C recognized as an accepted means of compliance rather than a regulation itself. Alternative approaches can be used, but they must meet the same airworthiness requirements and receive individual approval from the certification authority.

How long does DO-178C certification take?

Timelines vary significantly by DAL level and program complexity, and even a single component can take years to certify. Most teams find that their initial schedule projections need significant adjustment once DO-178C compliance overhead is factored in, so building in calibration factors early helps avoid mid-program surprises.

What tools support DO-178C compliance?

DO-178C programs typically use requirements management, analysis, testing, and structural coverage tools across the lifecycle. When a tool replaces manual work that affects certification credit, it needs to be qualified under DO-330 based on its intended use and the software’s DAL.