Airborne electronic hardware lifecycle data
DO-254 hardware lifecycle data evidence review for quality teams
This review reads a DO-254 hardware lifecycle data set to confirm it supports the design assurance level the hardware was assigned, not a lesser one that looks similar on paper. A certification specialist checks the hardware plans, design data, verification, and configuration records against the assigned DAL with your quality function, and finds where the evidence stops short of what the level demands. It runs before submittal, during a finding response, or when a change alters the DAL or reopens verified hardware. You receive a gap list, a map from each objective to its evidence, and a closure sequence for quality leadership.
When this review is needed
- A hardware data set is heading to submittal and quality wants it checked against the assigned DAL.
- A finding questions whether the verification meets the rigor the design assurance level requires.
- A change raised the DAL or altered the design and the data has not caught up to the new expectation.
- The lifecycle data was produced by separate design and verification groups and no one has read it against the DAL as a whole.
The problem
DO-254 data reads as a complete engineering record long before it satisfies the assurance its level requires. The plans are in place, the design data is thorough, the verification ran, but the advanced verification methods, the elemental analysis, or the independence the higher levels call for were scoped for a lower assurance target. Quality holds a data set that documents a working design and still falls short of the assurance the hardware was assigned.
What gets reviewed
- The objective set for the assigned DAL established as the standard the data is measured against
- Hardware plans checked for existence and for actual application in the design and verification data
- Design data reconciled to requirements and to the configuration the verification actually exercised
- Verification and any advanced methods checked for the coverage and independence the DAL requires
- Configuration and control records checked so the data set is a coherent, released baseline
- Objectives affected by a DAL or design change checked for re-work against the current level
What gets validated
- Every objective the assigned DAL requires is addressed by lifecycle data, with none scoped to a lower level
- Advanced verification methods the level calls for are present and reconciled to the design they cover
- Verification independence at the assigned level is met rather than assumed
- The design data verified is the configuration the release records identify, not an earlier board or device revision
- Requirements, design, and verification form a coherent set at one controlled baseline
Evidence normally required
- The hardware lifecycle data set: plans, design data, verification results, and configuration records
- The system safety assessment output that assigns the design assurance level
- The certification basis provisions the hardware compliance supports
- The hardware configuration index identifying the released data
- Change records for any objective, DAL, or design element altered since the data was compiled
Common discrepancies
- Verification scoped to a lower DAL than the hardware was assigned
- An advanced verification method the level requires that was never performed
- Design data verified against an earlier device or board revision than the one released
- A hardware plan written into the data set but not applied in the design activity it governs
What is at stake
Hardware data that supports a lower assurance level than assigned collapses when a reviewer maps objectives to the DAL. They ask for the additional verification or the design assurance activity the level requires, it was never in scope, and the package quality cleared reopens into a category of rework that can reach silicon and board layout. Lifting hardware assurance after the fact is slow and expensive, because it is design activity rather than a documentation exercise.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the DAL and objectives
Confirm the assigned design assurance level from the safety assessment and set its objective list as the standard.
Check assurance and independence
Confirm each objective is met with the verification methods and independence the assigned DAL requires.
Reconcile to the baseline
Confirm the design data verified is the released configuration, not a superseded device or board revision.
Sequence the closures
Order the gaps so design-level rework is scoped before the verification that depends on it.
What the buyer receives
Who uses the output
- Quality leadership deciding whether the hardware data package is ready to submit
- Hardware and verification engineers who need a concrete list of objectives to close or re-run
- The team preparing finding responses that must show a hardware objective met at the assigned DAL
How the work fits into the transaction or program
DO-254 data is where the hardware half of the certification story is proven, and its assurance is fixed by the assigned DAL rather than by how complete the engineering record looks. This review runs before submittal, measuring the data against its DAL while lifting the assurance is still a planned action rather than a finding that reaches back into the design.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-254 for airborne electronic hardware, and the assurance objectives by level are the same under each. The acceptance path differs: FAA delegated findings against a project plan on one side, EASA review items and means-of-compliance acceptance on the other. The review reads the objective coverage against whichever finding path the program is filing under.
Regulatory limits
This review reads your own hardware lifecycle data and reports where it supports the assigned DAL and where it falls short. It does not make an airworthiness determination, does not issue or accept a compliance finding, and does not replace the authority's or the delegate's review of the hardware data.
What this review does not cover
- Producing or re-running the hardware verification the gaps call for
- Authoring the missing design or lifecycle data
- Rendering the compliance finding an authority or delegate reserves
Specific to this review
- DO-254 rework is costlier than its software counterpart because lifting hardware assurance is design activity rather than documentation alone, and can reach into board layout or device selection.
- Advanced verification methods are the usual shortfall at the higher levels, since they are easy to defer and easy to leave scoped for a lower assurance target.
- A design verified against an earlier device revision is a quiet trap, because the data looks complete while it covers hardware the release later superseded.
- A hardware plan that exists but was not applied satisfies the index and fails the assurance objective it was written to meet.
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 reviewing DO-254 data different from reviewing DO-178C data?
The structure is parallel, but the cost profile is not. DO-178C gaps are usually closed with more verification and analysis. DO-254 gaps at the higher assurance levels often demand advanced verification methods and can reach back into the hardware design itself, so this review pays particular attention to whether those methods were performed and whether the data covers the released device revision.
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.