You are starting a new software program—or reopening a legacy baseline—and the same question appears almost immediately. Many teams brace for a simple answer: DO-178C is newer, so DO-178B must be obsolete. Aviation certification is more deliberate than that.
The version that applies is set by your program’s certification basis and the means of compliance accepted for that program. DO-178C is the normal starting point for new processes, while Federal Aviation Administration (FAA) Advisory Circular (AC) 20-115D permits continued DO-178B use in defined circumstances, including qualifying established processes and legacy software.
By AeroCert Institute — a federally recognized 501(c)(3) nonprofit organization founded by aviation safety professionals with FAA credentials. Last reviewed: 2026-08-16.
A standard is a means of compliance, not the regulation
Here is the first important distinction: DO-178B and DO-178C are industry standards, not regulations. They describe how to develop airborne software with evidence proportionate to its safety role. The legal requirements come from the applicable airworthiness regulations and the certification basis established for the aircraft, engine, propeller, or article.
AC 20-115D explains one acceptable way to show compliance for the software aspects of a product approval or a Technical Standard Order (TSO) authorization. A TSO is an FAA minimum-performance standard for specified articles. The AC is not mandatory and is not the only possible means of compliance, but a team choosing its method must follow the accepted method in all applicable respects.
That is why “always use the newest revision” is not a certification rule. The later letter does not decide the project. The deciding question is which software-assurance approach the applicant proposes, supports with evidence, and coordinates with the responsible certification authority.
Your Plan for Software Aspects of Certification (PSAC) is where that proposed approach should become visible. The PSAC explains how the software will be developed, verified, controlled, and shown compliant. If the version decision is unclear there, it is not yet clear enough for the program.
DO-178C is the normal starting point for new processes
For an applicant or developer establishing software life-cycle processes for the first time, AC 20-115D says those processes should be established in accordance with DO-178C. The circular also recognizes DO-178C as an acceptable means of compliance for software used in type certification and TSO authorization.
This does not make DO-178C a regulation. It gives a new team a clean default when there is no previously accepted DO-178B process to preserve. Starting with DO-178C avoids building a new process around an older revision and then having to justify why that choice is suitable.
DO-178C also works with a defined family of supporting documents. DO-330 addresses software tool qualification; DO-331 addresses model-based development and verification; DO-332 addresses object-oriented technology and related techniques; and DO-333 addresses formal methods. These documents belong to the DO-178C framework and are applied only when their subject matter is relevant to the project. A supplement is not a stand-alone alternative to DO-178C.
Tool Qualification Level (TQL) is the DO-178C framework’s classification for the rigor applied when a software tool must be qualified. A team should not lift DO-178C’s TQL terminology or supplement structure into a DO-178B compliance claim as though the two revisions used the same tool-qualification scheme.
For a team building its process from scratch, the practical answer is usually straightforward: propose DO-178C, identify any applicable supplements, and coordinate the approach before the plans and development environment harden.
DO-178B can still be acceptable
Here is the part the “newer is mandatory” shortcut misses: AC 20-115D expressly provides paths for continued use of DO-178B. One path covers new software developed with established DO-178B processes. Another covers modification or reuse of software that was previously approved using an earlier revision.
For new development using an established DO-178B process, the circular sets conditions. In plain language, the process must have no known unresolved deficiencies; it must have been used successfully on previously certified software at an appropriate software level; relevant special techniques and configuration-data practices must already have an accepted basis; and the plans, processes, and development environment cannot have changed significantly without adequate analysis. The applicant also cannot call the resulting software DO-178C-compliant.
If those conditions are not met, AC 20-115D points the team toward upgrading the process and developing the new software using DO-178C. “We have always done it this way” is not evidence that an established process remains suitable.
Legacy software requires a project-specific assessment, not an automatic rewrite. The circular calls for evaluating service history, safety-related service difficulties, airworthiness directives, open problem reports, process findings, and whether the prior software level is acceptable for the proposed installation. If the software changes, the team performs a change impact analysis to determine what is affected and what verification is needed.
That careful treatment of existing evidence is also why planes can keep flying safely on decades-old software. Proven software does not become unacceptable merely because a later standard exists. The installation, approval history, proposed change, and available evidence all matter.
Consider a small supplier opening a previously approved DO-178B baseline to change one function. If the supplier has maintained the original plans, processes, and life-cycle environment, the software level remains suitable for the new installation, and the usage and problem history are acceptable, AC 20-115D may support making the change under the original DO-178B basis. The team still has to perform and document the required assessment and change impact analysis; the example is not a shortcut around them.
If those legacy conditions are not satisfied, the circular directs the applicant to update the relevant processes and procedures to the DO-178C framework. The dividing line is therefore evidence and project suitability, not age alone.
What changed between DO-178B and DO-178C
DO-178C did not turn DO-178B software levels into a different set of safety categories. AC 20-115D states that the DO-178B and DO-178C software levels are consistent. A Level B designation under one revision does not become another letter merely because the program moves to the later standard.
Same levels, however, does not mean the same playbook.
The practical changes are mainly about clarification, stronger treatment of topics that caused inconsistent interpretation, and a better-defined relationship with specialized techniques and tool qualification. DO-178C’s supporting documents separate tool qualification and technique-specific guidance into the DO-330 through DO-333 family. The later framework also gives explicit attention to configuration data treated as a Parameter Data Item (PDI), meaning data that configures software behavior without changing the executable code.
That is not a complete differences list, and it should not be used as one. DO-178C itself identifies its differences from DO-178B, while the FAA circular explains how the later framework may be used and how existing DO-178B processes or legacy software may continue. A formal gap assessment must compare the program’s actual plans, standards, tools, life-cycle data, and prior approvals—not rely on a generic objective-count table.
For the broader history behind the two revisions, read How aviation’s software standard grew up. The history explains why old and new can coexist; AC 20-115D supplies the project-level decision paths.
How to decide before the choice becomes expensive
Start by naming the situation correctly. Are you creating new life-cycle processes, reusing an established DO-178B process for new development, reusing approved legacy software without modification, or modifying legacy software? Those are four different starting points, and AC 20-115D gives different considerations for each.
Before comparing revisions, confirm the software level required for the proposed installation. Reused software does not carry one universal level into every aircraft. If that decision is still open, begin with what decides your DO-178C design assurance level.
Then assemble the evidence needed for the applicable path:
- the proposed certification basis and means of compliance;
- the software level assigned for the proposed installation;
- prior approval records and evidence that an established process was used at an appropriate level;
- unresolved audit findings, review findings, or process-related problem reports;
- changes to plans, processes, tools, and the development environment;
- service and problem history for reused software;
- the change impact analysis for any modification; and
- the exact compliance claim the program intends to make.
Bring the decision into certification planning early. The PSAC should identify the standard revision, any applicable DO-178C supplements, the treatment of previously developed software, the tool-qualification approach, and the life-cycle data that will support the compliance showing. If the program relies on continued DO-178B use, document how the relevant AC 20-115D conditions are satisfied instead of treating the prior approval as self-explanatory.
This is also where wording matters. Software developed under an accepted DO-178B path should not be described as satisfying DO-178C unless the circular’s conditions for that declaration have been met. Conversely, choosing DO-178C for a modification does not erase the existence of approved legacy evidence; it determines how the baseline, change, and supporting processes are treated for the proposed approval.
Early agreement is less disruptive than discovering during a review that the applicant and the authority understood the compliance basis differently. By then, the version decision may already be embedded in plans, tools, verification methods, and life-cycle data.
The applicable revision is a project compliance decision: use DO-178C for new processes, and rely on DO-178B only where the program’s accepted basis and evidence satisfy the FAA guidance for established or legacy use.
As a next step, use AeroCert’s free public-tier checklist library to review the planning, requirements, development, verification, configuration-management, tool-qualification, and certification evidence affected by the choice. It includes seven plain-language DO-178B/C checklists with 88 checkpoints, free to use and share.
Primary sources
- FAA AC 20-115D, Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ), especially paragraphs 1, 5, 6, 8, 9, and 10.
This article is educational guidance. It does not replace the applicable certification basis, project-specific FAA coordination, a qualified authorized representative, or an FAA finding of compliance.
Leave a Reply