Airborne electronic hardware lifecycle data
DO-254 hardware lifecycle data evidence review for modifiers
A DO-254 hardware lifecycle data evidence review checks that the hardware plans, design data, verification results, and configuration records support the design assurance level assigned to the electronic hardware. It is run for aircraft modifiers before a submittal, in a finding response on hardware assurance, or when a change alters the hardware or its DAL. The review targets the design assurance activities the assigned level requires that the data does not evidence, and hardware data that supports a lower level than the function needs. You get a gap list keyed to the DAL, an evidence map across the hardware data, and a closure order.
When this review is needed
- A submittal includes complex electronic hardware whose data must support its assigned DAL.
- A finding questioned whether the hardware design assurance evidence reaches the required level.
- A change modified the hardware or its DAL and the lifecycle data was not re-checked.
- The hardware relies on advanced verification methods whose supporting rationale needs an independent read.
The problem
DO-254 sets the design assurance activities expected at each level, and the hardware data package is meant to evidence them. The design data, the verification results, and the configuration records are produced by hardware teams focused on making the part work, not on which level-driven activity each artifact is meant to satisfy. The package can be technically excellent and still leave a level-required activity, such as elemental analysis or a specific verification independence, without the evidence the assigned DAL expects.
What gets reviewed
- The assigned design assurance level checked against the function's failure-condition classification
- Hardware plans checked to define the design assurance activities the assigned level requires
- Design data checked to be captured and controlled to the level's expectation
- Verification results checked to satisfy the required activities with the required independence
- Advanced verification methods, where credited, checked for their supporting analysis and rationale
- Configuration and release records checked to control the hardware baseline the data describes
What gets validated
- The assigned DAL matches the failure condition the hardware function contributes to
- The hardware plans define every design assurance activity the level requires
- Verification results satisfy the required activities at the required independence
- Advanced verification credited to the package carries its supporting analysis
- Configuration records fix the hardware baseline the verification results were taken against
Evidence normally required
- The hardware lifecycle data: plans, design data, verification results, and configuration records
- The assigned DAL and the safety rationale behind it
- The requirements the hardware implements
- Any advanced verification analyses credited in the lifecycle
- Configuration and release records for the hardware baseline
Common discrepancies
- Verification results that meet a lower DAL than the function's assigned level requires
- A required design assurance activity, such as elemental analysis, without supporting evidence
- Advanced verification credited without the analysis that justifies the credit
- Configuration records that do not fix the baseline the verification was run against
What is at stake
Hardware data that supports a lower DAL than the function requires is a finding that reaches the heart of the safety case, and closing it late can mean regenerating verification or adding an advanced-verification analysis that the schedule was not built to hold. A single misjudged level can pull an otherwise sound design back into the assurance activities it skipped.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Confirm the DAL
Check the assigned design assurance level against the failure condition the hardware function contributes to.
Map activities to data
Set the design assurance activities the level requires against the plans, design data, and verification records.
Screen advanced methods and baseline
Confirm credited advanced verification carries its analysis and that configuration records fix the tested baseline.
Deliver activity gaps
Return the unmet activities with an evidence map and a closure order that clears assurance-blocking gaps first.
What the buyer receives
Who uses the output
- STC program managers judging whether the hardware data will meet its DAL
- Certification engineers answering a finding on hardware design assurance
- Engineering leads scheduling the verification or analysis the gaps expose
How the work fits into the transaction or program
Hardware lifecycle data underpins the compliance claim for any function the electronic hardware implements. Checking it against the assigned DAL before submittal keeps the assurance case from resting on a design that is technically strong but short of the level-driven activities the function's classification demands.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-254 for complex electronic hardware and both tie the DAL to the system safety assessment. The review checks the level against the failure classification the governing basis recognizes and applies that authority's expectation for advanced-verification justification.
Regulatory limits
This review checks the modifier's hardware lifecycle data. It does not perform hardware verification, does not make a compliance finding, and does not determine airworthiness. Hardware assurance acceptance remains with the authority.
What this review does not cover
- Performing hardware verification or generating design data
- Producing advanced-verification analyses for the modifier
- Re-authoring the hardware plans or configuration records
Specific to this review
- A technically excellent hardware design can still miss its DAL, because design quality and level-driven assurance activities are separate things.
- Elemental analysis and other level-specific activities are the usual omissions, since they serve assurance rather than making the part function.
- Advanced verification methods are only creditable with their justifying analysis, and that analysis is where credit is most often assumed rather than shown.
- Configuration records that do not pin the exact baseline undermine every verification result taken against the hardware, regardless of the results' quality.
Sources
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
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
The hardware works and passed all our tests. Is the DAL still a concern?
It can be. DO-254 expects level-driven assurance activities beyond functional testing, such as elemental analysis at higher levels. A working, well-tested part can still lack the evidence for an activity its assigned DAL requires, which the review surfaces.
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.
Talk through the aircraft, records, evidence, deadline, and next useful step.