Hardware design assurance
DO-254 hardware compliance support for airborne electronic hardware
DO-254 hardware compliance support helps an avionics or equipment supplier substantiate the design assurance behind its complex airborne electronic hardware. It is used by hardware teams whose programmable devices, an FPGA, ASIC, or complex PLD, have moved ahead of the lifecycle data that is supposed to prove them. The work reviews the PHAC and the hardware plans, the requirements and their traceability to the device implementation, the validation and verification records, the elemental and functional coverage, and the conformity and configuration data that pins it to a build. You receive a design-assurance gap assessment against the assigned level, a traceability view from requirement to device, and a prioritized list of the hardware lifecycle data to close.
When this review is needed
- A complex programmable device is approaching a design-assurance review and the lifecycle data has to be checked against the level its function carries.
- The device implementation has been re-spun and the verification records still describe an earlier revision of the FPGA or ASIC.
- Advanced verification methods such as elemental analysis were planned, and whether the evidence actually meets them needs to be confirmed.
- An IP core or reused hardware logic is being carried into the device and the credit claimed for it has to be substantiated.
- A supplier wants an independent read of the hardware package before it reaches the authority or a delegate.
The problem
DO-254 design assurance turns on whether the device that is built is the device the requirements describe, and that link is fragile. A programmable device gets re-spun for timing or resource reasons, the verification was run on a prior bitstream, and the worst-case timing analysis was never repeated against the build that ships. The standard reserves its heaviest expectations for complex hardware at the higher assurance levels, yet the elemental coverage and the conformity that would prove it are often the last things produced.
What gets reviewed
- The plan for hardware aspects of certification and the supporting hardware plans and standards
- The assigned design assurance level and what it expects for complex versus simple hardware
- Hardware requirements and bidirectional traceability to the device design and implementation
- Verification and validation records, including reviews, analyses, and hardware testing
- Elemental and functional coverage and any advanced verification methods the plan committed to
- Worst-case and timing analyses against the device build that actually ships
- Conformity and configuration records that identify the exact device build the data describes
What gets validated
- Requirements trace from the hardware definition through design to the implemented device
- Verification and validation records were run against the device revision that the design data currently describes
- Coverage meets the level assigned to the device, including elemental analysis where the plan committed to it
- Worst-case and timing analyses cover the build that ships rather than an earlier spin
- Derived hardware requirements are captured and fed back into the safety assessment
- Conformity records pin the lifecycle data to one identifiable device build
- Reuse credit for an IP core or reused logic is backed by the data the credit depends on
Evidence normally required
- The PHAC and the hardware design, validation, verification, and configuration plans
- The hardware requirements and the traceability to design and implementation assembled so far
- Verification and validation records, including review records, analyses, and test results
- The coverage analysis and any elemental or advanced verification evidence
- Conformity and configuration records for the device build the data is meant to describe
- The assigned design assurance level and the safety assessment that drove it
Common discrepancies
- Verification records run against a device revision the design data has since superseded
- Coverage short of the design assurance level the PHAC claims for the device
- Worst-case or timing analysis that was never repeated against the build that ships
- Derived hardware requirements that never returned to the safety assessment that should bound them
- An IP core carried into the device with no data to support the credit claimed for it
- A conformity record that does not pin the lifecycle data to a single device build
- Elemental analysis named in the plan but absent from the evidence the program produced
What is at stake
When the lifecycle data describes a device revision the program has moved past, the review cannot accept the verification, and the device qualification slips while the records are rebuilt against the current build. Coverage that falls short of the assigned design assurance level can force re-verification of logic that was thought finished, and that delay lands on the equipment program and the installation the device feeds.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Confirm the level
Establish the assigned design assurance level and what it expects for the device given its complexity classification.
Reconcile to the build
Map requirements through design to the implemented device and confirm the verification was run against the current revision.
Test the coverage
Check coverage, worst-case and timing analyses, and any elemental method against the level the device carries.
Package the gaps
Produce a design-assurance gap assessment and a prioritized closure list ready for review.
What the buyer receives
- A design-assurance gap assessment against the level the device carries
- A traceability view from hardware requirement through design to the implemented device
- A disposition log for derived requirements, reused logic, and coverage shortfalls
- A prioritized list of the hardware lifecycle data to close before review
Who uses the output
- Certification leads preparing the hardware submittal or design-assurance review
- Hardware engineering teams closing verification, coverage, and conformity gaps
- Program management sequencing the remaining device-level work
How the work fits into the transaction or program
The support strengthens the supplier's own DO-254 package so the design assurance holds up when the device is examined against its assigned level. It pairs with software compliance work when the device sits in a system with airborne software, and with environmental qualification when the same hardware has to be qualified to its installation environment.
Start with a single asset
Confirm requirements trace through verification.
Aircraft-specific considerations
DO-254 depth follows the device complexity and the design assurance level its function carries, not the airframe it ends up on. A simple part and a complex programmable device doing nominally the same job carry very different evidence burdens, and a device feeding a higher-assurance function draws elemental analysis and tighter conformity that a lower-assurance function does not, so the review scales with the device and its failure-condition classification.
Regulatory limits
Endeavor Elements supports the applicant's hardware lifecycle data. It does not act as the authority or a delegate, make compliance findings, issue any approval, or guarantee that a design assurance level will be accepted. The applicant and the authority keep their roles, and the assignment of the design assurance level remains a safety-assessment outcome the applicant owns.
What this review does not cover
- Making official compliance findings or acting as the authority or its delegate
- Issuing any approval, authorization, or design approval
- Performing the hardware design or running the device qualification itself
Specific to this review
- DO-254 reserves its heaviest design-assurance expectations for complex hardware such as FPGAs, ASICs, and complex PLDs, while simple hardware can be substantiated by test alone.
- Advanced verification methods like elemental analysis are usually invoked at the higher assurance levels, and a plan that commits to them without the evidence is a recurring finding.
- Because a programmable device is re-spun easily, verification run against a superseded bitstream is the most common reason a review cannot accept the data.
- Conformity for hardware identifies a specific device build, so lifecycle data that floats across multiple revisions cannot be pinned to what actually ships.
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).
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Do you decide whether our device is simple or complex?
No. The complexity classification and the assigned design assurance level are the applicant's, driven by the architecture and the safety assessment. The review checks that the lifecycle data matches the classification and level claimed and flags where it does not.
What happens if the device was re-spun after verification?
We map which verification still applies to the current build and which has to be repeated, then sequence the re-verification and the conformity updates so the data describes the device that ships.
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.