STC hardware evidence
STC program DO-254 electronic hardware lifecycle data support
This review prepares the airborne electronic hardware lifecycle data behind an STC so it supports the assigned design assurance level. A hardware certification engineer runs it after the plans, design data, and verification records exist but before the modifier submits. It reads the hardware plans, requirements and design capture, verification and validation results, and the configuration and accomplishment records, then measures each against the certification basis. You get a gap assessment, a trace map from requirements to verification, and a closure plan the program can act on ahead of formal review.
When this review is needed
- A complex electronic hardware item is going into an STC and its lifecycle data has to support the assigned design assurance level.
- A supplier delivered a hardware data package and the modifier needs it read against the certification basis before submittal.
- The design assurance level was set higher than the supplier's original target and the verification depth has to catch up.
- A programmable device was revised after first article and the modifier needs the delta evidence confirmed.
The problem
DO-254 evidence for a programmable device spreads across requirements capture, conceptual and detailed design, and verification results that each stand on their own methodology. The modifier holds the STC even when the device came from a supplier, so an elemental analysis that thins out, or a verification result that does not close a derived requirement, lands on the modifier's desk. Confirming the data reaches the design assurance level takes hardware engineering judgment the program cannot borrow from its software team.
What gets reviewed
- Hardware plans read against the certification basis and the assigned design assurance level
- Requirements capture and the derived requirements the design introduced
- Conceptual and detailed design data checked against the requirements they implement
- Verification and validation results confirmed to cover the requirements and the assurance level
- Configuration control across the hardware baseline and its revisions
- The hardware accomplishment summary reconciled to the delivered evidence
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
- Every derived requirement carries a verification result and a rationale the assurance level accepts
- Design data traces to the requirements it satisfies without an orphan function
- Verification method matches what the assurance level demands for each requirement class
- Configuration records identify the exact device revision the verification evidence was taken against
- The hardware accomplishment summary references evidence that exists in the delivered package
Evidence normally required
- The hardware plans, including the plan for hardware aspects of certification
- Requirements capture and derived-requirement records
- Conceptual and detailed design data
- Test, analysis, and validation results from verification
- Configuration index and the hardware accomplishment summary
Common discrepancies
- A derived requirement with no verification result and no captured rationale
- A device revision that verification never covered because it postdates the tested article
- Elemental analysis that thins where the design grew most complex
- Design functions with no traceable requirement behind them
What is at stake
Hardware data that falls short of the assurance level invites additional verification demands that reopen the device itself, well past the paperwork. A derived requirement without a traced verification result, or a gap in elemental coverage, can force re-analysis or a design iteration that the STC schedule was never sized for. Once formal review flags the shortfall, the correction competes with every other open item on the program.
How the work runs
Fix the assurance level
Confirm the assigned design assurance level and the certification basis the hardware evidence must meet.
Trace requirements to design
Check that captured and derived requirements map to design data with no orphan functions.
Confirm verification depth
Match verification method and coverage to what the assurance level requires for each requirement.
Plan the closure
Sequence the missing verification and analysis so it completes before formal review.
What the buyer receives
- A gap assessment mapping hardware requirements and objectives to their evidence
- A trace map from requirements through verification for the authority package
- A closure plan sequencing the missing verification and analysis before formal review
Who uses the output
- Hardware certification engineers judging whether the device data is ready to submit
- Program managers fitting the hardware closure into the STC timeline
- Modifiers accountable for a supplier's electronic hardware on their STC
How the work fits into the transaction or program
The review connects a supplier's hardware delivery to the modifier's STC submittal. It gives the program a hardware-specific read that the software review does not cover, so the accomplishment summary rests on verification results that exist, and its closure plan schedules the analysis and testing that has to finish before the package goes formal.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both accept DO-254 for complex electronic hardware, but expectations on derived requirements and elemental coverage can differ by authority and reviewer, so the review flags where a package built for one may need additional rationale for a validating authority.
Regulatory limits
The review reads the hardware lifecycle data against the assigned assurance level and the certification basis. It does not set the design assurance level, approve the hardware, sign a compliance finding, or make an airworthiness determination on the installation.
What this review does not cover
- Performing or repeating the hardware verification and validation
- Assigning or changing the design assurance level
- Signing a hardware compliance finding or approving the modification
Specific to this review
- Derived requirements are where DO-254 packages most often thin, because the design introduces them and no upstream requirement forces their verification unless someone checks.
- A device revision after first article can silently invalidate verification results taken against the earlier baseline, so the configuration link between evidence and revision is checked explicitly.
- Raising the assurance level after design freeze reopens elemental coverage that lower-level verification never produced, which is the costliest DO-254 gap to close late.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. STC application process, certification basis, and continued airworthiness obligations of an STC holder.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Frequently asked questions
Does this overlap with the DO-178C software review?
They are separate disciplines. The software review reads DO-178C lifecycle data, this one reads DO-254 electronic hardware data, and each uses methods the other does not. A device with both programmable logic and hosted software needs both reviews, coordinated so the accomplishment summaries agree at the item boundary.
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.