DAL allocation
Development-assurance level allocation under ARP4754B
Development-assurance level allocation traces how each function and item gets its DAL from the failure-condition classification under ARP4754B, and checks that any DAL reduction claimed from architecture actually holds. It is used by system teams whose levels were set early and may not reflect the safety assessment or the independence the architecture assumed. The work follows the allocation from failure condition through function to item and tests each reduction against the independence behind it. You receive a DAL allocation trace and a list of the allocations the safety data does not support.
When this review is needed
- A safety assessment moved a failure-condition classification and the DAL allocation has to be re-traced from the top.
- A DAL reduction was claimed from independent implementations and the team needs to confirm the independence is real.
- Software and hardware levels were set before the system DAL allocation was settled and need to be reconciled to it.
- A new function was added late and the team needs to know what it does to the allocation above and below it.
The problem
ARP4754B allocates assurance from the top: a failure condition gets a classification, the classification sets a function DAL, and the function DAL flows down to the items that implement it. The chain is only as sound as its weakest link, and the link most often weak is the reduction claim. Teams take a lower item DAL on the strength of independent or dissimilar implementations, then the architecture turns out to share a resource, a clock, or a power source that quietly couples them.
What gets reviewed
- Failure-condition classifications and the function DALs they drive
- Allocation of function DAL down to item DAL across the architecture
- DAL reduction claims based on independence between implementations
- The independence and dissimilarity the architecture assumes for any reduction
- Shared resources that could couple implementations claimed to be independent
- Reconciliation of allocated item DALs with the software and hardware levels assigned
What gets validated
- Each function DAL traces to a failure-condition classification in the safety assessment
- Item DALs follow from the function DAL allocation rather than being set independently
- Any DAL reduction is backed by the independence the architecture actually provides
- Implementations claimed independent do not share a resource that defeats the claim
- Independence claims are visible in the design, beyond an assertion in the plan
- Allocated item DALs match the software and hardware levels the program assigned
Evidence normally required
- The functional hazard assessment and failure-condition classifications
- The architecture and the functional and item allocation
- Any DAL reduction rationale and the independence it relies on
- The resource, power, and timing dependencies the architecture carries
- The assigned software and hardware levels for the items involved
Common discrepancies
- A DAL reduction claimed from independence the architecture does not actually deliver
- Implementations counted as independent that share a clock, bus, or power source
- Item DALs set directly rather than allocated from the function DAL above them
- A failure-classification change that never propagated down to the item allocations
- Software and hardware levels inconsistent with the item DAL the allocation produced
What is at stake
A DAL reduction that the architecture does not actually deliver collapses on review, and every item below the reduced function inherits the higher level it was scoped away from. The software and hardware programs that built to the reduced level then face a level uplift with the data already produced, which is the most expensive point at which to discover it.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Anchor the top
Tie each function DAL to a failure-condition classification in the safety assessment.
Follow the flow
Trace the function DAL down to the item DALs the architecture allocates it to.
Test the reductions
Check every claimed reduction against the independence and shared resources the design actually carries.
Reconcile the levels
Confirm the allocated item DALs match the software and hardware levels assigned, and list what does not.
What the buyer receives
- A DAL allocation trace from failure condition through function to item
- A view of each reduction claim against the independence behind it
- A coupling check on implementations claimed to be independent
- A list of allocations the safety data does not support
Who uses the output
- Systems and safety leads defending the allocation at review
- Software and hardware leads confirming their item levels match the allocation
- Program management sizing any level uplift the findings imply
How the work fits into the transaction or program
The work sits above the software and hardware level mappings, fixing the item DALs they inherit. It pairs with software level objective mapping and hardware design-assurance level mapping when an allocation change re-levels the items those reviews built to.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
Endeavor Elements traces the applicant's DAL allocation and tests its reduction claims. It does not classify failure conditions for the authority, assign DALs on its behalf, or determine that the system is approved.
What this review does not cover
- Classifying failure conditions or assigning DALs on the authority's behalf
- Performing the safety assessment itself
- Making official compliance findings or issuing any approval
Specific to this review
- ARP4754B allocates DAL from failure-condition classification, so a single reclassification can cascade through the function and item allocation.
- A DAL reduction depends on independence that the architecture must actually deliver, which is why unsubstantiated reduction claims are a common allocation finding.
- Two implementations can be independent in the requirements yet coupled in the design through a shared clock, bus, or power source that defeats the reduction.
Sources
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
SAE International. Safety assessment methods (FHA, PSSA, SSA, FTA, FMEA) supporting development assurance level assignment.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
What makes a DAL reduction claim hold up?
The independence the reduction relies on has to be real in the design, not just stated in the plan. The review traces whether the implementations share any resource that would couple their failures, because a shared clock or power source can defeat a reduction that looks sound on paper.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Walk through your situation with an engineer who has done this work.