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.
Leave a Reply