DO-178C: Design Assurance Levels, Life Cycle, and FAA Review

DO-178C is the aviation industry’s guidance for developing and certifying software that runs on civil aircraft, and it is the framework almost every avionics team uses to earn regulatory approval. Published by RTCA in December 2011 as a replacement for DO-178B, DO-178C software certification is recognized by the FAA through Advisory Circular AC 20-115D as an acceptable means of showing that airborne software meets airworthiness requirements.¹ Its European counterpart, EUROCAE ED-12C, is treated as technically equivalent, so software approved under one framework is generally accepted under the other.²

What DO-178C Applies To

The standard covers any software whose failure could affect the safe operation of an aircraft: flight control laws, engine management, display systems, communication radios, and similar functions. It does not cover ground-based air traffic management software, which is addressed by DO-278A, and it does not cover airborne electronic hardware, which falls under DO-254.

DO-178C is guidance, not regulation. The FAA calls it “an acceptable means, but not the only means” for compliance.³ In practice, proposing an alternative adds enough effort and uncertainty that civil aviation projects use it almost universally.

Design Assurance Levels Drive Everything

Every DO-178C project starts with a system safety assessment, typically performed under ARP 4761, that assigns each software component a Design Assurance Level (DAL) from A through E. The DAL answers a single question: what happens if this software fails? Every requirement in DO-178C scales from that answer.

Level A (Catastrophic): failure could cause loss of the aircraft. Flight control computers and fly-by-wire systems sit here. Target failure rate: no more than one in a billion flight hours (10⁻⁹).
Level B (Hazardous): failure significantly reduces safety margins or could cause serious injury. Autopilot functions and some engine controls. Target failure rate: 10⁻⁷.
Level C (Major): failure increases crew workload or causes significant discomfort but remains manageable. Navigation displays and some communication systems. Target: 10⁻⁵.
Level D (Minor): failure causes minor inconvenience. Cabin lighting controls, passenger entertainment interfaces. No specific failure rate is mandated beyond showing the effect is minor.
Level E (No Effect): no impact on aircraft operation or crew workload. No DO-178C objectives apply.

Getting the DAL wrong at the outset is one of the most expensive mistakes in avionics development. If a later safety assessment reveals that Level C software should have been Level B, the rework can be significant because objectives and rigor climb sharply between levels.

Objectives, Independence, and Structural Coverage

The number of objectives you must satisfy scales with DAL. Level A requires 71, Level B requires 69, Level C requires 62, and Level D requires 26. Level E has none.

The counts understate the real cost driver, which is independence. Independence means the person reviewing or testing a piece of work cannot be the same person who created it. Level A requires 30 of its 71 objectives to be completed with independence. Level B requires independence on 18. Levels C and D require none, which is a major reason lower-level projects cost less to certify.

Structural coverage analysis, which demonstrates that tests actually exercise the code, also diverges sharply by level:

Level A: Modified Condition/Decision Coverage (MC/DC). Every condition in every decision must independently affect the outcome.
Level B: Decision coverage. Every branch point exercised both true and false.
Level C: Statement coverage. Every line of executable code reached by at least one test.
Level D: No structural coverage requirement.

MC/DC is where Level A projects spend a disproportionate share of verification time. A single complex Boolean expression can need dozens of test cases to achieve full MC/DC, and every gap must be analyzed and justified.

The Life Cycle Processes

DO-178C organizes the work into planning, development, and integral processes. These run in parallel and iterate throughout the project rather than proceeding as distinct phases.

Planning

Before code is written, you produce a set of plans that describe the development environment, coding standards, verification methods, and configuration management approach. The Plan for Software Aspects of Certification (PSAC) is the anchor document. It identifies the assigned DAL, proposes the compliance strategy, and functions as the agreement between the applicant and the certification authority. Other plans cover software development, verification, quality assurance, and configuration management.

Development

Development moves through high-level requirements, low-level requirements and architecture, source code, and integration onto target hardware. Traceability holds the sequence together. Every requirement traces forward to the code that implements it and the test that verifies it, and backward to the system requirement it came from. A requirement that cannot be traced in both directions is a gap that will surface in verification or audit.

Integral Processes

Three processes run alongside development. Verification catches errors through reviews, analyses, and testing at each stage. Configuration management controls every artifact so nothing changes without authorization and every version is traceable. Quality assurance provides an independent check that the team is following its own plans. A fourth process, certification liaison, handles communication with the FAA or other authority. Early and continuous engagement with the regulator prevents surprises at audit.

The Documentation Package

The certification package is the body of evidence that shows your software was developed according to plan and meets every applicable objective. Most of these documents are living artifacts maintained throughout development, not deliverables produced at the end.

Plan for Software Aspects of Certification (PSAC): describes the system, identifies the DAL, proposes the compliance approach, and sets the schedule for regulatory reviews.
Software Development Plan: defines environment, languages, tools, and coding standards.
Software Verification Plan: describes verification methods, tools, and strategies for reviews, analyses, and testing.
Software Configuration Management Plan: sets how artifacts are identified, controlled, baselined, and audited.
Software Quality Assurance Plan: details how QA monitors compliance with the other plans.

Beyond the plans, the package includes requirements, design, source code, test cases, test results, traceability data, problem reports, and the Software Accomplishment Summary (SAS). The SAS is the closing document that summarizes the certification effort and declares compliance with the approved plans. Gaps or inconsistencies in documentation are among the most common causes of audit findings and delays.

Stages of Involvement: How the FAA Reviews Your Software

FAA Order 8110.49A governs how the authority reviews software life cycle data.⁴ Involvement typically takes the form of four Stage of Involvement (SOI) audits conducted by FAA engineers, Designated Engineering Representatives (DERs), or members of an Organization Designation Authorization (ODA).⁵

SOI 1 (Planning Review): early review of your plans, particularly the PSAC. Confirms that your proposed methods, tools, and standards will produce acceptable evidence before you invest heavily in development.
SOI 2 (Development Review): examines requirements, architecture, and design against the approved plans. Traceability between system and software requirements receives close scrutiny.
SOI 3 (Verification Review): focuses on whether testing, reviews, and analyses are strong enough to catch defects. Coverage results, structural coverage analysis, and problem reports are the primary evidence.
SOI 4 (Final Review): review of the Software Accomplishment Summary and the complete package. If all objectives are satisfied and open issues resolved, the authority grants software approval for installation on the specific hardware platform.

These audits stretch across the entire timeline. SOI 1 can happen a year or more before SOI 4. The scope and depth of each review are negotiated between the applicant and the authority early in the project.⁴ A finding during any SOI can halt progress until resolved.

Technology Supplements

Rather than rewriting DO-178C to cover every emerging technology, RTCA published four companion supplements that modify or add objectives when specific approaches are used.⁶ All four are recognized alongside DO-178C in AC 20-115D, and you apply only the ones relevant to your project.

DO-330 (Tool Qualification): if a tool automates part of development or verification and its output is not independently verified, the tool itself may need qualification. Five Tool Qualification Levels reflect whether the tool could insert an error or fail to detect one. A flight-critical code generator faces a much higher burden than a text editor. DO-330 comes up on almost every project because almost every project uses tools.
DO-331 (Model-Based Development and Verification): adds objectives for model creation, verification, and maintenance when models drive requirements or code generation.
DO-332 (Object-Oriented Technology): provides guidance for using features like inheritance, polymorphism, and dynamic binding in certified software.
DO-333 (Formal Methods): defines when theorem proving, model checking, and abstract interpretation can satisfy DO-178C objectives as alternatives to traditional testing.³

Legacy and Third-Party Code

DO-178C was written primarily for new, custom-developed avionics software, but projects often need to incorporate code that already exists. Previously Developed Software (PDS) built before a formal DO-178C process can still be certified, but you generally have to reverse-engineer the evidence DO-178C would have required from the start: documented requirements, traceability, test coverage, and structural analysis. How much rework depends on the quality of the original documentation.

Commercial Off-the-Shelf (COTS) software is harder. Operating systems, libraries, and third-party components rarely arrive with DO-178C-compliant evidence, and the vendor is usually unwilling or unable to provide it. Options include qualifying the COTS component through added testing and analysis, wrapping it in a monitoring layer, or replacing it with a purpose-built alternative. None are cheap, and the choice depends on the DAL and the role the component plays.

What Certification Actually Costs

DO-178C adds meaningful cost, but the increase at lower levels is smaller than many teams assume. Level D development runs roughly 15 percent more than a comparable high-quality commercial project. Moving from Level D to Level C adds about 35 percent more effort, mainly because Level C introduces statement coverage and additional verification objectives.

The largest gap between Level A and Level B systems is the 100-times-greater reliability requirement, and that reliability comes primarily from system architecture and hardware redundancy rather than the software itself. On the software side, the incremental effort from Level B to Level A comes from MC/DC coverage and the additional independence requirements.

Overall, adopting DO-178C increases initial software engineering costs by roughly 25 to 40 percent compared to a non-certified project of similar complexity. Projects that blow past that range typically do so because of requirements instability, late DAL reassignment, or planning gaps that trigger audit findings. The standard itself is predictable; the mistakes are what get expensive.

What Changed From DO-178B

DO-178B served the industry from 1992 to 2011, and many legacy systems still carry DO-178B certification. DO-178C did not overhaul the framework but addressed gaps that two decades of use had exposed.⁶

Technology supplements: adding DO-330 through DO-333 gave developers sanctioned paths for tool qualification, model-based development, object-oriented technology, and formal methods.
System-software interaction: the feedback paths between system and software processes were reworked, clarifying responsibilities for derived requirements and data exchange with hardware teams.
Parameter Data Items: configurable data that can change aircraft behavior without modifying executable code was formalized, with clear expectations for development and verification.
Tool qualification: guidance was moved out of the main document into the dedicated DO-330 lifecycle.
Outsourcing: DO-178C explicitly recognizes distributed development across suppliers and subcontractors, with oversight guidance.
Extended applicability: scope was broadened to explicitly cover propellers and auxiliary power units alongside aircraft and engines.

Projects certified under DO-178B do not need to re-certify under DO-178C unless the software undergoes a significant modification. When changes are made to a DO-178B-certified system, the FAA generally expects those modifications to follow DO-178C going forward.

1
Federal Aviation Administration. AC 20-115D – Recognition of RTCA/DO-178C, Software Considerations in Airborne Systems and Equipment Certification
2
European Union Aviation Safety Agency. Easy Access Rules for Acceptable Means of Compliance
3
Federal Aviation Administration. AC 20-115D – Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( )
4
Federal Aviation Administration. FAA Order 8110.49A – Software Approval Guidelines
5
Federal Aviation Administration. Delegated Organizations
6
Federal Aviation Administration. DO-178B/C Differences Tool