Author: AeroCert Institute

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:

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.

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