The Design Assurance Level is the single most consequential number in a DO-254 program. It determines which processes you must follow, what evidence you must produce, whether an independent reviewer must verify your work, and how much structural coverage your testbench must achieve. Everything in DO-254 — the plans, the reviews, the simulation campaigns — scales with the DAL.
The DAL is not chosen by the FPGA team. It flows down from the aircraft-level safety analysis, driven by the severity of the failure conditions the hardware is associated with. Understanding how that assignment works — and what each level actually demands — is the first thing any FPGA engineer joining an avionics program needs to know.
1. How a DAL Is Assigned
The starting point is the aircraft-level Functional Hazard Assessment (FHA). The FHA asks: what happens to the aircraft and its occupants if this function fails? The answer places the failure condition into one of five severity categories: Catastrophic, Hazardous, Major, Minor, or No Safety Effect. Each category maps to a Design Assurance Level.
The FHA is a system engineering artifact, not an FPGA artifact. An FPGA team typically receives a hardware DAL allocation that has already been decided at the aircraft or system level through a Preliminary System Safety Assessment (PSSA). The FPGA team does not negotiate the DAL — they receive it and must design to it. The only way to reduce the allocated DAL is to change the system architecture so that the hardware failure condition has a lower impact, which requires system-level re-analysis and re-approval.
One FPGA can contain logic associated with multiple DAL allocations — for example, a flight display controller might have DAL-B functions (primary flight data presentation) and DAL-D functions (maintenance logging) on the same die. When this happens, the entire FPGA must be developed to the highest DAL present, unless the functions are formally partitioned with proof that the lower-DAL logic cannot affect the higher-DAL logic under any fault condition.
2. DAL-A — Catastrophic Failure Conditions
DAL-A applies when hardware failure could contribute to a catastrophic failure condition: loss of the aircraft or multiple fatalities. Examples include primary flight control actuator drivers, engine FADEC functions, and fly-by-wire signal processing. DAL-A is the most demanding level and carries the full weight of the DO-254 process.
At DAL-A, every process defined by DO-254 is mandatory with no relaxation. All four hardware plans must be written and reviewed before design begins. Requirements must be complete and bidirectionally traceable to every design element. Structural coverage at the HDL level is required — every statement and branch must be exercised, with modified condition/decision coverage (MC/DC) typically demanded by the certifying authority. Verification independence is mandatory: a separate organization or team must review the design data and verify the test results. The Accomplishment Summary must document every artifact produced.
In practice, DAL-A hardware development costs two to five times more per logic function than equivalent non-certified development. The verification campaign alone — writing test cases to MC/DC coverage, running structural coverage analysis, and conducting independent review — typically consumes more engineering hours than the design itself.
3. DAL-B and DAL-C — Hazardous and Major
DAL-B applies to Hazardous failure conditions: failures that would cause serious injury, large reductions in safety margins, or require abnormal crew procedures to manage. Examples include secondary navigation functions, redundant display channels, and non-primary flight management. DAL-B requirements are close to DAL-A: all plans are required, structural coverage is expected, and verification independence remains mandatory.
The practical difference between DAL-A and DAL-B is in the depth of coverage analysis and the strictness of the independence requirement. Some certifying authorities accept statement and branch coverage (rather than MC/DC) for DAL-B hardware; others do not. Establishing this early with the DER determines the testbench scope.
DAL-C applies to Major failure conditions: failures that significantly reduce safety margins or increase crew workload, but would not be catastrophic or hazardous. Examples include non-essential cockpit systems, tertiary communication functions, and cabin management hardware. At DAL-C, verification independence is not required — the same team that designed the hardware can verify it. Structural coverage is typically required at the statement and branch level. The conceptual and detailed design artifacts are still required, but the review process is less rigorous.
4. DAL-D — Minor Failure Conditions
DAL-D applies to Minor failure conditions: failures that would cause a slight reduction in safety margins or a slight increase in crew workload, with no significant effect on safety. Examples include non-essential passenger amenity systems, informational displays with no flight-critical content, and convenience features with no control authority.
At DAL-D, DO-254 requirements are substantially reduced. The four hardware plans are still required, but the level of detail is lower. Hardware requirements are required, but conceptual and detailed design documentation may be abbreviated or combined. Simulation evidence is expected, but structural coverage analysis is typically not required. No verification independence is required.
DAL-E — No Safety Effect — is the level where DO-254 formally does not apply. Hardware whose failure has no effect on operational capability, safety, or workload requires no DO-254 process. In practice, the system safety analysis must document the rationale for the DAL-E allocation, and that documentation is reviewed during certification. DAL-E is not a free pass; it is a justified classification.
5. The Evidence Matrix
The table below summarizes the key evidence items required at each level. Exact requirements depend on the certifying authority, the DER’s interpretation, and the applicable regulatory basis — but this matrix represents the broad consensus for commercial aviation programs certified under FAA Part 25 or EASA CS-25.
Final Thoughts: The DAL Is Not the Destination
Understanding your hardware’s DAL tells you the scale of the process ahead of you — not whether the hardware is good. A DAL-A FPGA with perfect documentation but a latent timing violation is less safe than a DAL-C FPGA with disciplined RTL and thorough simulation. The DAL defines the minimum process; engineering judgment determines whether that process actually finds the problems that matter.
For engineers new to certified programs: read the Hardware Development Plan for your project before writing a single line of RTL. The plan documents exactly which processes your program will follow, which evidence items will be produced, and what the acceptance criteria are. The plan is the contract. Everything you do — every module, every testbench, every synthesis run — either generates evidence that closes an item in that plan, or it does not count.
Happy coding.
fpgawizard.com
