Airborne electronic hardware
DO-254 hardware data evidence review for software assurance teams
This review reads a DO-254 hardware data package and confirms it earns the design assurance level it claims. A certification engineer works through the hardware plans, the design data for the complex device, the verification and validation results, and the configuration records, then checks that the evidence actually supports the assurance level assigned to the item. Assurance teams commission it before submittal, when answering a finding, or when a device revision reopens verification. You receive a gap list tied to the DO-254 process objectives, an evidence map, and an ordered closure plan.
When this review is needed
- A complex electronic hardware item is close to submittal and the design data has never had an outside read.
- The authority questioned whether the verification evidence supports the assigned design assurance level.
- A device respin or netlist change reopened verification and you need to know what re-flows.
- The item is being reused on a new program at a higher assurance level than it was first developed for.
The problem
DO-254 evidence lives across design capture, synthesis, and lab and hardware verification, and those threads are usually owned by different engineers who do not read each other's records. A device can be functionally sound while the elemental analysis, the requirements coverage, or the derived-requirement rationale falls short of what the assigned design assurance level demands. The device works on the bench, so the assurance gap goes unnoticed until a reviewer asks for the trace.
What gets reviewed
- The hardware plan set (PHAC and companions) checked against the assigned design assurance level
- Requirements capture, derived requirements, and the rationale attached to each
- Design data through capture and implementation, with traceability to requirements
- Verification and validation results, including the analysis and testing appropriate to the level
- Configuration management and the identity of the device the evidence describes
- Elemental and other advanced analysis where the level and item complexity call for it
What gets validated
- Verification methods present match what the assigned design assurance level requires for the item
- Derived requirements carry a rationale and are fed back to the safety process
- Design data traces to requirements and to the verification that exercises it
- The device identity in the configuration records matches the build the verification was run against
- Any advanced verification the level demands is present, not assumed satisfied by lower-order testing
Evidence normally required
- The hardware plans including the PHAC at the proposed revision
- Hardware requirements with derived-requirement rationale
- Design data through capture and implementation
- Verification and validation results and coverage analysis
- Configuration index and the hardware accomplishment summary
Common discrepancies
- A derived requirement with no rationale and no path back to the safety assessment
- Verification that covers function but not the coverage the assurance level requires
- Design data traced to an earlier revision than the device the summary describes
- Advanced analysis assumed complete because functional testing passed
What is at stake
If the verification evidence does not carry the assurance level, the authority can require additional verification methods or advanced analysis late, when a respin is expensive and the schedule has no slack. Reused hardware is worse: a level mismatch discovered after integration can force re-verification of a part everyone assumed was settled.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Anchor to the level
Confirm what the assigned design assurance level demands of this item before reading any evidence.
Follow requirements down
Trace requirements, including derived ones, through design capture to the verification that exercises them.
Match method to level
Check that verification and analysis methods present are the ones the level requires, not lower-order substitutes.
Order the rework
Rank the gaps so re-verification runs in the sequence that clears the item fastest.
What the buyer receives
- A process-objective gap list ranked by verification effort and review exposure
- An evidence map tying each assurance claim to the design or verification record behind it
- A closure sequence ordering the re-verification a change or level mismatch reopened
Who uses the output
- Assurance leads judging whether the hardware package is submittal-ready
- Certification leadership framing a response to a finding on hardware evidence
- Engineering leads scoping the re-verification a respin or reuse triggered
How the work fits into the transaction or program
The review comes after hardware verification is nominally done and before the data reaches the authority. It reads design capture, verification, and configuration as one package, so an assurance-level gap is caught while a respin is still on the table rather than after the item is locked into an installation.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA treat DO-254 similarly for hardware, but each attaches its own guidance on how complex devices and design assurance levels are argued, and EASA leans on its certification review items in ways the FAA process does not mirror exactly. The review flags claims that would satisfy one authority but invite a question from the other.
Regulatory limits
This review reads and reconciles evidence. It does not assign a design assurance level, make a compliance finding, or determine the hardware is airworthy. Those judgments belong to the applicant, the authority, and its designees.
What this review does not cover
- Performing or re-running hardware verification or lab testing
- Authoring the design data or requirements the package lacks
- Any compliance finding or acceptance of the assurance argument
Specific to this review
- Derived requirements are the most common DO-254 trace break, because they are created during design and easy to leave disconnected from the safety process.
- A device that passes bench testing can still miss the coverage its design assurance level requires, since function and assurance are different questions.
- Reusing hardware at a higher level than it was developed for rarely triggers a full re-read of the original evidence, which is where reuse findings begin.
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?
DO-254 governs the electronic hardware itself, so the evidence is design capture, netlist, and hardware verification rather than code and structural coverage. The failure modes differ: derived-requirement gaps and coverage that does not match the assurance level are the ones we watch 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.