Airborne electronic hardware lifecycle data
DO-254 hardware lifecycle data evidence review for equipment suppliers
This review examines a supplier's DO-254 lifecycle data for airborne electronic hardware: the hardware plans, the design data, the verification and validation records, and the configuration records that hold them together. It checks that the evidence supports the assigned design assurance level, that the DAL-driven activities such as elemental analysis or independent verification were actually performed where required, and that the design data matches the configuration under review. A hardware certification engineer runs it before submittal, in a finding response, or after a design change. You receive a gap list, an evidence map, and a closure sequence for engineering leadership.
When this review is needed
- The complex device was designed before its DAL was firm and the DAL-driven activities may not have been planned in.
- A device revision changed logic and the verification for the affected regions needs to be shown current.
- A finding asks the supplier to demonstrate the additional assurance appropriate to the assigned level.
- Intellectual property or a reused core was integrated and its assurance data needs to be reconciled to this DAL.
The problem
DO-254 data for a complex device is spread across requirements, design capture, verification, and the configuration index, and the activities that distinguish a high DAL from a low one are easy to plan out of. Elemental analysis, robustness testing, and independence are the parts most often deferred and least often revisited. The data set can look full while the DAL-specific evidence that justifies the level is thin.
What gets reviewed
- Check that the hardware plans commit to the activities the assigned DAL requires
- Confirmation that design data traces from hardware requirements through capture to implementation
- Read of verification and validation records against the DAL-driven objectives
- Review of DAL-specific assurance such as elemental analysis, robustness, and independence
- Confirmation that the configuration index matches the device revision under review
- Identification of assurance activities absent for the level claimed
What gets validated
- The hardware plans and standards reflect the assigned design assurance level
- Hardware requirements trace through design capture into the implemented device
- Verification covers requirements and, where the level requires it, additional assurance is present
- Elemental analysis or equivalent coverage exists where the DAL demands it
- The hardware configuration index matches the device revision being certified
Evidence normally required
- The hardware plans, including the PHAC and verification and validation plan
- Hardware requirements and design data down to the implementation
- Verification and validation records, including any elemental analysis
- The hardware configuration index and device revision identification
- The assigned design assurance level and the safety assessment behind it
Common discrepancies
- Elemental analysis absent or partial for a device carrying a high design assurance level
- Verification run against a prior device revision than the one being submitted
- Independence expected at the level but performed by the design engineer in practice
- Reused programmed-logic cores lacking assurance data that reconciles to this DAL
What is at stake
When a reviewer checks the assurance appropriate to the level and finds a required activity missing, the gap cannot be closed with a document. It usually means rerunning verification against the device, which for programmed logic can mean regenerating test benches and re-executing on hardware. Discovering this near submittal puts the schedule at the mercy of a lab and a device.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Confirm the DAL
Establish the assigned design assurance level from the safety assessment and check the plans commit to its activities.
Trace design to verification
Follow hardware requirements through capture into the device and into the verification that exercises them.
Check level-driven assurance
Confirm elemental analysis, robustness, and independence are present where the DAL requires them.
Sequence the rework
Order missing assurance by device and lab availability so hardware-bound reruns start first.
What the buyer receives
- A gap list of assurance activities missing for the assigned design assurance level
- An evidence map from each hardware requirement through design to verification
- A closure sequence ordering verification rework by device and lab availability
Who uses the output
- Engineering leadership scoping the hardware verification rework before submittal
- Certification leads presenting the hardware assurance argument to the authority
- Hardware leads regenerating verification against the current device revision
How the work fits into the transaction or program
DO-254 data is the hardware counterpart to the DO-178C branch, and both draw their required rigor from the safety assessment that sets the DAL. This review checks the hardware data against that level and connects to the configuration management review, since the device revision under assurance has to match the controlled configuration.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both recognize DO-254 for complex electronic hardware and both expect the DAL to descend from the aircraft and system safety process. Guidance on additional assurance such as elemental analysis is applied through the authority's position and any issue papers on the program, so this review flags where the data assumes a lighter treatment than the level supports.
Regulatory limits
This review evaluates the completeness of the hardware lifecycle data against its assigned level. It makes no airworthiness determination, approves no hardware, and does not decide DO-254 acceptability in the authority's judgment. That determination stays with the authority and its delegated hardware specialists.
What this review does not cover
- Running hardware verification or generating elemental analysis
- Revising the hardware plans, requirements, or design data
- Assessing the device's electrical performance in the target system
Specific to this review
- The activities that separate a high DAL from a low one, such as elemental analysis and independence, are the easiest to leave out of the plan and the hardest to add back late.
- For programmed logic, a device revision change can invalidate verification for regions far from the edit, so a small logic fix can reopen a large body of evidence.
- Reused cores seldom arrive with assurance already matched to the receiving DAL, and reconciling them is routinely underestimated.
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 device passed all its functional tests. Why is the DO-254 data still short?
Functional tests show the device works; DO-254 assurance shows it was developed with the rigor its design assurance level requires. Activities like elemental analysis and independent verification are about coverage and process, not function, and they are the parts most often missing when the data is otherwise complete. This review checks the assurance, not just the function.
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.