Airborne electronic hardware
DO-254 hardware lifecycle data support for installation approval
DO-254 data support checks that the airborne electronic hardware lifecycle data behind an installed article supports the design assurance level assigned to its function. It is prepared by or for the modifier before an installation approval package reaches formal review. The work reads the hardware plans, the design data, the verification and validation results, and the configuration records, then tests whether they collectively substantiate the assigned DAL for the complex electronic hardware in the article. You receive a DAL-referenced coverage view, a gap assessment where the lifecycle data does not reach the assigned level, and a closure plan for the hardware evidence before submittal.
When this review is needed
- An article contains a programmable device or an application-specific circuit whose DO-254 data has to support the DAL the safety assessment assigns.
- The assurance data was supplied against a device standard and the modifier must show it applies to the article as installed.
- The design data, verification results, and configuration records were produced by different groups and never reconciled to one baseline.
- A reviewer is expected to focus on the complex hardware, and the project wants the DAL substantiation checked before that focus lands.
The problem
DO-254 assurance rests on showing that a complex electronic hardware item was developed and verified to a level of rigor matching its DAL, and the evidence is spread across requirements, design capture, verification, and validation activities. Hardware data inherited with a device, or assembled over a long development, can present as a full set while missing the requirements-based verification, the elemental analysis, or the configuration control that the assigned DAL demands. The device works on the bench, which masks the gap in the assurance argument.
What gets reviewed
- The hardware plans checked for a lifecycle consistent with the assigned DAL
- Requirements capture and design data traced through to verification
- Verification and validation results assessed for the rigor the DAL requires
- The configuration records confirmed to control the device standard actually installed
- Advanced verification, such as elemental analysis, present where the DAL calls for it
- A closure plan for hardware objectives not yet supported by producible evidence
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- The lifecycle data substantiates the DAL the safety assessment assigns to the hardware function
- Requirements-based verification covers the hardware requirements rather than sampling a subset
- Configuration records identify the exact device standard and revision installed
- Advanced verification methods appear where the assigned DAL mandates them
- Design and verification data trace to one controlled hardware baseline, not divergent builds
Evidence normally required
- The hardware plans, including the plan for hardware aspects of certification
- The hardware requirements, design data, and configuration index
- Verification and validation results and any elemental analysis
- Release and configuration records for the device standard installed
- The DAL allocated to the hardware by the safety assessment
Common discrepancies
- Requirements-based verification that covers only part of the hardware requirement set
- A device standard in the configuration records different from the one installed
- Elemental analysis absent for a DAL that requires an advanced verification method
- Design data that traces to a build superseded by the installed hardware revision
What is at stake
Hardware assurance that does not reach its assigned DAL is difficult to repair late, because the missing activity is often verification or analysis that had to be planned into the design cycle, not bolted on afterward. A shortfall found at review can force a return to the hardware verification environment or a re-argument of the DAL, either of which can hold the installation approval well past its intended window.
How the work runs
Confirm the assigned DAL
Establish the level the safety assessment allocates to the hardware function and treat it as the standard the data must reach.
Trace requirements to verification
Confirm hardware requirements flow through design data to verification results at the rigor the DAL demands.
Check configuration and methods
Confirm the installed device standard is controlled and that any DAL-mandated verification method is present.
Plan the closure
Sequence the open hardware objectives by the verification or analysis effort each requires.
What the buyer receives
- A DAL-referenced coverage view of the hardware lifecycle data
- A gap assessment where the data does not reach the assigned level
- A closure plan for the hardware evidence before the package is submitted
Who uses the output
- Certification project managers judging whether the hardware assurance holds at its DAL
- Engineering leads scoping the verification or analysis an open hardware objective needs
- Compliance staff presenting the DAL substantiation and configuration control to the reviewer
How the work fits into the transaction or program
Electronic hardware assurance runs parallel to the software data and is bounded by the same safety assessment. This coverage view confirms the hardware data reaches its DAL before it is bound into the compliance matrix, so a missing verification method or a configuration mismatch is caught while it can still be planned into a work window rather than discovered under review.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both accept DO-254 for complex electronic hardware assurance, and the objective structure is shared. The difference lies in how the DAL is allocated through the certification basis, so the coverage view uses the DAL this installation's basis assigns rather than one carried over from a prior program the device served in.
Regulatory limits
The work assesses the hardware lifecycle data against its assigned DAL and flags shortfalls. It does not design or verify hardware, does not assign the DAL, and does not make a compliance finding or grant an approval. Verification and the compliance determination rest with the applicant's team and the authority.
What this review does not cover
- Performing hardware verification, validation, or elemental analysis
- Allocating the DAL or authoring the safety assessment
- Any compliance finding or approval on the hardware item
Specific to this review
- Advanced verification such as elemental analysis is the most common DO-254 gap, because it is only required above a certain DAL and is easy to omit when data is reused from a lower-level device.
- Configuration control on the device standard matters more than on most evidence, since a programmable part can carry a revision the assurance data never covered.
- Hardware assurance gaps resist late repair because the missing rigor usually had to be built into the design cycle, not added after the device is complete.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. STC application process, certification basis, and continued airworthiness obligations of an STC holder.
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
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.
Frequently asked questions
How is this different from the DO-178C software review?
Both check lifecycle data against a level the safety assessment assigns, but DO-254 covers complex electronic hardware such as programmable devices and application-specific circuits. The evidence set and the verification methods differ, and configuration control over the exact device standard installed carries particular weight here.
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.