Certification problem
Airborne hardware data that does not match its design-assurance level
This page is for avionics and equipment suppliers whose airborne electronic hardware lifecycle data falls short of the design-assurance level assigned to a complex device under DO-254. It triggers when an FPGA, ASIC, or PLD carries one assurance level while its verification, traceability, or elemental analysis reflects a lower one. The review compares the assigned level against the objectives that apply and the data produced, examining the hardware plans, requirements, verification records, and any elemental analysis. You get the objectives unmet at the assigned level and the hardware data each gap requires.
When this review is needed
- A complex device carries an assurance level its verification depth does not match.
- Elemental analysis or advanced verification is expected at the level but was not performed.
- Hardware requirements trace incompletely from requirement through implementation and verification.
- The team wants the device's data reconciled against its assigned assurance level before submittal.
The problem
Design assurance for complex hardware sets a level of rigor the lifecycle data has to demonstrate, and the shortfall shows up when the device is treated as more capable than its evidence proves. A device gets an assurance level early, then its verification, traceability, and analysis are produced to a lighter standard as the schedule tightens. The plans still name the higher level while the verification stops short, the requirements trace has holes, and the elemental analysis the level expects was never run. The device looks assured on paper and is under-evidenced underneath.
What gets reviewed
- The design-assurance level assigned to each complex hardware device
- The DO-254 objectives that apply at that level and the data produced
- Traceability of hardware requirements from requirement through implementation to verification
- The verification depth and methods measured against what the assigned level expects
- Elemental or advanced verification analysis where the level calls for it
- Lifecycle data that tracks a lower assurance level than the device was assigned
What gets validated
- Every DO-254 objective applicable at the assigned level has supporting data
- Hardware requirements trace cleanly through implementation to verification
- Verification depth and methods meet what the assigned level requires
- Elemental or advanced verification is present where the level demands it
- The hardware plans declare a level the produced data supports
- No complex device is treated as simple to avoid the level's objectives
Evidence normally required
- The assigned hardware design-assurance level and its safety basis
- The hardware plans and standards declaring the level
- Hardware requirements and the traceability through to verification
- The verification records and any elemental analysis performed
Common discrepancies
- Verification depth below what the assigned level expects
- A requirements trace with gaps between hardware implementation and verification
- Elemental analysis required at the level but never performed
- Plans declaring a higher level than the hardware data supports
- A complex device classified as simple to sidestep the applicable objectives
What is at stake
Hardware data short of its assigned level is an assurance shortfall for a device the system safety case depends on. A reviewer comparing the level to the hardware objectives finds verification thin or the trace incomplete, and closing it can mean rerunning hardware verification or performing elemental analysis on a device that is already in layout, which is slow and costly to revisit.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Confirm the level
Establish each complex device's assigned design-assurance level and the DO-254 objectives at it.
Check the classification
Confirm devices treated as simple are genuinely simple rather than complex in disguise.
Map the data
Lay verification, traceability, and analysis against the objectives the level requires.
Order the closure
Name the data each gap needs and sequence by difficulty of revisiting the device.
What the buyer receives
- The objectives unmet at the assigned design-assurance level
- For each gap, the verification, trace, or analysis the level still requires
- A note where a device's classification understates its complexity
- A closure list ordered by the gaps most disruptive to revisit in layout
Who uses the output
- Hardware certification leads aligning the data to the assigned level
- FPGA and ASIC engineers closing verification and analysis gaps
- Certification engineers reconciling the plans with the demonstrated data
How the work fits into the transaction or program
This pass examines hardware assurance against its assigned level specifically. It complements a software-level check and an environmental-qualification check when a program needs its full assurance evidence reviewed.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Regulatory limits
Endeavor Elements compares the applicant's hardware data against the objectives of the assigned level. It does not assign the assurance level for the authority, perform the verification, or guarantee acceptance of the hardware data.
What this review does not cover
- Assigning or approving the design-assurance level
- Performing hardware verification or elemental analysis
- Issuing approvals or making official compliance findings
Specific to this review
- DO-254 applies to complex devices such as FPGAs, ASICs, and PLDs, so the first check is whether a device classified as simple is actually complex and owes the level's objectives.
- Hardware verification and elemental analysis are tied to the device design, so a gap found after layout is far harder to close than a documentation gap.
- Traceability gaps in hardware tend to sit between implementation and verification, where the path from coded logic to a verification result is the easiest to leave incomplete.
- The plans naming the assurance level rarely move when verification is thinned, so the declared level outruns the evidence underneath it.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Frequently asked questions
Does DO-254 apply to every part on the board?
No. The design-assurance objectives apply to complex custom devices such as FPGAs, ASICs, and PLDs. A first check is whether a device labeled simple is actually complex and therefore owes the level's objectives.
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.
Walk through your situation with an engineer who has done this work.