Skip to main content
Think of DAL as a dosage: the more severe the consequence of failure, the higher the dose of rigor required. A flight control function that could cause loss of the aircraft demands DAL A, the most stringent level. An in-flight entertainment system with no safety effect sits at DAL E and needs no certification objectives at all.

​
The Five Levels

DAL runs from A (highest rigor) to E (no certification required), mapped directly to ARP 4761’s five failure condition classifications: diagram The internal identifiers are dalA through dalE, matching the enum values used in the dalLevel field on safety requirements and the DAL column groups in the FHA risksheet.

​
How DAL Is Assigned Automatically

In the Aerospace Safety Solution, DAL allocation is not a manual classification decision — it is computed automatically from the failure condition’s severity classification. The FHA risksheet applies a formula that maps each ARP 4761 classification directly to its corresponding DAL:
Failure Condition Classification→Assigned DAL
Catastrophic→DAL A
Hazardous→DAL B
Major→DAL C
Minor→DAL D
No Safety Effect→DAL E
This deterministic mapping follows the ARP 4761 standard directly. Once an engineer classifies a failure condition, the system propagates that classification into the DAL column without any additional step. This prevents the common error of classifying a failure condition as Catastrophic but inadvertently documenting it as DAL B.

​
From Failure Condition to Safety Requirement

DAL does not just label a failure condition — it flows downstream into every safety requirement derived from that failure condition. When an engineer creates a safety requirement by linking it to a failure condition via the allocatesTo link role, the requirement inherits the DAL level through the dalLevel custom field. This inheritance creates a traceable chain: a Catastrophic failure condition produces DAL A safety requirements, which in turn demand DAL A compliance objectives in DO-178C and DO-254 compliance tracking. The allocatedSubsystem field on the safety requirement captures where in the architecture that requirement is allocated, and verificationMethod (Test, Analysis, Inspection, or Demonstration) records how it will be verified.
The dalLevel on a safety requirement reflects the classification of its parent failure condition. Manually overriding it breaks the traceability chain and will surface as an inconsistency in the Classification Consistency Report.

​
Compliance Objectives Per DAL Level

The practical consequence of a DAL assignment is the set of DO-178C or DO-254 objectives that must be satisfied. The Objectives Compliance Matrix in the Aerospace Safety Solution tracks these objectives per standard per DAL level, using four separate status fields — dalAStatus, dalBStatus, dalCStatus, and dalDStatus. Each status field is independently tracked with five states:
  • Not Applicable — this objective does not apply to this item
  • Not Started — work has not begun
  • In Progress — partially addressed
  • Satisfied — evidence is in place and accepted
  • Waived — a DER (Designated Engineering Representative) waiver has been granted
The fifth level — DAL E — has no corresponding status column. There is no dalEStatus field because DAL E items carry zero certification obligations.

​
A Common Misconception: DAL Is Not a Risk Score

DAL is often confused with risk priority numbers or severity ratings from other domains. In automotive FMEA, a severity score feeds into an RPN calculation; in MIL-STD-882E, hazard risk indices combine probability and severity. DAL works differently. DAL is a development process requirement, not a risk ranking. A DAL A assignment does not mean the component is more dangerous than a DAL B component — it means the development process that produced the component must satisfy a defined set of rigor objectives. Two functions with identical operational risk profiles may have different DAL assignments if one is software-implemented and the other is hardware-implemented, because DO-178C and DO-254 apply different objective tables.
DAL is derived solely from the severity of the failure condition — not its probability. A failure condition classified as Catastrophic requires DAL A regardless of whether its probability target is 10⁻⁹ or 10⁻⁷. The probability target is tracked separately in the FHA risksheet as a distinct column.

​
Visual Consistency Across the Dashboard

The Aerospace Safety Solution uses a consistent color scheme wherever DAL appears, derived from the underlying failure condition classification colors:
  • DAL A → red (Catastrophic)
  • DAL B → orange (Hazardous)
  • DAL C → yellow (Major)
  • DAL D → green (Minor)
  • DAL E → grey (No Safety Effect)
This color consistency means that a safety engineer reading the FHA risksheet, the Objectives Compliance Matrix, and the Certification Readiness Scorecard sees the same visual language throughout — a DAL A row is always red, whether it appears in a failure condition table, a safety requirement list, or a compliance status chart. Compliance status coloring follows a separate convention: Satisfied is green, In Progress is yellow, Not Started is red, Not Applicable is grey, and Waived is blue. These two color systems — DAL severity colors and compliance status colors — operate independently and should not be conflated.
Code: .polarion/tracker/fields/dal-enum.xml (0.73) · modules/RiskTemplates/FHATemplate/attachments/risksheet.json (0.56) · .polarion/tracker/fields/complianceObjective-standard-enum.xml, complianceObjective-status-enum.xml, complianceRequirement-complianceStatus-enum.xml, complianceRequirement-evidenceType-enum.xml (0.54) · .polarion/nextedy/models/rtm.yaml (0.53) · .polarion/tracker/fields/safetyRequirement-custom-fields.xml (0.53) · .polarion/nextedy/sheet-configurations/DO-178C Objectives Compliance Matrix.yaml (0.49) · .polarion/pages/spaces/_default/Standards Compliance Overview/page.xml, Certification Readiness Scorecard/page.xml, Compliance Matrix/page.xml (0.48) · .polarion/tracker/fields/complianceObjective-custom-fields.xml (0.47) · .polarion/tracker/fields/testCase-custom-fields.xml, desReq-custom-fields.xml, processStep-custom-fields.xml, characteristic-custom-fields.xml, systemElement-custom-fields.xml, commonCauseEvent-custom-fields.xml, riskControl-custom-fields.xml, task-custom-fields.xml, custom-fields.xml (0.47) · .polarion/tracker/fields/classification-enum.xml (0.47)