Electronic hardware data
DO-254 hardware data evidence review for hardware assurance teams
A DO-254 data evidence review confirms that an airborne electronic hardware lifecycle data package supports the design assurance level assigned to the device and that the records back what the summary claims. It is run by a hardware assurance team before submittal, a finding response, or a change to the hardware. The review reads the hardware plans, design data, verification results, and configuration records against the DAL, then checks that advanced verification methods are substantiated where the level requires them. You get a gap list keyed to the assurance objectives, an evidence map, and a closure sequence for the assurance lead.
When this review is needed
- A hardware data package is heading to submittal and the DAL objectives have to be shown as satisfied.
- The device DAL was raised and existing verification may not reach the elevated assurance objectives.
- An authority finding questioned the substantiation behind an advanced verification method claim.
- A device revision reopened the hardware lifecycle data and the affected objectives need re-evidencing.
The problem
DO-254 packages fail quietly at the level where the assigned DAL demands more than functional test. A complex device may lean on elemental analysis or advanced verification the records do not fully substantiate, or the design data may describe a revision the verification never ran against. The plans read as complete while the assurance argument for the higher DAL is thinner than the summary implies, and that thinness is exactly what an authority probes.
What gets reviewed
- Hardware plans and design data checked against the objectives the assigned DAL requires
- Verification results reconciled to the requirements and derived requirements they cover
- Advanced verification methods substantiated where the DAL calls for them
- Configuration and release records checked against the verified device revision
- Traceability from requirements through design to verification confirmed
- Derived requirements and their safety feedback checked for verification coverage
What gets validated
- The assurance objectives for the assigned DAL are each supported by a record, not only a plan
- Advanced verification method results are substantiated to the depth the DAL requires
- The verified device revision matches the design data and the configuration on record
- Derived requirements trace to a verification result and to the safety feedback that generated them
- Verification coverage of the requirement set holds without an unexplained gap
Evidence normally required
- The hardware plans and the assigned design assurance level
- Design data including requirements, architecture, and detailed design
- Verification records and any advanced verification method results
- Configuration management and release records for the device
- The safety assessment feedback that drives derived requirements
Common discrepancies
- An advanced verification method cited but not substantiated to the assigned DAL
- Design data describing a device revision the verification never ran against
- A derived requirement with no verification result behind it
- A configuration record that does not match the verified device build
What is at stake
An assurance argument that does not hold at the assigned DAL draws a finding that can force added verification on a device that is already fabricated, which is slow and costly to redo. If the design data and the verified configuration have drifted apart, the mismatch surfaces at the worst point and reopens work the program thought was closed.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the DAL objectives
Establish the DO-254 assurance objectives the assigned level requires for this device.
Map data to objectives
Tie the design data and verification results to the objectives they are meant to satisfy.
Test the assurance argument
Check that advanced verification methods are substantiated to the depth the DAL demands.
Sequence the gaps
List the unmet objectives and order the work to close them before submittal.
What the buyer receives
- A gap list keyed to the assurance objectives not met for the DAL
- An evidence map linking each objective to its verification and design record
- A closure sequence ordering the open objectives by dependency and lead time
Who uses the output
- Assurance leads confirming the DAL objectives hold before they sign the summary
- Certification leads answering a finding on an advanced verification claim
- Engineering owners re-evidencing objectives a device revision reopened
How the work fits into the transaction or program
The review takes the hardware lifecycle data once the team believes the device is closed and checks it against the DAL before the summary is relied on. Its gap list drives the verification or substantiation still owed, and its evidence map anchors the hardware section of the compliance data.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-254 for electronic hardware, and each can set its own expectation for how advanced verification methods are substantiated at the higher assurance levels. The review notes where a substantiation satisfies one authority and where the other would ask for a deeper argument before accepting the method.
Regulatory limits
The review checks the hardware data against the objectives for its assigned DAL. It does not perform hardware verification, assign or approve the DAL, or make a compliance determination for the authority.
What this review does not cover
- Performing hardware verification, analysis, or elemental analysis runs
- Assigning or approving the design assurance level
- Determining that the hardware complies for certification
Specific to this review
- The higher DAL levels are where DO-254 packages thin out, because functional test alone stops being enough and the added assurance argument is easy to under-substantiate.
- Design data drifting ahead of the verified revision is a common defect, since hardware revisions can outpace the verification that was run.
- Derived requirements from the safety feedback are a frequent coverage gap, because they appear late and are easy to leave unverified.
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
How is this different from the DO-178C software review?
This review works from electronic hardware lifecycle data and the objectives DO-254 sets by design assurance level, where the harder gaps sit in advanced verification substantiation and design-to-verification drift. The software review is keyed to DO-178C objectives and a different set of typical failure modes.
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.