Design Assurance Level — DAL — is the single number that decides how much work a DO-178C programme is. It sets how many objectives you must satisfy, how many of them need an independent pair of eyes, and whether you will be measuring MC/DC coverage or nothing at all.
It is also the number teams most often get wrong, usually by assuming it is theirs to pick. It isn't. Here is what the five levels mean, where yours comes from, and what actually changes as you move up.
The five levels at a glance
DO-178C defines five software levels, A through E. The level is driven entirely by one question: if this software contributes to a failure, how bad is the worst credible outcome?
| Level | Failure condition | What that means in the aircraft |
| A | Catastrophic | Would prevent continued safe flight and landing |
| B | Hazardous / Severe-Major | Large reduction in safety margins; serious or fatal injury to a small number of occupants |
| C | Major | Significant reduction in safety margins; discomfort, possibly minor injuries |
| D | Minor | Slight reduction in safety margins; a routine increase in crew workload |
| E | No safety effect | No effect on operational capability or crew workload |
Note the wording throughout: failure condition, not software criticality. The severity belongs to the aircraft-level effect, not to how clever or complex the code is. A trivial piece of software can be Level A and a large, sophisticated one can be Level D.
You do not choose your DAL
This is the most common and most expensive misunderstanding in the whole standard. The software level is an output of the aircraft and system safety assessment, normally conducted under ARP4754A/B and ARP4761/A. It arrives at the software team already decided.
What actually changes between levels
Moving up a level does not mean "do the same work more carefully." It means satisfying more objectives, and satisfying more of them independently.
| Level | Objectives | Of which with independence | Relative to the level below |
| A | 71 | 30 | +9 objectives, but +12 independent |
| B | 69 | 18 | +7 objectives, +13 independent |
| C | 62 | 5 | +36 objectives — the big step |
| D | 26 | 2 | +26 objectives over Level E |
| E | 0 | 0 | No DO-178C objectives |
Read the last column carefully, because it contradicts most people's intuition. The jump everyone fears is C to B to A. The jump that actually reshapes a programme is D to C: thirty-six additional objectives, the arrival of structural coverage, and the first real verification infrastructure. Going from C to A adds far fewer objectives — but it roughly sextuples the ones needing independence, which is a staffing problem rather than a process one.
Independence is the word that costs money
An objective "with independence" means the person who verifies an item cannot be the person who produced it. It is not a statement about departments or reporting lines; it is about the individual.
Two practical consequences. First, a two-person team cannot satisfy Level A by working closely together — the split has to be real and has to be visible in your records. Second, for certain objectives a qualified tool can supply the independence instead of a second engineer, which is one of the few genuine cost levers at the top levels. It is also why tool qualification (DO-330) tends to appear on Level A and B programmes and rarely on Level D ones.
Structural coverage by level
Coverage is where the level shows up most concretely in day-to-day engineering.
| Level | Statement | Decision | MC/DC | Source-to-object code traceability |
| A | Required | Required | Required | Required |
| B | Required | Required | — | — |
| C | Required | — | — | — |
| D | — | — | — | — |
| E | — | — | — | — |
MC/DC at Level A is the requirement people quote most, and it is genuinely demanding for complex boolean logic. But the quieter Level A requirement — showing that object code not directly traceable to source code is verified — is the one that surprises teams, because it depends on the compiler and its options, not on anything the team wrote.
Common mis-scoping mistakes
- Assuming one level for the whole box. A single LRU can host functions at different levels, provided partitioning between them is robust and demonstrated. Levelling everything at the highest function's DAL is a common and very expensive default.
- Treating Level E as "nothing to do." Level E carries no DO-178C objectives, but you still have to justify the classification to the authority. Unjustified Level E is a finding, not a saving.
- Confusing DAL with SIL or ASIL. They come from different standards with different definitions, and they do not map across cleanly. A supplier arriving from automotive or industrial work should assume nothing transfers.
- Forgetting the independence headcount. Level A and B programmes are frequently staffed as if independence were a review step rather than a separate person's job, and discover the gap at SOI #3.
- Fixing the level before the FHA is stable. If the safety assessment moves, the level moves, and the plans you wrote against the old level move with it.
Frequently asked questions
Who assigns the DAL?
It comes out of the aircraft and system safety assessment — the Functional Hazard Assessment establishes the severity, and the system safety process allocates assurance levels down to the items that implement each function. The software team receives it; it does not set it.
Can different parts of the same software be at different levels?
Yes, provided you can demonstrate robust partitioning between them, so that software at a lower level cannot adversely affect software at a higher one. Without that demonstration, everything in the partition is treated at the highest level present.
How much more does Level A cost than Level C?
There is no honest single multiplier, because it depends far more on how the programme was planned than on the level itself. What is predictable is the shape: C to A adds relatively few objectives but sharply increases the independent ones, so the cost lands in staffing and in verification infrastructure rather than in extra process steps.
Is DAL the same as MC/DC?
No. MC/DC is one coverage criterion that Level A requires. The level determines many other things as well — the number of objectives, how many need independence, and whether data and control coupling analysis applies.
What is the difference between DAL and IDAL?
IDAL, item development assurance level, is the term used in the system-level standards for the level allocated to an item. Once that item is software, DO-178C calls it the software level. In everyday programme conversation they are used interchangeably, but the allocation happens at system level and lands on software.
Scoping a programme, or challenging a level that looks wrong for the architecture? That conversation is worth having early — get in touch.
