What DAL D actually means for a cabin software team

Most cabin software — passenger controls, in-flight entertainment, the display that shows you the moving map — is developed to DO-178CDesign Assurance Level D. People who have never worked under it tend to hear “Level D” as “the easy one.” People who have worked under Level A tend to agree. Both are missing what it actually changes about how a team works, which is the part that transfers to every other kind of software we build.

Levels are about consequences, not code

DO-178C does not grade software by how complicated it is. It grades it by what happens when it misbehaves. A system safety assessment classifies each failure condition — catastrophic, hazardous, major, minor, no effect — and the software that can contribute to that failure inherits a level from A down to E.

Level D is the “minor” tier: a failure slightly reduces safety margins or slightly increases crew workload, or it produces some inconvenience for passengers. A cabin lighting app that stops responding is a minor failure condition. The flight deck can still fly the aircraft; someone will have to walk down the aisle. That is why cabin systems land at D, and why the flight control computer lands at A.

The difference in effort is not a rounding error. DO-178C lists 71 objectives at Level A and 26 at Level D. Structural coverage analysis — proving that your tests exercised every statement, every decision, every condition — starts at Level C and is not required at D. Independence between the person who wrote a requirement and the person who verified it is not required at D. Low-level requirements, and the verification objectives that hang off them, are largely not applicable at D.

So yes: Level D is less work. What it is not is optional.

What Level D still demands

Strip away the objectives that don't apply and what remains is a small set of habits that most commercial software teams claim to have and almost none actually practise.

• Requirements exist before code, and the code traces to them.You still write high-level requirements, still review them for accuracy and consistency, and every requirement still has to trace to a test that exercises it. The reverse is also checked: code that traces to no requirement is a finding. In a normal product team, “we'll write the ticket after” is a Tuesday. Under DO-178C it is a nonconformance.
• Requirements-based testing is the only kind that counts. Tests exist to demonstrate that a requirement is met — including the requirements about what the software does when its inputs are wrong, late, or missing. Robustness testing is not a nice-to-have at D; it is how you show the software behaves under abnormal conditions. A test that exists because a developer was curious is fine to keep, but it satisfies no objective.
• Configuration management is real.Every artefact — plans, requirements, source, tests, results — is identified, baselined, and change-controlled. You have to be able to state exactly which source, built with exactly which toolchain and options, produced the binary loaded on the aircraft, and to reproduce it. Level D relaxes the control category for many data items, but “we think it was the commit from Thursday” is never an acceptable answer.
• Problems are reported, tracked, and closed — in writing. A problem-report system with a lifecycle is a required part of the process. Every known deficiency at release is listed, assessed for safety impact, and either fixed or explicitly accepted. Nothing is quietly known and unrecorded.
• The plans are written first and followed. The Plan for Software Aspects of Certification tells the authority what you intend to do; the Software Accomplishment Summary at the end shows what you did, and reconciles the differences. If your process changed halfway through, that is fine — as long as you can show that it did, why, and what you did about it.

The part nobody tells you

Here is the uncomfortable truth about Level D: the certification authority is mostly not looking at your code. They are looking at your evidence that you followed your own plans. The gap between a team that ships good Level D software and a team that ships bad Level D software is not the objectives list. It is whether the team treats the discipline as a filing exercise done at the end, or as the way work actually happens.

Done as a filing exercise, Level D is a miserable few weeks of retro-fitting traceability matrices to code nobody fully remembers writing. Done as the way work happens, it is barely noticeable: a requirement is written, it gets an ID, a test references the ID, the commit references the test, the build is reproducible because it has always been reproducible. The overhead is a few percent.

When someone asks “what does this do when the cabin network drops mid-command?” the answer is a requirement, a test, and a result — not an opinion.

Why we keep the discipline when nobody is checking

We build software outside aviation too: compliance platforms, financial data pipelines, fleet systems. None of it goes through a certification authority. All of it is developed the same way, because the Level D habits turn out to be exactly the habits that make software cheap to own.

Requirements-first means the “why” survives the people who wrote the code. Traceability means a change request can be scoped in minutes rather than by archaeology. Reproducible builds mean an incident can be bisected instead of speculated about. A real problem-reporting lifecycle means known issues are known to everyone, including the customer, before they become surprises.

The honest framing is this: DO-178C Level D is roughly the minimum discipline required for software whose failure merely inconveniences people. Most commercial software is developed to a lower standard than that. When we say we bring aviation discipline to non-aviation work, this is what we mean — not clean-room theatre, but the small, boring set of practices that make “it usually works” an unacceptable answer.