Field approval, electronic hardware
Field-approval DO-254 electronic hardware data support
This support prepares airborne electronic hardware lifecycle data so a field-approval package survives FAA review. It examines the hardware plans, requirements and design data, verification results, and configuration records against the assigned design assurance level, then identifies where the evidence does not hold at that DAL. A hardware certification engineer runs it ahead of submission. You get a DAL-referenced gap assessment, an evidence map that ties hardware requirements to their verification, and a closure plan for the shortfalls that would otherwise surface in formal review.
When this review is needed
- A field-approval installation contains a complex electronic device that needs DO-254 evidence to a specific DAL.
- The device predates its use on this program and its lifecycle data was captured to a different assurance level.
- Verification results exist for the hardware but the coverage against the DAL objectives has never been confirmed.
- A programmable logic device was updated and the change's effect on the assurance evidence is unclear.
The problem
Airborne electronic hardware data is often built by a component vendor for one program and reused on another, so the assurance evidence rarely matches the DAL a new installation carries. Field-approval reviewers look for verification coverage tied to hardware requirements at the assigned level, and complex programmable devices are exactly where that trace tends to thin out. The modifier inherits a data set they must defend without having designed the part.
What gets reviewed
- Hardware plans, including the plan for hardware aspects of certification, read against the assigned DAL
- Hardware requirements and design data with their traceability to verification
- Verification and validation results covering the objectives the DAL requires
- Configuration and problem-report records for the electronic hardware items
- Elemental analysis or coverage evidence where the DAL calls for it on complex items
- Any commercial device or IP reuse justified against the assurance the level requires
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 hardware requirement traces to design data and to a verification result that supports the DAL
- Verification coverage on complex programmable devices reaches the depth the assigned level requires
- The hardware configuration index matches the items the verification evidence was run against
- Problem reports on the hardware are dispositioned consistently with the assigned DAL
- Reused or commercial hardware carries a justification appropriate to the assurance level claimed
Evidence normally required
- The plan for hardware aspects of certification and supporting hardware plans
- Hardware requirements, design, and the traceability data linking them
- Verification and validation results and coverage analyses
- The hardware configuration index and open problem reports
- The assigned design assurance level and the certification basis for the installation
Common discrepancies
- A complex programmable device whose verification coverage sits below its assigned DAL
- Hardware requirements with no traceable link to a verification result
- A reused component justified for one program and carried onto this one without a fresh assurance argument
- A configuration index that lists a device revision different from the one verified
What is at stake
Hardware evidence that does not reach the assigned DAL forces the reviewer to return the package or narrow the approval, and the equipment cannot enter service on the certificate the modifier planned. Regenerating verification for a complex device late in the cycle is slow and expensive, and any interim operating arrangement stays in place longer than intended.
How the work runs
Anchor the DAL
Confirm the assigned design assurance level and the hardware objectives it drives for the installation.
Trace requirement to verification
Follow each hardware requirement through design data to the verification result meant to satisfy it.
Test coverage on complex items
Check that programmable and complex devices carry coverage evidence to the depth the DAL requires.
Plan the closure
Sequence the missing hardware evidence and any reuse justifications for completion before submission.
What the buyer receives
- A gap assessment referenced to the objectives of the assigned DAL
- An evidence map tying hardware requirements through design to verification
- A closure plan for the missing or shortfall hardware evidence
Who uses the output
- Engineering leads scoping what hardware verification still has to be produced
- Compliance managers building the electronic-hardware portion of the field-approval package
- Maintenance leadership planning around when the equipment can be cleared for service
How the work fits into the transaction or program
The review stands between the hardware vendor's lifecycle data and the FAA's read of the field approval. It turns reused and program-specific hardware artifacts into a DAL-based coverage picture, and the closure plan drives the remaining verification into the package before submission instead of during a return cycle.
Start with a single asset
Reduce finding cycles by checking the package first.
Regulatory limits
The work assesses electronic hardware lifecycle data against the objectives of the assigned DAL and reports the shortfalls. It does not set the DAL, make a compliance finding, approve the hardware data, or determine airworthiness. Those remain FAA decisions.
What this review does not cover
- Designing, modifying, or re-verifying the electronic hardware itself
- Assigning or changing the design assurance level
- Any approval or airworthiness determination on the installed device
Specific to this review
- Complex programmable devices are where hardware verification coverage most often fails to reach the assigned DAL.
- Hardware reused from a lower-assurance program needs a fresh justification at a higher DAL, beyond the evidence it originally carried.
- A device revision mismatch between the configuration index and the verified article can invalidate otherwise complete evidence.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
U.S. Government (eCFR). Maintenance recordkeeping content and approval-for-return-to-service requirements, including 43.9, 43.11, and Appendix B.
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
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.
Frequently asked questions
How is this different from the software data review?
This one works to DO-254 and the design assurance level of the electronic hardware, where the software review works to DO-178C and a software level. The evidence types differ, and complex programmable devices raise coverage questions that do not arise in the same form on the software side.
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.