Hardware design assurance
Airborne electronic hardware evidence review under DO-254
A hardware evidence review checks whether an article's DO-254 lifecycle data matches the design assurance level assigned to its programmable devices and the complexity the device actually carries. It is for avionics and equipment suppliers substantiating complex hardware such as FPGAs, ASICs, and PLDs. The review reads the PHAC, the hardware requirements, the conceptual and detailed design data, the verification and validation results, and the configuration records, then checks them against the DO-254 objectives for the level. You receive a status against those objectives and a list of items where the evidence is missing, partial, or out of step with the device complexity.
When this review is needed
- A complex device is heading for a stage-of-involvement review and its lifecycle data needs an independent read.
- A device was reclassified from simple to complex and the evidence must be brought up to the heavier expectation.
- An IP core or reused logic block is carried into the design and its assurance credit has to be shown.
- Findings question whether the verification reaches the detailed design or stops at the requirements.
The problem
DO-254 assurance for complex hardware runs from the planning data through requirements, conceptual design, detailed design, and verification, and the device complexity drives how much of that chain has to be substantiated. Programs often treat a complex device as if it were simple, validate the requirements without exercising the detailed design, or carry an IP core whose internal assurance no one can produce. The hardware works on the bench while the evidence does not reach the objectives the level demands.
What gets reviewed
- The PHAC and hardware plans and whether the artifacts follow them
- The classification of each programmable device as simple or complex
- The hardware requirements and their trace to the conceptual and detailed design
- Verification and validation results against the design assurance level
- Reused logic, IP cores, and the assurance credit claimed for them
- Configuration records and the device build standard they apply to
What gets validated
- Each programmable device is classified, and complex devices carry the full lifecycle data
- The lifecycle data matches the DO-254 objectives for the assigned design assurance level
- Each hardware requirement traces to the detailed design and to verification
- Verification exercises the detailed design rather than stopping at requirements validation
- Derived hardware requirements are captured and provided to the safety assessment
- IP cores and reused logic carry assurance evidence appropriate to the device level
- Configuration records identify the device build standard the evidence applies to
Evidence normally required
- The PHAC and the hardware lifecycle plans
- The device classification rationale and the hardware requirements
- Conceptual and detailed design data
- The verification and validation results and any test or analysis records
- IP core or reused-logic substantiation and prior credit claimed
Common discrepancies
- A device treated as simple that meets the complexity criteria for the full lifecycle
- Requirements validated without verification of the detailed design that implements them
- An IP core integrated without internal assurance evidence behind it
- Derived hardware requirements absent from the safety assessment
- Results tied to a device revision the design has since superseded
- Lifecycle data assembled for a lower design assurance level than the one assigned
What is at stake
A device wrongly classified as simple can require a substantiation effort that was never planned, on a schedule that assumed none. A verification gap at the detailed-design level can mean re-running analysis or test on a frozen device. When an IP core arrives without internal evidence, the program either substantiates it late or removes it from the design.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Classify the devices
Confirm whether each programmable device is simple or complex and the design assurance level it carries.
Trace the design
Follow hardware requirements into conceptual and detailed design and on to verification, checking the trace.
Test the verification
Check that verification reaches the detailed design and that reused logic carries appropriate assurance.
Report the gaps
Produce an objective status and a closure list ordered by stage-of-involvement risk.
What the buyer receives
- A status against the DO-254 objectives for the assigned design assurance level
- A device-classification view flagging anything treated below its complexity
- A trace-gap view from hardware requirements through detailed design and verification
- A prioritized closure list ordered by stage-of-involvement risk
Who uses the output
- Certification leads preparing the hardware package for a stage-of-involvement review
- Hardware engineering teams closing verification and trace gaps
- Hardware design assurance confirming the lifecycle follows the plans
How the work fits into the transaction or program
The review covers the hardware discipline alongside a software lifecycle review for articles that carry both. It links to the safety assessment through derived hardware requirements and to a systems-development review where hardware requirements are allocated.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
Endeavor Elements reviews the applicant's hardware lifecycle data for objective coverage and consistency. It does not act as the authority or a designee, make compliance findings, or guarantee acceptance of the hardware evidence.
What this review does not cover
- Acting as the authority or a designee at a hardware review
- Issuing any compliance finding or hardware approval
- Designing or re-verifying the device in place of the applicant
Specific to this review
- DO-254 scales its expectations with device complexity, so a device classified as simple carries far less lifecycle data, which makes the classification rationale the first thing the review tests.
- Verification under DO-254 is expected to reach the detailed design of a complex device, so a package that validates requirements but never exercises the implementation leaves an objective open.
- IP cores and reused logic blocks carry assurance that has to be established at the level of the device using them, so a block reused from a lower-assurance program needs its credit re-substantiated rather than inherited.
- Hardware verification results are bound to a specific device revision, so evidence run against an earlier revision no longer substantiates a superseded build.
Sources
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
Frequently asked questions
How do you handle a device our team classified as simple?
The review tests the classification rationale against DO-254 complexity criteria. If a device meets the criteria for complex, the report flags the additional lifecycle data the level requires rather than accepting the prior classification.
Can you assess an IP core supplied by a third party?
The review checks whether the assurance evidence for the IP core supports the design assurance level of the device using it. Where the internal evidence is not available, that is recorded as a gap to substantiate or design around.
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.