Electronic hardware lifecycle data
DO-254 hardware lifecycle data evidence review for avionics suppliers
This review reads an avionics supplier's DO-254 hardware lifecycle data and asks whether it earns the design assurance level assigned to the electronic hardware. A certification specialist checks the hardware plans against the DAL, follows the requirements into the design data and verification, and confirms the configuration records fix what was actually built and tested. It runs before submittal, during a finding response, or when a device revision or a tool change reopens closed evidence. You receive a gap list, an evidence map from requirement to record, and a closure sequence.
When this review is needed
- A hardware data package is close to submittal and the requirement-to-verification picture has not been read by an outside eye.
- A device was respun and the team needs to know which prior verification still applies to the new silicon.
- A finding questions whether elemental analysis or advanced verification was actually needed and done at the assigned level.
- A synthesis tool or library was changed and the qualification and results tied to the old tool are now in doubt.
The problem
DO-254 evidence spans requirements, design, implementation, and verification for programmable devices that change quietly with every respin. A requirement gets verified against a build, the device is revised for an unrelated reason, and the verification record now describes hardware that no longer exists. The configuration records that should pin build to evidence are the ones most often out of date, and the tools that produced the results carry their own qualification burden.
What gets reviewed
- Hardware plans checked so the assurance activities they commit to match the assigned DAL
- Requirements traced into design data and implementation for the current device revision
- Verification records checked against requirements, including any advanced verification the level requires
- Elemental analysis or equivalent confirmed where the DAL calls for it, with its results reviewed
- Configuration records confirmed to pin the tested build, netlist, and device revision to the evidence
- Tool assessment and qualification checked for the tools whose output the evidence depends on
What gets validated
- The assurance activities in the plans are the ones the assigned DAL requires for this hardware
- Verification records describe the device revision now being fielded, not a superseded build
- Advanced verification or elemental analysis is present where the level requires it, with reviewed results
- Configuration records tie the netlist, build, and device revision to the verification evidence
- Tools that produced verification results carry the assessment or qualification the level requires
Evidence normally required
- The plan for hardware aspects of certification and the supporting design and verification plans
- Hardware requirements, design data, and implementation records at the current device revision
- Verification cases, procedures, and results, including any advanced verification analyses
- Elemental analysis or equivalent coverage evidence where applicable
- Configuration records and tool assessment or qualification data for the toolchain
Common discrepancies
- Verification results tied to a device revision earlier than the one now shipping
- Elemental analysis assumed unnecessary at a level that in fact required it
- Configuration records that do not pin the tested netlist to the released device
- A synthesis or verification tool changed without reassessing the results that depended on it
What is at stake
Hardware evidence that does not match the fielded device is a finding that lands at the worst time, because a respin to close it is measured in months, not weeks. If advanced verification or elemental analysis was skipped at a level that required it, the shortfall cannot be argued away, and a late demand for it can hold the item long after the software and system data are ready.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix DAL and device revision
Confirm the assigned design assurance level and the current device revision, then align the plans and evidence to both.
Trace requirement to hardware
Follow each requirement into design data and verification for the current revision, checking that results describe the fielded build.
Check level-driven activities and tools
Confirm advanced verification and elemental analysis where the level requires them, and check tool assessment for the toolchain.
Sequence around respins
Order closures so long-lead verification and any respin-dependent gaps lead and record reconciliation follows.
What the buyer receives
- A gap list naming each requirement or activity whose hardware evidence is missing, stale, or mislevel
- An evidence map from every hardware requirement to the design and verification record that closes it
- A closure sequence that flags respin-dependent gaps and puts long-lead verification first
Who uses the output
- Certification leadership deciding whether the hardware data is ready to submit or present at a review point
- Hardware verification engineers who need a concrete list of results to rebuild against the current revision
- The team answering a hardware finding about verification depth or level at an authority review
How the work fits into the transaction or program
DO-254 hardware data pairs with the software and system evidence to support the item's overall assurance argument. This review checks the hardware layer against its DAL and its current device revision, so a respin or a skipped analysis is caught as a hardware gap before it becomes a program-level delay at integration.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both accept DO-254 for electronic hardware, though the expectation for advanced verification and tool qualification firms up with the design assurance level and the specific device technology. The review reads the data against the level assigned and the review points the authority or delegate will exercise, since a complex programmable device draws more scrutiny than a simple one at the same level.
Regulatory limits
This review assesses the supplier's DO-254 data against its assigned level and reports gaps. It does not accept the hardware, does not issue a compliance finding, and does not make an airworthiness determination. Those judgments belong to the authority or the delegate reviewing the item.
What this review does not cover
- Performing the hardware verification, elemental analysis, or tool qualification the gaps require
- Respinning the device or authoring the missing design and verification records
- Granting or accepting a hardware compliance finding
Specific to this review
- The device revision is the axis everything turns on: a respin for an unrelated reason can silently detach every verification result from the hardware now shipping.
- Elemental analysis is where level judgment goes wrong, because deciding it is unnecessary is cheap and reversing that call late requires verification the schedule never planned for.
- Tool qualification is an easy blind spot; a swapped synthesis or simulation tool can undercut results that were sound under the tool they were produced with.
- Configuration records for programmable hardware age faster than for software, since each netlist and build is a distinct article the evidence must be pinned to.
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 was respun after verification. How much of our evidence still counts?
That depends on what the respin changed, and separating the two is exactly what this review does. It maps each verification result to the device revision it was produced against, then identifies which results the respin invalidates and which remain valid, so you re-run only what the change actually touched.
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.