Category: Aviation Safety Education

Your program may hear that the Federal Aviation Administration (FAA) will be “highly involved,” that a designee will handle the software, or that a lower software level means little review. None of those phrases is a complete review plan. The real question is how the certification authority will obtain enough visibility to make its compliance findings.

Short answer: The certification authority determines its level of involvement and documents that decision early. Software level is a starting point, but product complexity, novelty, applicant experience, unusual methods, open issues, and available designee capability also matter. Delegation assigns authorized tasks; it does not transfer the applicant’s compliance responsibility or remove FAA oversight.

By AeroCert Institute — a federally recognized 501(c)(3) nonprofit organization founded by aviation safety professionals with FAA credentials. Reviewed August 2026.

Level of involvement is a review strategy

Level of involvement (LOI) describes how the certification authority plans to engage with the software portion of a certification project. It affects the scope and number of reviews, if any, and whether work is performed directly by FAA staff, delegated to properly authorized designees, or divided between them.

LOI does not change the objectives that apply to the software. It does not reduce the applicant’s responsibility to produce compliant software life-cycle data. It also does not tell a project exactly which documents will be read or how many findings will result.

FAA Order 8110.49A defines a review broadly. A review may involve reading documents, interviewing project personnel, witnessing activities, participating in briefings, or sampling software life-cycle data. It may occur at an FAA desk, at the applicant’s facility, or at a supplier’s facility. Sampling is the primary way the authority assesses whether the project’s processes and data satisfy the applicable RTCA/DO-178B or RTCA/DO-178C objectives.

That makes LOI a certification strategy, not a score the applicant earns. The authority uses it to decide where direct visibility is most valuable and how to use delegated resources within their authorization.

The practical effect is straightforward: two projects using the same software standard can receive different review attention without either project having a different set of applicable objectives. The evidence obligation stays with the applicant. What changes is how the authority plans to examine that evidence and who is authorized to make particular findings.

Software level starts the discussion

The software level is one of the first LOI inputs because it reflects the failure condition associated with anomalous software behavior. If that term is unfamiliar, start with What decides your DO-178C design assurance level?.

Appendix A of FAA Order 8110.49A provides three optional worksheets for the certification authority or designee. The first worksheet associates the software levels with these starting ranges:

• Level D: low involvement
• Level C: low or medium involvement
• Level B: medium or high involvement
• Level A: medium or high involvement

This is useful orientation, but it is not an applicant decision table. The order says the worksheets are examples, may contain criteria that do not apply to every project, and are not mandatory individually or in combination.

Notice what the first worksheet does not say. A Level C project is not automatically low involvement. A Level A project is not automatically high involvement. The ranges leave room for project-specific judgment, and the other worksheets add context about the applicant, the product, and the delegated support available.

The software level therefore sets the initial risk context. It does not finish the LOI decision.

This distinction matters during planning. If a team treats the worksheet as a promise of minimal review, it may underprepare the data the authority later samples. If it assumes a higher software level guarantees constant FAA presence, it may build a schedule around review activity the authority never planned. Both errors come from treating an input as the decision—and both can create the kind of avoidable rework described in Why DO-178C Costs More When Compliance Starts Late.

What changes the authority’s involvement

Order 8110.49A directs the authority to determine and document LOI as soon as possible in the project life cycle. The scope and number of software reviews depend on more than software level.

The order identifies factors that include:

• product size, complexity, functionality, novelty, and software design;
• new technologies or unusual design features;
• novel software methods or life-cycle models;
• the applicant’s experience satisfying DO-178B or DO-178C objectives;
• the availability, experience, and authorization of designees;
• additional considerations associated with Section 12 of DO-178B or DO-178C; and
• software-specific issue papers that apply to the certification project.

Appendix A expands that picture. Its second worksheet looks at applicant and developer certification experience, demonstrated development capability, software service history, current system and software characteristics, and designee capabilities. Its third worksheet combines those considerations with the software level to suggest low, medium, or high involvement.

Consider a Level C project using a novel architecture and an unfamiliar development method. If the team has limited civil certification experience and no suitably authorized designee is available, the authority may need more direct visibility than the Level C label alone would suggest. The applicable objectives do not increase; the review strategy changes because the path to credible evidence carries more uncertainty.

The reverse is not a shortcut. Strong experience, familiar technology, stable processes, and capable delegated support may make focused involvement practical, but they do not excuse missing evidence or unmet objectives. LOI is about how compliance will be assessed, not whether compliance is required.

Applicants cannot calculate their own binding LOI from the worksheets. They can, however, make the authority’s judgment easier by providing accurate project information early. The planning data should clearly describe software levels, architecture, development and verification environments, proposed methods, supplier roles, tool use, reuse, and anticipated certification issues. If those facts change, the coordination should change with them.

What delegation does—and does not—mean

FAA Order 8110.49A states that both desk reviews and on-site reviews may be delegated to properly authorized designees. Delegation can therefore place substantial technical review activity with a designee, but only within the authorization and scope established for the work.

This is where teams sometimes use imprecise language. “The FAA delegated the project” can sound as though the FAA has stepped away. That is not what the order describes.

The certification authority remains part of the certification process. One stated objective of the software review process is to provide the authority an opportunity to monitor designee activities. The availability, experience, and authorization of designees are themselves factors in determining LOI. If the right delegated capability is unavailable—or if the issue falls outside the assigned authorization—the authority may retain or increase direct involvement.

Delegation also does not transfer the applicant’s responsibility. The applicant still must establish the agreed means of compliance, perform the planned development and verification activities, control the resulting data, and provide evidence that the applicable objectives are satisfied. A designee can review data and make findings only as authorized; the designee does not become the developer, verification organization, or quality system.

The useful planning question is not, “Will the FAA or the designee do the certification?” It is, “Which findings and review activities are assigned to whom, within what authorization, and what evidence must be ready for each interaction?”

That question should be answered explicitly. For an on-site review, Order 8110.49A calls for agreement on scope, dates, locations, participating authority personnel and designees, agenda and expectations, data availability, procedures, resources, and how results will be communicated. Those arrangements turn a vague statement about involvement into an executable review plan.

LOI and SOI answer different questions

Level of involvement and Stages of Involvement (SOI) are related, but they are not interchangeable.

LOI addresses the depth and scope of certification-authority engagement and how authorized delegation will be used. SOI reviews describe review points aligned with project maturity: planning, development, verification, and final certification evidence. For a practical view of those review points, see What Happens When the FAA Looks at Your Software? SOI Reviews, Explained.

FAA Order 8110.49A does not use SOI terminology. That absence should not be read as proof that one concept replaced the other. The safer interpretation is that they answer different planning questions. LOI helps determine how much authority attention is appropriate and what may be delegated. SOI planning helps organize when evidence will be mature enough for meaningful review.

The two axes meet in the project review plan. A project with focused LOI may still need disciplined maturity at every agreed review point. A project with more direct authority involvement still benefits from clear entry criteria, controlled data, and timely issue closure. Review timing cannot compensate for weak evidence, and high-quality evidence does not give the applicant authority to set its own LOI.

The best time to resolve this is during certification planning, before the team has committed to assumptions about review dates or delegated roles. Ask the authority or designated representative to confirm:

• the planned LOI and the factors driving it;
• the expected desk and on-site review activities;
• the authorized designees and the scope assigned to each;
• the data and maturity expected for every review; and
• how findings, corrective actions, and changes to the plan will be communicated.

Treat that coordination as living project information. A change in software level, architecture, method, supplier, designee availability, or certification issue may justify revisiting the review strategy.

The takeaway: the FAA’s involvement is risk- and project-informed, and delegation changes who performs authorized review work—not who must produce compliant evidence.

To make early coordination more productive, use AeroCert’s free public-tier checklist library to identify gaps in the evidence your reviewers will need. It includes seven plain-language DO-178B/C checklists with 88 checkpoints, free to use and share. The checklists do not calculate LOI; they help you arrive with a clearer, more reviewable baseline.

Primary sources

• FAA Order 8110.49A, Software Approval Guidelines, Chapter 2 and Appendix A, effective March 29, 2018.

This article is general information, not a project-specific compliance finding. Coordinate the applicable certification basis, means of compliance, level of involvement, and delegation with your certification authority and authorized representatives.

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.

If you are planning a DO-178C program, one question quickly becomes expensive: which software level applies? It is tempting to answer from the code—how large, complicated, or new it looks. Certification starts somewhere else.

The system safety process sets the minimum software level from the severity of the failure conditions the software can cause or contribute to. More severe potential aircraft effects require more development assurance. Code size, architecture, budget, and schedule affect the work, but none of them decides the level on its own.

By AeroCert Institute — a federally recognized 501(c)(3) nonprofit organization founded by aviation safety professionals with FAA credentials. Reviewed August 2026.

What “DAL” means on a software project

Most teams call it the Design Assurance Level, or DAL. That is useful shorthand, but it can hide three different decisions.

At the system level, SAE ARP4754A uses a Functional Development Assurance Level, shortened to FDAL, and an Item Development Assurance Level, or IDAL. DO-178C, Software Considerations in Airborne Systems and Equipment Certification, uses the term software level.

The levels are related, but they are not interchangeable. The system safety and development-assurance work determines how aircraft and system functions are allocated to items. Your software plans then identify the software level that applies to each software component and show how it follows from those system-level decisions.

This distinction is more than vocabulary. If a plan says only “DAL C,” a reviewer still needs to know whether that label applies to a function, an item, or the software itself—and where the assignment came from.

Federal Aviation Administration (FAA) Advisory Circular (AC) 20-115D recognizes DO-178C as an acceptable means of showing that airborne software satisfies applicable airworthiness requirements. The circular says the system safety process assigns the minimum development-assurance level from the severity of the associated failure conditions. The applicant then satisfies the DO-178C objectives associated with that level and produces the applicable software life-cycle data.

The practical rule: name the level precisely, identify the safety assessment that supports it, and keep that connection visible in the software plans.

The decision starts with what can go wrong

The safety process begins with the aircraft or system function. What must it do? How could it fail? What would happen to the aircraft, occupants, or crew if that failure occurred?

Those failure conditions are classified by severity. The software level follows the most severe failure condition to which the software can contribute:

Software level	Associated failure-condition severity
Level A	Catastrophic
Level B	Hazardous or Severe-Major
Level C	Major
Level D	Minor
Level E	No effect on safety

These letters do not measure how likely a programmer is to make a mistake. They measure the potential consequence if the software behaves incorrectly in the installed system.

Consider one example: a short routine provides the sole command that deploys a safety-critical aircraft function. Its small size does not make the required assurance small. If incorrect output can contribute to a severe failure condition and no valid architectural mitigation changes that effect, the level follows the failure condition—not the number of lines of code.

Architecture can change the answer, but only through a supported safety argument. Partitioning, monitoring, redundancy, independence, and other design features may change how a failure propagates or which item can contribute to it. Your software team cannot claim a lower level simply because one of those features appears on an architecture diagram. The feature, its assumptions, and its limitations must be established in the system safety process.

The same rule applies to reused software. A component does not carry one universal level into every aircraft installation. Its existing evidence may be useful, but AC 20-115D says software used in a new installation must satisfy the level assigned for that proposed installation.

The correct target is not the highest level your team can afford or the lowest level it can argue for. It is the level the installed system’s safety analysis supports.

What the software level changes

A higher level does not mean the software performs a more complicated function. It means the program needs stronger assurance that errors have been prevented, detected, and addressed in proportion to the possible safety effect.

The assigned level determines which DO-178C objectives apply. It also affects where independence is expected and which life-cycle data must support the compliance showing. The impact reaches planning, requirements, design, coding, integration, verification, configuration management, quality assurance, and certification liaison—not just final testing.

That is why the software level is a major cost and schedule driver. Assuming a higher level than the safety assessment supports creates unnecessary work. Assuming a lower level can leave the team with plans, reviews, tests, tools, and records that are insufficient for the assigned failure effects.

AeroCert’s article What does DO-178C certification cost a small company? explains how software level fits with verification, tool qualification, planning, and other cost drivers. The important connection is that the cost follows the justified assurance work; the budget does not set the level.

The level also influences—but does not completely determine—the FAA’s review involvement. FAA Order 8110.49A says the review scope depends partly on software level and also on factors that include complexity, novelty, design, and project circumstances. A Level A project does not receive its exact review plan from the letter alone, and a lower-level project is not automatically simple.

Get the level right early enough that your team can plan the right objectives, independence, data, tools, and reviews from the beginning.

How to establish the level before your plans harden

Start above the software. Identify the aircraft and system functions your software implements, monitors, protects, or influences. Then connect those functions to the failure conditions, classifications, and architectural assumptions in the safety assessment.

Before treating the level as settled, make sure your team can answer these questions:

• Which aircraft or system functions depend on this software?
• What failure conditions can result from lost, incorrect, untimely, or misleading behavior?
• How were those failure conditions classified?
• Which mitigations are credited, who controls them, and how is their independence supported?
• Can the software contribute to more than one failure condition?
• Which failure condition drives the minimum software level?
• Does a supplier’s proposed level agree with the installation-level safety assessment?
• Where is the rationale recorded, and how does it trace into the software plans?

For projects using SAE ARP4754A, FAA AC 20-174 recommends documenting proposed FDALs, IDALs, their justifications, and associated objectives in the certification plan and coordinating them early with the certification authority. The software level and its basis should also be visible in the Plan for Software Aspects of Certification, commonly called the PSAC, and remain consistent with the system safety data.

Early coordination matters when the assignment depends on novel functions, complex integration, reused software, unusual architecture, or assumptions controlled by another organization. The authority or an authorized representative does not perform the applicant’s safety analysis, but early review can expose a disagreement before the software process is built around the wrong level.

Keep the assignment under change control. If the function, installation, interface, architecture, mitigation, or safety classification changes, revisit the software level and the affected plans and life-cycle data.

Finally, make the decision easy to audit. A reviewer should be able to move from the software component to its functions, from those functions to the relevant failure conditions, and from the severity classifications to the assigned level without relying on undocumented team knowledge. AeroCert’s guide to what the FAA examines during Stage of Involvement reviews shows how that evidence is examined as the program matures.

Your software level is a result of the installed system’s safety analysis: establish it from credible failure effects, document the assumptions behind it, and let the level drive the assurance plan—not the other way around.

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 assigned level. 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 4.1, 7.1, and 8.4.2.
• FAA AC 25.1309-1B, System Design and Analysis, for transport-category airplane guidance on failure-condition classification and development assurance.
• FAA AC 20-174, Development of Civil Aircraft and Systems, especially paragraph 7 on early coordination and documenting proposed FDALs, IDALs, and their justifications.
• FAA Order 8110.49A, Software Approval Guidelines, for factors used to determine FAA software-review involvement.
• RTCA DO-178C, the software-development-assurance standard recognized by AC 20-115D. Section 2.3 and Annex A contain the detailed software-level framework and objectives; no proprietary standard text is reproduced here.

This article is educational guidance. It does not replace the applicable certification basis, project-specific safety assessment, FAA coordination, a qualified authorized representative, or an FAA finding of compliance.

Last time, we told you how software earned its wings — from a Moon computer bolted into a fighter jet in 1972, to the digital systems flying nearly every modern airliner. And we left you with the question that kept aviation’s engineers up at night: software had proven it could fly, but how do you prove it’s safe to fly — every flight, for everyone?

This is the story of the answer: a rulebook that has been quietly growing up alongside software itself for more than forty years.

A Question Nobody Had Answered Before

Aircraft had always been made of things you could inspect — metal you could x-ray, cables you could tug, rivets you could count. But software is different. You can’t x-ray a line of code. You can’t tug on a function to see if it holds.

So in the early 1980s, the aviation community sat down together to write down, for the first time, what it should take to trust airborne software. The result, published in 1982, was a document called DO-178, “Software Considerations in Airborne Systems and Equipment Certification.” It described, in broad strokes, what a company should do to show its software could be trusted. It was a starting point, and like most first drafts, it was incomplete. But it established something profound: software wouldn’t be trusted because someone said so. It would be trusted because of evidence.

(Who exactly “sat down together,” and under whose roof? That’s a story with a surprising twist — and it’s getting its own article next time.)

DO-178A: Learning by Doing

Just three years later, in 1985, came the first major revision: DO-178A. Companies had tried to follow the original, regulators had tried to apply it, and both sides had learned where it was vague or impractical. The revision sharpened the expectations — and it answered a need the FAA itself had voiced: one unified standard the whole industry agreed upon, so that certification expectations meant the same thing to every company and every reviewer.

Think of it like the first edition of a cookbook versus the second: the recipes are recognizable, but the second edition tells you why the dough needs to rest, because too many readers skipped that step and wondered why their bread failed.

DO-178B: The Big Rewrite

By the early 1990s, something fundamental had changed. Software had moved from the margins of flight toward its center — managing engines, displays, and flight controls. The stakes had grown, and in 1992 the rulebook grew to match: DO-178B, a thorough rewrite rather than a touch-up.

DO-178B refined the framework we showed you earlier in this series into the form used today: five software levels, matching the rigor of the evidence to the severity of what could go wrong if the software failed. Earlier versions had sorted software into a few broad criticality categories; DO-178B sharpened this into the Level A through E system, where software whose failure could be catastrophic faces the most demanding scrutiny, and software whose failure is merely inconvenient faces less. Every objective a company must meet traces back to that simple, powerful idea.

DO-178B proved remarkably durable. It guided the software on aircraft you have almost certainly flown on, and for nearly two decades, it was the rulebook.

DO-178C: New Tools, New Questions

Then software engineering itself evolved, and the rulebook needed to catch up — not because DO-178B had failed, but because engineers were building software in ways its authors had never imagined. In 2011, after years of work by a joint international committee, came DO-178C, the generation in use today.

Four changes stand out:

Software was now building software. Engineers used powerful tools to generate and check code automatically. That raises a wonderfully recursive question: if a tool helps create your safety evidence, how do you know you can trust the tool? DO-178C added a companion document, DO-330, just for qualifying those tools.

Engineers were designing with models. Instead of writing code line by line, many teams now describe a system’s behavior in graphical models and generate code from them. A supplement, DO-331, sets the rules for keeping that path trustworthy.

Programming itself had modernized. Object-oriented techniques — the way most of the world’s software is now written — organize code so it’s easier for humans to read, easier to test, and easier to trace back to the requirements it exists to satisfy, keeping the code closer to its intended design. Supplement DO-332 shows how to bring those modern techniques into certified airborne software.

Mathematics could now prove things testing couldn’t. Formal methods — using mathematical proof to demonstrate that software behaves correctly — matured from academic curiosity to practical technique, and supplement DO-333 sets out how proofs can serve as certification evidence.

Same philosophy, same software levels — but with answers for the way software is actually built now.

Why Old and New Coexist

Here’s the part that surprises people, and it connects to where this series began: the arrival of DO-178C did not outlaw DO-178B.

An aircraft certified under an earlier version remains certified. Its software earned its evidence under the rules of its day, and that evidence still stands. It’s like building codes: a house built soundly to the 1992 code doesn’t become illegal when the code is updated — but if you tear out a wall and renovate, the renovation must meet today’s code.

Aviation works the same way. Keep proven software unchanged, and it flies on under its original certification. Make a significant enough change, and you may be required to step up to the modern standard — bringing the new evidence, new tools, and new scrutiny that come with it. Deciding when a change crosses that line is one of the most consequential judgment calls in aviation software, and it’s made deliberately, case by case, with the regulator involved.

What This Means When You Fly

Forty years, four generations, one unchanged principle: trust must be earned with evidence, and the amount of evidence must match the stakes.

DO-178 grew up the way good institutions do — slowly, by consensus, keeping what worked and updating what the world outgrew. But that word “consensus” hides the best part of this story. Who writes a rulebook that aircraft makers, their competitors, their suppliers, and their regulators all agree to follow? Not a company. Not even a government.

A nonprofit. And that story — nearly a century old — is what we’ll tell you next time.

---

At AeroCert Institute, we believe everyone — passengers, students exploring aerospace careers, and small businesses bringing new ideas to the skies — deserves to understand the systems that keep flight safe. Every article we publish is free, with no paywalls and no memberships, and always will be. If you learned something today that you never knew before, that’s exactly the gap we exist to close. Help us reach more people like you — consider supporting our work with a donation.

DO-178C compliance has no fixed price. The cost of certifying airborne software is driven by its Design Assurance Level, the number of objectives that level requires, the verification and tool-qualification effort behind them, and how early you coordinate with the FAA. For a small company, planning discipline — not headcount — is usually the biggest cost lever.

By AeroCert Institute — a federally recognized 501(c)(3) nonprofit organization founded by FAA-certified aviation safety professionals. Reviewed July 2026.

What “DO-178C certification” actually means

A common misconception first: the FAA does not certify software on its own. Software is approved as part of the certification of a product — an aircraft, engine, or propeller — or under a Technical Standard Order (TSO) authorization for equipment. DO-178C, Software Considerations in Airborne Systems and Equipment Certification, is the industry standard the FAA recognizes (through Advisory Circular 20-115D) as an acceptable means of showing that your software was developed with the rigor its safety role demands.

So when people say “DO-178C certification,” they really mean: developing and verifying your software against the DO-178C objectives so it can be approved as part of an aircraft or equipment approval. The cost question is really “what does it cost to satisfy those objectives, with evidence?”

Why FAA software certification has no sticker price

Two projects with the same code size can have wildly different certification costs. The drivers:

• Design Assurance Level (DAL). The single biggest factor — it sets how many objectives you must satisfy and how much independence and rigor each one requires (details below).
• Verification effort. Requirements-based testing, reviews, and structural coverage analysis (up to MC/DC coverage at Level A) typically dominate the budget — often more than writing the software itself.
• Tool qualification. If a tool’s output is used without independent verification, the tool itself must be qualified (DO-330). Qualification kits and the work to apply them are a real line item.
• Planning and audits. DO-178C expects a set of plans and standards — starting with the Plan for Software Aspects of Certification (PSAC) — and the FAA typically reviews your project at Stage of Involvement (SOI) audits per FAA Order 8110.49A. Rework discovered at an audit is the expensive kind.
• Experience. First-time applicants pay a learning tax. Experienced staff, designees, or consultants cost money up front but prevent the rework that costs more later.
• The standard itself. DO-178C and its supplements are copyrighted documents purchased from RTCA — budget for the documents your project actually invokes.

The biggest cost driver: your Design Assurance Level

The DAL is assigned from the system safety assessment, based on how severe the failure of your software’s function would be for the aircraft. Each level maps to a set of objectives in DO-178C Annex A — and the objective count is a fair first proxy for effort:

Level	Failure condition	DO-178C objectives
DAL A	Catastrophic	71
DAL B	Hazardous	69
DAL C	Major	62
DAL D	Minor	26
DAL E	No safety effect	DO-178C objectives do not apply

The raw counts understate the difference. Levels A and B also require independence for many objectives — meaning the person or process verifying an item cannot be the one who built it — and Level A adds the most demanding structural coverage criterion (MC/DC). In practice, each step up in level is a step change in cost, which is why getting the DAL right (not conservatively wrong) matters so much. For how that assignment is actually made — and why it comes from the installed system’s safety analysis rather than from your code — read what decides your DO-178C design assurance level.

Where small businesses overspend on FAA certification

• Writing plans after the code. Retrofitting a process onto finished software means re-doing reviews, traces, and tests to generate the evidence the plans promise.
• Assuming a higher DAL than the safety assessment requires. “We’ll just do Level A to be safe” can double the verification bill for no certification benefit.
• Buying tools before defining the process. A tool only saves money when it fits the lifecycle you actually run — and some purchases quietly add a DO-330 qualification obligation.
• Discovering coverage and traceability gaps late. Gaps found at SOI 3 or 4 mean re-testing under schedule pressure.
• Treating certification as end-of-project paperwork. DO-178C is a development-lifecycle standard; the evidence must be produced as you go, not reconstructed at the end.

How a small company keeps DO-178C costs down

1. Let the system safety assessment set the DAL — and challenge inherited assumptions before accepting a higher level.
2. Write the PSAC early and get agreement with your FAA office or designee before heavy development starts.
3. Make requirements testable from day one — verification cost is mostly determined by requirement quality.
4. Qualify only the tools that need it; independent verification of a tool’s output is often cheaper than qualification.
5. Run a gap checklist against the objectives before each SOI review, so auditors find a clean story instead of surprises.

Free FAA certification resources for small businesses

AeroCert Institute is a 501(c)(3) nonprofit built for exactly this problem: free, plain-language education on FAA software certification for small businesses, students, and the public. We maintain a library of 35+ DO-178B/C review checklists, and our small business support program starts with a free public-tier checklist library you can run against your own project today. More plain-language explainers are on our Articles page.

Primary sources

• FAA AC 20-115D — Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ): the FAA’s recognition of DO-178C as an acceptable means of compliance.
• FAA Order 8110.49A — Software Approval Guidelines: how the FAA oversees software projects, including Stage of Involvement reviews.
• 14 CFR Part 21 — Certification Procedures for Products and Articles: the regulatory framework software approval lives inside.
• RTCA DO-178C — Software Considerations in Airborne Systems and Equipment Certification: the standard itself, available for purchase from RTCA.

Last time, we promised you the story of how aviation’s software standards came to be. But every rulebook is written in response to something — and before there could be rules for software in the sky, software had to get there first.

So this is the story before the story: how a computer built to reach the Moon ended up flying an airplane over the California desert, and why that flight changed what it means to be safe in the air.

It’s a story with fresh resonance right now. Rockets that land themselves upright on ocean barges. Capsules carrying astronauts while millions watch live. A new generation looking up at the sky the way their grandparents did in 1969. Every bit of that modern spectacle flies on software — and the question of whether software could be trusted with flight was asked, and answered, half a century ago, by people improvising with a Moon computer and a borrowed fighter jet.

Before Software: Machines That Could Almost Think

Pilots have had mechanical help for over a century. As early as 1914, a young engineer named Lawrence Sperry stunned a Paris crowd by flying past the grandstand with his hands raised off the controls — his gyroscopic “autopilot” holding the aircraft steady. For the next several decades, that kind of help was mechanical and analog: gyroscopes, linkages, electrical circuits. Clever machines, but machines that did exactly one thing.

A computer is different. A computer follows instructions — and instructions can be changed, combined, and layered into behavior of almost unlimited complexity. That power is exactly what makes software so useful, and exactly what would eventually make proving its safety so hard.

The first place that power was truly trusted with human lives wasn’t an airplane at all.

The Computer That Went to the Moon

To land astronauts on the Moon, NASA needed navigation and control no human could perform by hand. The answer was the Apollo Guidance Computer, designed at MIT’s Instrumentation Laboratory, with onboard flight software developed by a team led by a young engineer named Margaret Hamilton — who would later be awarded the Presidential Medal of Freedom for that work.

The machine itself sounds almost comical today. It had roughly 38 kilobytes of memory — thousands of times less than a single photo on your phone. Much of its software was physically woven into the hardware: copper wires threaded by hand through tiny magnetic cores, one bit at a time, by skilled workers — many of them women — at a Massachusetts factory. A bug couldn’t be patched with a download. The program had to be right before it was woven.

And then, during the most famous landing in history, the software proved exactly why it deserved trust. As Apollo 11 descended toward the Moon, the computer began throwing alarms — it was being flooded with more work than it could handle. But Hamilton’s team had designed the software to recognize overload, shed its least important tasks, and keep doing the critical ones: flying the spacecraft. The landing continued. The software had not just worked; it had failed gracefully, exactly as designed.

Remember that phrase. Decades later, designing for graceful failure would sit at the heart of every aviation software standard.

“I Just Went to the Moon With One”

After Apollo 11, Neil Armstrong took a desk job — head of aeronautics research at NASA. And he brought an idea with him: if a digital computer could be trusted to land on the Moon, it could be trusted to fly an airplane.

This was a radical proposition. Aircraft control systems were mechanical — rods, cables, and hydraulics physically connecting the pilot’s hands to the control surfaces. Replacing all of that with a computer and electrical wires (a concept called “fly-by-wire”) meant asking pilots to bet their lives on code. When engineers and pilots hesitated, Armstrong’s reply was hard to argue with: he had just been to the Moon with one.

NASA approved the project, and engineers at the Flight Research Center in California took a Navy F-8 Crusader fighter jet, removed its mechanical control system entirely, and installed an Apollo spacecraft computer in its place — literally the same kind of machine that had flown to the Moon, repurposed to fly an airplane.

May 25, 1972

On that morning, NASA research pilot Gary Krier took off from Edwards, California, in the first aircraft ever controlled by a digital computer — with no mechanical backup. If the software failed, there was only an analog emergency system between him and the desert floor.

It was never needed. Not on that flight, and not once across the program’s 210 flights over the next 13 years. The F-8 program did more than prove a concept; it carefully documented what worked and what didn’t — which design techniques produced trustworthy systems, how a computer could tolerate real faults and keep flying. It was, in a sense, aviation’s first body of evidence about software safety, gathered years before anyone wrote a standard requiring it.

Software Spreads Its Wings

Through the late 1970s and early 1980s, digital systems moved from research aircraft into the airliners you and your family actually fly. Flight management computers began handling navigation and fuel planning. Electronic “glass cockpit” displays began replacing walls of mechanical gauges. In 1988, the first airliner flown entirely by digital fly-by-wire entered service, and in 1994 a second major airliner family followed. Today, essentially every modern transport aircraft trusts software with functions that once belonged to cables and hydraulics.

Each step brought real benefits — smoother flights, better fuel efficiency, fewer opportunities for certain kinds of human error. But notice what else was happening: with each step, software was taking on responsibilities where failure was less and less acceptable. A navigation hiccup is an inconvenience. A flight-control failure is not.

The Question That Demanded an Answer

By the early 1980s, aviation faced a problem unlike any in its history. The industry knew how to prove a wing was strong — you could x-ray the metal, tug the cables, count the rivets, and ultimately bend a test wing until it broke. But you can’t x-ray a line of code. You can’t tug on a function to see if it holds. Software doesn’t wear out, corrode, or fatigue — when it fails, it fails because of a flaw that was always there, woven in from the beginning, waiting for the one situation nobody thought to test.

Software had proven it could fly. Now the question became urgent: how do you prove it’s safe enough to fly — every flight, for everyone?

Answering that question would take the better part of a decade, draw in engineers from across the entire industry, and produce one of the most quietly successful rulebooks ever written.

That’s where we’ll pick up next time.

---

At AeroCert Institute, we believe everyone — passengers, students exploring aerospace careers, and small businesses bringing new ideas to the skies — deserves to understand the systems that keep flight safe. Every article we publish is free, with no paywalls and no memberships, and always will be. If you learned something today that you never knew before, that’s exactly the gap we exist to close. Help us reach more people like you — consider supporting our work with a donation.

When your smartphone needs an update, you tap a button, wait a few minutes, and you’re done.

If only aviation worked that way.

Airplanes rely on software too — millions of lines of it — but updating that software is nothing like updating an app. In fact, some aircraft still fly safely today using software certified under standards written decades ago.

So why doesn’t aviation “just update everything” to the newest version?

The answer reveals something important about how safety-critical systems work.

Safety First, Convenience Second

In aviation, software updates aren’t about adding new features or fixing a glitchy screen. They’re about ensuring that every function tied to flight — from engine control to navigation — behaves exactly as expected, every time, without exception.

A single unintended change could have serious consequences. That’s why aviation uses a structured system of software safety levels. At the most critical end, a Level A failure could cause the loss of the aircraft. Level B covers hazardous failures. Level C, major failures. Level D, minor ones. And Level E covers software whose failure has no meaningful effect on safety at all.

The higher the safety level, the more rigorous — and the more carefully guarded — the certification process.

Old Standards, Proven Aircraft

Many aircraft flying today were originally certified under the standards in place at the time they were built. Those standards were the best available — and they produced aircraft with exceptional safety records that continue to this day.

When a plane is certified, its software becomes part of a tightly controlled safety ecosystem. Changing that software isn’t just a matter of rewriting code. It can trigger a cascade of required work: new testing, new documentation, new safety analyses, new independent reviews, and new regulatory approvals. In some cases, even a modest change requires the software to be evaluated against a newer, more demanding standard — similar to how renovating a building might require meeting the latest fire code, even if the original construction was perfectly sound.

This is why legacy software can remain in service for decades. If it’s safe, stable, and performing correctly, aviation doesn’t change it lightly. Stability isn’t a flaw — in safety-critical systems, it’s a virtue.

When Updates Do Happen

Of course, aircraft software does get updated — but only when necessary, and only after careful evaluation. Engineers must work through a deliberate set of questions: What exactly changed? Which safety level does it affect? Could the update introduce new risks that didn’t exist before? Does the scope of the change require stepping up to a newer certification standard altogether?

Sometimes the safest choice is to keep the existing, proven software exactly as it is. Other times, the nature of the change demands a more rigorous process — and aviation has a modern framework for exactly that. But that framework, and what makes it different, is a subject that deserves its own explanation.

Why This Matters to You

Understanding why aircraft software updates are so carefully controlled helps explain why aviation is one of the safest forms of transportation ever created.

The next time you settle into your seat at 35,000 feet, the software managing the engines beneath you was reviewed through a process most passengers have never heard of. That process works — quietly, invisibly, on every flight. And most people will go their whole lives never knowing it exists.

It also highlights something most people never realize: aviation safety isn’t just about building new things — it’s about preserving what already works, and changing it only when the evidence says you must.

So the next time you board a flight, the software beneath your feet may be older than your smartphone. That’s not a warning. That’s the point.

And when the industry does decide it’s time to raise the bar — to define what modern aviation software certification looks like — the process for doing that is one of the most thorough and carefully considered standards ever written. That’s the story we’ll tell next.

At AeroCert Institute, we believe everyone — passengers, students exploring aerospace careers, and small businesses bringing new ideas to the skies — deserves to understand the systems that keep flight safe. Every article we publish is free, with no paywalls and no memberships, and always will be. If you learned something today that you never knew before, that’s exactly the gap we exist to close. Help us reach more people like you — consider supporting our work with a donation.

Have you ever settled into your airplane seat, buckled your seatbelt, and wondered — how do I know this plane is actually safe? It’s a question more people should ask, and the answer is more fascinating than you might think.

The truth is, keeping you safe in the air isn’t just about well-trained pilots or sturdy aircraft frames. A huge part of modern aviation safety comes down to something most passengers never think about: software.

Your Flight Runs on Millions of Lines of Code

Today’s commercial aircraft are essentially flying computers. From the moment a plane pushes back from the gate to the moment it touches down, software is making thousands of decisions every second — controlling engines, managing navigation, monitoring systems, and alerting pilots to potential problems.

Think of it like this: if a modern aircraft were a smartphone, it would have hundreds of apps running simultaneously, all of them safety-critical, none of them allowed to crash.

So who makes sure all that software actually works — and works safely?

Enter the FAA

The Federal Aviation Administration (FAA) is the U.S. government agency responsible for regulating civil aviation. One of its most important jobs is making sure that every piece of software on a commercial aircraft meets strict safety standards before that plane ever carries a single passenger.

This process is called aviation software certification, and it is one of the most rigorous software review processes in the world.

Before any safety-critical software can be approved for use on a commercial flight, it must be tested, documented, and reviewed against a detailed set of standards. Independent experts verify that the software does exactly what it is supposed to do — and nothing else. Every possible failure is considered. Every risk is evaluated.

It is a long, expensive, and highly technical process. But it is also the reason that commercial aviation remains one of the safest forms of transportation on earth.

Why Does This Matter to You?

You might be thinking — this sounds like something for engineers and regulators to worry about, not everyday passengers. But here is why it matters to everyone:

Every time you fly, you are trusting that this process worked.

You are trusting that the software controlling the engines was reviewed by qualified experts. You are trusting that the navigation system was tested against thousands of failure scenarios. You are trusting that the people who built and certified that software followed the rules — and that someone was watching to make sure they did.

That trust should be informed. And right now, most of the public has no idea this process even exists.

The Knowledge Gap Is a Safety Gap

Here is something that concerns us deeply at AeroCert Institute: the aviation software certification process is largely invisible to the public, to students considering aerospace careers, and even to small businesses trying to bring innovative aviation products to market.

This knowledge gap creates real problems:

• Students who could contribute to aviation safety don’t pursue it because they don’t know the opportunity exists
• Small businesses with promising aviation innovations struggle to navigate the certification process without guidance
• The public cannot advocate for stronger safety standards they don’t know about

At AeroCert Institute, we believe that an informed public is a safer public.

What We Are Doing About It

AeroCert Institute Inc. is a federally recognized 501(c)(3) nonprofit organization dedicated to making aviation safety knowledge freely accessible to everyone.

We provide free, plain-language resources that explain FAA regulations and software safety requirements — not just for industry professionals, but for students, small businesses, curious citizens, and anyone who has ever wondered what really keeps their flight safe.

We are building a future where aviation safety knowledge is not locked behind expensive consultants or technical jargon — where anyone with a question can find a trustworthy answer.

Because safer skies start with an informed community.

How You Can Help

AeroCert Institute runs entirely on the generosity of donors who believe, like we do, that public safety education should be free and accessible to all.

Your donation — no matter the size — helps us create more free resources, reach more students, and support more communities who deserve to understand the systems keeping them safe every time they fly.

Donate today and help us keep the skies safe for everyone.

---

AeroCert Institute Inc. is a federally recognized 501(c)(3) nonprofit organization. EIN: 41-5311291. All donations are tax-deductible to the extent permitted by law.

Have a question about aviation safety? Contact us at info@aerocert.org