Development Assurance Levels (DALs) are at the heart of every civil aircraft certification program. Assigned during functional hazard assessments, they dictate the rigour of every engineering process — from requirements capture to final verification. Yet they are frequently misunderstood, misapplied, or used as a simple checklist rather than a risk-based framework.
This article distills lessons from over 18 years working on DAL assignments across commercial jets, regional aircraft, and novel electric propulsion programs, offering a practical perspective for engineers and certification managers navigating ARP4754A.
What is a Development Assurance Level?
A DAL is a label — A through E — assigned to a function (or the system/item that implements it) to indicate how much confidence the certification authority requires that the function will perform correctly and not fail in an unsafe way. The higher the severity of the associated failure condition, the higher the DAL, and the more rigorous the development process must be.
Key insight: A DAL is not a quality level — it is a measure of the confidence required that a development error has not been introduced. This distinction matters enormously when planning your assurance activities.
| DAL | Failure Condition Category | Effect on Aircraft / Occupants |
|---|---|---|
| A | Catastrophic | Prevents continued safe flight and landing |
| B | Hazardous | Large reduction in safety margins or fatal injury to a small number of occupants |
| C | Major | Significant reduction in safety margins or passenger injuries |
| D | Minor | Slight reduction in safety margins or passenger inconvenience |
| E | No Safety Effect | No effect on operational capability or safety |
The Three Most Common Mistakes
1. Confusing system DAL with item DAL
ARP4754A allows DAL allocation from a system function down to the items that implement it. Through independence and redundancy, a DAL B function may be implemented by two DAL C items. Many programmes skip this analysis, unnecessarily inflating cost and schedule by developing everything to the top-level DAL.
2. Treating DAL assignment as a one-time activity
DALs are derived from the Functional Hazard Assessment (FHA), which is a living document. Architecture changes, interface updates, and late-stage requirements additions can all change the failure condition severity — and therefore the DAL. Without a robust change impact process, programmes drift into non-compliance without realising it.
3. Applying DAL E without proper justification
DAL E means the function has no safety effect. This requires rigorous justification: what happens if the function fails in any conceivable way? Assigning DAL E to avoid process overhead is a red flag for any certification authority reviewer.
Practical Recommendations
- Establish your FHA early and keep it under configuration control from day one.
- Conduct DAL allocation analysis at both function and item level before architecture is frozen.
- Involve your DER or PCP in DAL assignments before submitting to the authority — alignment early avoids expensive rework.
- Document your independence arguments carefully; authorities scrutinise these closely at DAL A and B.
- Review DAL assignments at every major programme milestone, not just at certification.
Conclusion
Development Assurance Levels are one of the most powerful tools in the aerospace certification toolkit — when used correctly. The investment in getting DAL assignments right at the start of a programme pays dividends throughout the entire development lifecycle, reducing surprises during Stage of Involvement reviews and authority audits.
If you are planning a new programme or reviewing your current assurance strategy, feel free to reach out — I am happy to discuss how a sound DAL framework can be built into your certification plan from the ground up.