Hardware certification
Hardware certification liaison support for airborne electronic hardware
Hardware certification liaison support manages the working interface between an airborne electronic hardware program and the certifying authority or its delegate. It is used by avionics and equipment suppliers and aircraft modifiers running a DO-254 effort whose stage-of-involvement reviews, action items, or data submittals have drifted from the plan. The liaison reviews the PHAC, the hardware verification and validation records, the conformity and configuration data, and the open action items, then keeps each submittal mapped to the objective it answers. You receive a review-readiness assessment, a tracked action-item register, and a submittal map that ties every artifact to the review milestone it supports.
When this review is needed
- A stage-of-involvement review is approaching and the artifacts named on the agenda are not yet in a state the authority can examine.
- Action items from a prior review have stayed open while the program moved on, and no one is tracking how each one closes.
- Data submittals are reaching the authority piecemeal, so the reviewer cannot see which objective a given artifact is meant to answer.
- The PHAC committed to a verification approach that the current evidence no longer matches, and the gap needs to surface before the next review.
- A delegate or authority engineer has flagged that the hardware lifecycle data is hard to navigate against the design assurance level claimed.
The problem
On a hardware program the engineering is usually ahead of the paperwork that proves it. Requirements get refined, the FPGA or ASIC implementation moves on, and the verification records lag behind the device that is actually built. When the liaison interface is run ad hoc, action items lose their owners, submittals arrive without a map to the objectives, and each stage-of-involvement review reopens questions that an earlier one was supposed to settle.
What gets reviewed
- The plan for hardware aspects of certification and the verification approach it commits to
- Traceability from hardware requirements through design to the device as built
- Verification and validation records against the assigned design assurance level
- The stage-of-involvement review agenda and the artifacts each milestone expects to see
- The action-item and problem-report register and the ownership behind each entry
- Conformity and configuration records that pin the data to the device actually built
- The submittal sequence and how each data package maps to the objective it answers
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- Each artifact on the stage-of-involvement agenda exists and is in a state the authority can review
- Requirements trace from the hardware definition to design, implementation, and verification results
- Coverage of the verification matches the design assurance level the PHAC assigns to the device
- Every open action item has an owner, a closure path, and the evidence that will close it
- Each data submittal is mapped to the DO-254 objective and review milestone it supports
- The conformity records identify the exact device build the lifecycle data describes
- Derived hardware requirements are captured and fed back into the safety assessment
Evidence normally required
- The current plan for hardware aspects of certification and any verification or validation plans
- The hardware requirements, design data, and the traceability assembled so far
- Records of verification and validation and the device configuration they were run against
- The open action-item and problem-report list, with prior review minutes if any exist
- Identifying conformity records for the device build the data is meant to describe
- Authority or delegate correspondence from earlier stages of involvement
Common discrepancies
- Action items carried forward from a prior review with no owner and no closure evidence
- Records of verification run against a device revision that the design data has since superseded
- Coverage that falls short of the design assurance level the PHAC claims for the device
- Submittals that reach the authority without a map showing which objective they answer
- Derived hardware requirements that never returned to the safety assessment that should bound them
- A conformity record that does not pin the lifecycle data to a single identifiable device build
- A PHAC verification approach that the current evidence has quietly moved away from
What is at stake
A review that cannot trace the hardware data to its objectives turns one stage of involvement into several, and the action items multiply faster than they close. The delay lands on the device qualification schedule and the installation it feeds, and the engineering time spent re-explaining the package is time taken from closing the real gaps.
How the work runs
Anchor to the plan
Confirm the PHAC, the verification approach it commits to, and the stage-of-involvement milestones the program is working toward.
Map the open items
Pull the action items and submittals into a single register, assign owners and closure paths, and tie each artifact to the objective it answers.
Check review readiness
Test each agenda artifact for existence, traceability, and coverage against the assigned design assurance level, and flag what is not yet examinable.
Sequence the interface
Produce a submittal map and a prioritized closure list so the next stage of involvement builds on the last instead of reopening it.
What the buyer receives
- A review-readiness assessment of the artifacts each stage of involvement expects to see
- A tracked action-item register with owners, closure paths, and supporting evidence
- A submittal map tying each data package to the DO-254 objective and milestone it answers
- A prioritized list of the hardware data gaps to close before the next review
Who uses the output
- Certification leads running the authority and delegate interface
- Hardware engineering teams closing verification and action-item gaps
- Program management sequencing the work across stages of involvement
How the work fits into the transaction or program
The support runs alongside the supplier's own hardware certification program. It keeps the authority interface orderly so each stage of involvement builds on the last, and it pairs with a fuller evidence review when the program needs the lifecycle data examined in depth rather than the interface managed.
Start with a single asset
Reduce finding cycles by checking the package first.
Aircraft-specific considerations
The depth of hardware lifecycle data tracks the device complexity and the design assurance level its function carries, not the airframe it ends up on. A complex programmable device feeding a higher-assurance function draws more verification scrutiny than a simple part doing the same job, so the liaison effort scales with the device and its failure-condition classification rather than with the installation.
Jurisdiction-specific considerations
FAA programs commonly route DO-254 oversight through stage-of-involvement reviews with an authority engineer or a delegate, while EASA programs frame equivalent expectations through Part-21 and certification review items. The artifacts overlap heavily, but the review cadence and who holds the finding differ, so the liaison tracks each jurisdiction's milestones and correspondence separately rather than assuming one mirrors the other.
Regulatory limits
Endeavor Elements supports the applicant's hardware certification data and the working interface around it. It does not act as the authority or a delegate, make compliance findings, issue any approval, or guarantee that a stage of involvement will close. The applicant, the authority, and any delegate keep their roles.
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, verification, or device qualification itself
Specific to this review
- On a hardware program the implemented device often moves ahead of its verification records, so the most frequent finding is evidence run against a superseded device revision.
- Stage-of-involvement reviews fail more often on navigability than on missing data: the artifact exists but nothing maps it to the objective the reviewer is checking.
- Action items behave like open requirements; without an owner and a named closure path they accumulate across reviews instead of clearing.
- DO-254 lifecycle depth is driven by device complexity and the assigned design assurance level, so a simple part and a complex programmable device carry very different evidence burdens.
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).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
Frequently asked questions
Does the liaison make compliance findings for the authority?
No. The authority or its delegate makes the findings. The liaison keeps the applicant's hardware data organized and mapped to the review objectives so each stage of involvement is easier to work through.
How is this different from a hardware evidence review?
A liaison engagement manages the working interface: the action items, the submittal sequence, and the review readiness across stages of involvement. An evidence review goes deeper into the verification and lifecycle data itself behind those artifacts.
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.