Hardware lifecycle data
DO-254 hardware data evidence review for qualification test teams
A DO-254 hardware lifecycle data review checks that the plans, design data, verification, and configuration records for airborne electronic hardware support the design assurance level assigned to the function. It is run for a qualification test team before submittal, a finding response, or a change that reopens the hardware argument. The reviewer confirms the lifecycle data meets what the DAL demands and finds where the assurance claimed outruns the evidence, particularly for complex devices. You receive a gap list against the DAL, a data-to-assurance map, and an order for closing what is short.
When this review is needed
- The hardware lifecycle data is heading to the authority and the DAL has not been checked against the evidence.
- A finding questioned the verification depth for a complex device on the board.
- The DAL was elevated after design work began and the assurance data has to catch up.
- A device revision or board change reopened hardware that was considered closed.
The problem
Airborne electronic hardware is graded by design assurance level, and the level drives how much verification, elemental analysis, and independence the lifecycle data owes. Complex devices such as programmable logic are where the assurance argument gets thin, because the effort to substantiate them fully is heavy and the plans can promise more than the records deliver. A package can look organized, with plans, design data, and a verification folder, while the assurance owed at the assigned DAL was never fully produced for the parts that need it most.
What gets reviewed
- The assurance activities confirmed against the assigned design assurance level
- Hardware plans and standards checked for consistency with the DAL
- Design data reconciled with the verification meant to confirm it
- Complex device verification checked for the depth the DAL requires
- Independence confirmed where the DAL calls for it
- Configuration records reconciled with the hardware actually verified
What gets validated
- The assurance activities present match those required at the assigned DAL
- Hardware plans and standards are consistent with the DAL and the delivered data
- Complex devices carry the verification depth the level requires, not a simplified subset
- Independence is demonstrated where the DAL requires it
- The configuration verified matches the configuration the design data describes
Evidence normally required
- The hardware plans, standards, and design data
- Verification records and any elemental analysis for complex devices
- The assigned design assurance level and its basis
- Configuration and release records for the hardware
- The change record for hardware reopened since the last baseline
Common discrepancies
What is at stake
Assurance short of the DAL is a finding that can force additional verification, elemental analysis, or independence for a complex device, which is slow work that needs the design team back on a part they had moved past. If the DAL was raised after design started, the shortfall can run across the lifecycle rather than sit in one record. Hardware rework late in a program competes directly with the submittal date it was meant to protect.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the assurance owed
Confirm which DO-254 activities and what depth the assigned DAL requires, especially for complex devices.
Map data to the DAL
Trace the plans, design data, and verification against the assurance the level demands.
Scrutinize complex devices
Check that programmable logic and other complex parts carry the full verification depth, not a reduced set.
Order the rework
Rank the shortfalls by the hardware verification effort each requires.
What the buyer receives
- A gap list against the assurance owed at the assigned DAL
- A data-to-assurance map showing where the level is met and where it is short
- A closure order ranking gaps by the hardware rework each would trigger
Who uses the output
- Test leadership sizing the hardware verification still owed
- Certification leadership defending the assurance argument to an authority
- Engineering leads producing the elemental analysis and independence that is short
How the work fits into the transaction or program
Hardware lifecycle data sits alongside the software argument as one of the deepest evidence stacks, and both are graded by an assigned level. This review confirms the hardware data serves its DAL before the package is submitted, so a shortfall on a complex device is found before an authority does. Its findings feed the compliance line that credits the hardware function and the safety argument that assumes the DAL is met.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
DO-254 is recognized by both the FAA and EASA, but the two can differ on how far they expect complex device verification and tool assessment to be substantiated. The review notes where hardware data acceptable to one authority would need additional substantiation for the other when the device is certified once for use under both.
Regulatory limits
The review checks that the hardware lifecycle data supports the assigned DAL and is internally consistent. It does not perform hardware verification, judge the correctness of a result, or determine that the hardware complies. Acceptance of the assurance argument rests with the authority.
What this review does not cover
- Performing hardware verification or elemental analysis
- Assigning or changing the design assurance level
- Any compliance determination on the hardware
Specific to this review
- Complex programmable devices are where the assurance argument thins out first, because the verification depth they owe is the most effort-heavy in the package.
- A DAL raised after design began leaves lifecycle data built to a lower assurance bar, and the plans rarely flag the shortfall.
- Configuration drift is a common trap: verification results can reference a device revision the current board no longer carries.
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
Why does the review focus so much on complex devices?
Complex devices such as programmable logic carry the heaviest verification burden under DO-254, so that is where the delivered data most often falls short of the assigned DAL. Simple hardware rarely drives findings; the complex parts are where an unmet assurance activity hides.
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.