If you have just been told that your software has to be DO-178C compliant, this page is written for you. It assumes you are a competent engineer who has never worked under an airborne software standard before, and it explains what the standard actually asks for, what you will have to produce, who checks it, and where programmes typically lose time.
It is deliberately practical rather than exhaustive. Later articles cover each part in detail.
What DO-178C actually is — and what it isn't
DO-178C, Software Considerations in Airborne Systems and Equipment Certification, is published by RTCA, and as ED-12C by EUROCAE in Europe. Certification authorities — the FAA, EASA, and Transport Canada Civil Aviation — accept compliance with it as an acceptable means of showing that airborne software is fit to fly.
Three things it is not, all of them common first misconceptions:
- It is not a coding standard. It never tells you to avoid a particular language construct or to cap function length. It requires you to have a coding standard and to show that you followed it.
- It is not a development process. It does not mandate waterfall, a V-model, or anything else. It defines objectives and the evidence that satisfies them; how you sequence the work is yours to plan and to justify.
- It is not a software quality measure. It is a design assurance standard. It gives confidence that errors which would cause an unsafe condition have been found and removed — not that the software is elegant, fast, or maintainable.
Where the assurance level comes from
The most common misunderstanding is that a software team picks its own assurance level. It does not. The level is handed down to software from an aircraft- and system-level safety assessment, normally conducted under ARP4754A/B and ARP4761/A.
The chain runs roughly like this. A Functional Hazard Assessment identifies what happens if each function fails and how severe that is. The Preliminary System Safety Assessment allocates requirements and assurance levels down to the items that implement those functions. The System Safety Assessment then confirms, once the design is real, that the objectives were met. Common Cause Analysis runs alongside to check that things assumed to be independent actually are.
The practical consequence: if you think your level is wrong, the conversation is with the systems and safety teams, not with the certification authority. Architectural change at system level — partitioning, monitors, dissimilar redundancy — is the legitimate way to reduce a software assurance level, and it is far cheaper than arguing about it later.
The five Design Assurance Levels
DO-178C defines five software levels, A through E, driven by the severity of the failure condition the software can contribute to.
| Level | Failure condition | Meaning in practice | Objectives (approx.) | Of which with independence |
| A | Catastrophic | Failure would prevent continued safe flight and landing | 71 | 30 |
| B | Hazardous / Severe-Major | Large reduction in safety margins; serious or fatal injury to a small number of occupants | 69 | 18 |
| C | Major | Significant reduction in safety margins; discomfort, possibly minor injuries | 62 | 5 |
| D | Minor | Slight reduction in safety margins; routine increase in crew workload | 26 | 2 |
| E | No safety effect | No effect on operational capability or crew workload | 0 | 0 |
Two things are worth reading out of that table. First, the drop from Level C to Level D is far larger than the drop from B to A — most of the objectives disappear at D. Second, “with independence” is where staffing cost hides: it means the person who verifies an item cannot be the person who produced it, which at Level A applies to roughly thirty objectives and shapes how you size the team.
The lifecycle: what you actually produce
DO-178C organises work into three groups: the planning process; the development processes — requirements, design, code, integration; and the integral processes — verification, configuration management, quality assurance, and certification liaison — which run continuously alongside everything else rather than as a final phase.
The word integral is doing real work there. Teams new to the standard routinely treat verification and configuration management as things that happen after coding. Under DO-178C they start at planning and never stop, and a programme that defers them is a programme that will rework its evidence.
The document set
Planning produces five plans and three standards. Everything downstream is judged against them, which makes planning the cheapest place to get things right and the most expensive place to get them wrong.
| Artifact | What it commits you to |
| PSAC — Plan for Software Aspects of Certification | The top-level agreement with the certification authority: system overview, software level, lifecycle, standards, and how compliance will be shown |
| SDP — Software Development Plan | How requirements, design, code and integration will be produced, and by whom |
| SVP — Software Verification Plan | How reviews, analyses and tests will be conducted, including independence and coverage |
| SCMP — Software Configuration Management Plan | Baselines, change control, problem reporting, archive and retrieval |
| SQAP — Software Quality Assurance Plan | How conformance to the plans is audited, and by whom |
| Requirements Standards | Rules and notation for writing high-level and low-level requirements |
| Design Standards | Rules and constraints for the software architecture and design |
| Coding Standards | Language subset, naming, complexity and construct restrictions |
Verification is more than testing
DO-178C verification is made of reviews, analyses and tests. Testing alone satisfies only part of it. Tests are derived from requirements — not written by reading the code — and each test case traces to the requirement it exercises.
Structural coverage is then measured to answer a different question: not “does the software meet its requirements” but “did my requirements-based tests actually exercise the code, and is there code here that no requirement asked for?” Coverage that will not close is usually telling you about missing requirements, missing tests, or code that should not exist.
| Level | Statement coverage | Decision coverage | MC/DC | Source-to-object code traceability |
| A | Required | Required | Required | Required |
| B | Required | Required | — | — |
| C | Required | — | — | — |
| D | — | — | — | — |
| E | — | — | — | — |
The audits: Stage of Involvement 1 to 4
The certification authority, or its delegate, engages at four points. These are not surprise inspections. They are scheduled reviews of evidence you already have, and the schedule is proposed in your PSAC.
| Stage | Focus | What is really being asked |
| SOI #1 — Planning | Plans and standards | Is the plan credible, complete, and appropriate to the software level? |
| SOI #2 — Development | Requirements, design, code, traceability | Did you follow your own plans and standards? |
| SOI #3 — Verification | Test cases, procedures, results, coverage | Is the verification evidence complete, and does it actually close? |
| SOI #4 — Final | SAS, SCI, open problem reports | Is the software ready, and are the remaining known problems acceptable? |
The supplements
DO-178C was published with companion documents. They do not replace the core standard; they modify and add objectives for a particular technology.
| Document | Applies when | One-line summary |
| DO-330 | You rely on a tool to eliminate, reduce or automate a process | Tool qualification. Determines the Tool Qualification Level (TQL-1 to TQL-5) and what evidence the tool itself needs |
| DO-331 | You develop or verify using models | Model-based development. Defines what a model is in requirements and design terms, and how model coverage relates to structural coverage |
| DO-332 | You use object-oriented languages or related techniques | Adds objectives for inheritance, polymorphism, dynamic memory management and type safety |
| DO-333 | You use formal methods | Allows formal analysis to replace certain tests and reviews, with its own evidence requirements |
Where programmes actually lose time
Across DAL A and DAL C programmes, schedule is rarely lost writing code. It is lost in four places, all of them predictable:
- Traceability debt. Links are recorded late, by hand, from memory. The rework is not the linking — it is discovering, months on, that a requirement was never implemented, or that a piece of code answers to nothing.
- Derived requirements not fed back to safety. Requirements invented during design must go back to the safety assessment. Skipping that is a finding, and it is found late.
- Coverage discovered at the end. Structural coverage run for the first time near the end reliably uncovers dead code, missing tests and requirements gaps all together, at the worst possible moment.
- Late tool qualification. Deciding at verification time that a tool's output will be trusted without qualification evidence is an expensive conversation to have at SOI #3.
None of these are difficult problems. They are all sequencing problems, and all four are cheap to avoid at planning time.
DO-178C in Canada
For Canadian programmes the certification authority is Transport Canada Civil Aviation. The standard is the same document and the objectives do not change, but the approval route, the use of delegates, and the way findings are handled differ from the FAA model that nearly all published DO-178C guidance assumes. Bilateral agreements between Canada, the United States and Europe also govern how an approval granted by one authority is validated by another — which matters a great deal if you are a Canadian supplier selling into a foreign programme, or the reverse.
That is a large enough subject, and badly enough served by the existing literature, that it gets its own article.
Frequently asked questions
Is DO-178C mandatory?
Not in itself. DO-178C is a means of compliance, not a regulation. What is mandatory is showing the certification authority that your airborne software is safe for its intended function. DO-178C is the means that authorities routinely accept, and in practice it is what will be expected of you.
How long does DO-178C certification take?
It depends almost entirely on the software level, and on whether assurance was built in from the start or retrofitted afterwards. DO-178C rarely lengthens a well-planned programme by as much as teams fear, and frequently doubles a badly planned one. Retrofitting evidence onto finished code is the expensive case.
Can we use Agile with DO-178C?
Yes, and many programmes do. DO-178C mandates objectives and evidence, not a lifecycle model. What Agile has to accommodate is that certain artifacts must be baselined, reviewed with independence, and held in configuration management — so the definition of done for an increment has to include its evidence.
What is the difference between DO-178C and DO-254?
DO-178C covers airborne software; DO-254 covers airborne electronic hardware, such as complex programmable devices and FPGAs. They share the design assurance philosophy, and the level assignment comes from the same system safety assessment, but the objectives and the evidence differ.
Does DO-178C apply to drones and eVTOL aircraft?
Where the aircraft is being type certified, yes — the same airworthiness framework applies. What varies is the failure condition severity assigned to a given function on an uncrewed or novel aircraft, which can put software at a different level than the equivalent function on a transport aircraft.
If you are scoping a programme, inheriting one, or preparing for a first Stage of Involvement review, this is exactly the work we do — get in touch.
