Hardware lifecycle data
DO-254 hardware data evidence review for certification teams
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 the item was assigned. It is run for a certification team before submittal, during a finding response, or ahead of a design change review, by or for the team that owns the electronic hardware data package. The work reads the lifecycle data against the design assurance level and its expected activities, then flags where the data does not support the level the hardware carries. You receive a gap list, an evidence map from each activity to its supporting data, and a closure sequence compliance management can execute.
When this review is needed
- The design assurance level was raised and the verification data still reflects the earlier, lower level.
- The elemental analysis or verification coverage expected at the assigned level is missing or partial.
- A device revision changed the design and the configuration records do not capture the change.
- The team is preparing to submit and wants the hardware lifecycle data checked against its assigned level.
The problem
DO-254 expects a set of lifecycle activities scaled to the design assurance level, and a hardware data package can slip out of alignment with the level it was built for. The DAL rises after a safety assessment while the verification effort stays where it was, the design data and the fabricated device diverge as revisions accumulate, or the configuration record loses track of which device revision the verification actually ran against. The package looks like a full set of hardware data while falling short of the assurance the level demands.
What gets reviewed
- The assigned design assurance level confirmed against the lifecycle activities the data must show
- Hardware plans checked so the process they define matches the records produced
- Design data reconciled to the device revision the verification was run against
- Verification results checked for the coverage and elemental analysis the level expects
- Configuration records checked so each result ties to a controlled device revision
- Independence checked where the assigned level requires it
What gets validated
- The lifecycle activities in the data match the ones the assigned design assurance level expects
- The hardware plans agree with the process the verification and design records show was followed
- Design data corresponds to the device revision the verification results were produced against
- Verification coverage and elemental analysis meet the level's expectations, with gaps analyzed
- Every verification result ties to a configuration-controlled device revision
Evidence normally required
- The hardware plans and standards for the item
- The hardware design data and the device revision history
- The verification records, including analysis, review, and test results
- The hardware configuration index and accomplishment summary
- The assigned design assurance level and the safety assessment that sets it
Common discrepancies
- Verification data supporting a lower level than the hardware was assigned after a DAL increase
- Design data that does not match the device revision the verification ran against
- Elemental or coverage analysis short of what the assigned level expects
- A verification result that cannot be tied to a controlled device revision
What is at stake
Hardware lifecycle data that supports a lower level than the item is assigned reopens verification at the very point the schedule assumed it was closed, and at the higher levels that can mean adding elemental analysis or independent verification that takes weeks. A configuration record that cannot pin verification to a specific device revision is worse, because it leaves the results unable to prove which hardware they actually confirmed.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the level
Confirm the assigned design assurance level and the lifecycle activities the data must show.
Pin the revision
Reconcile design data and verification results to a controlled device revision.
Test the coverage
Confirm verification coverage and elemental analysis meet the level, with gaps analyzed.
Sequence the closures
Order the level-support work against the submittal date.
What the buyer receives
- A gap list identifying each activity the lifecycle data does not support at the assigned level
- An evidence map linking every expected activity to its supporting hardware data
- A closure sequence ordering the level-support work against submittal
Who uses the output
- Compliance managers confirming the hardware data supports its level before submittal
- Certification leads deciding which level-support gaps must close first
- Engineering owners reconciling verification results to a controlled device revision
How the work fits into the transaction or program
The DO-254 hardware data supports the electronic-hardware side of the design assurance the safety assessment allocates, so its adequacy is judged against an assigned level rather than against how much verification was run. Reviewing it before submittal exposes a level-to-data or revision mismatch while the fix is still schedulable, and the activity map it produces feeds the requirements trace and the compliance matrix rows the hardware supports.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-254 for airborne electronic hardware, but they differ on supplementary guidance and on how verification independence and coverage gaps are documented. Where hardware is certified under both, the review notes where lifecycle data acceptable to one authority needs added analysis or independence to satisfy the other.
Regulatory limits
The review confirms the hardware lifecycle data supports the assigned level and is internally consistent. It does not assign the design assurance level, perform verification, or determine that the hardware is compliant or airworthy.
What this review does not cover
- Performing the hardware verification or elemental analysis
- Assigning or changing the design assurance level
- Any determination that the hardware supports its level
Specific to this review
- DO-254 activities scale with the design assurance level, so a DAL increase after a safety assessment can leave a complete-looking package short on elemental analysis and independence.
- Device revisions are the hardware analogue of software builds: verification that cannot be pinned to a specific revision cannot prove which device it confirmed.
- The gap between a fabricated device and its design data is the failure mode that quietly grows across revisions, because each change is small and the configuration record lags.
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 device revision matter so much in a DO-254 review?
Verification results only prove something about the exact device revision they were produced against. If the configuration record cannot tie a result to a specific revision, the evidence cannot show which hardware it confirmed, and a later revision may have changed the very element the result was meant to cover.
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.