Type-design packages
DO-254 electronic hardware lifecycle data support for a type-design package
This review reads the DO-254 lifecycle data for complex airborne electronic hardware in a type-design data package and checks it against the design assurance level the hardware carries. It confirms the hardware plans, design data, verification results, and configuration records are present, agree with each other, and support the assigned DAL. A certification engineer runs it so the hardware data set does not claim assurance its evidence cannot back. You get a DAL-coverage assessment, a list of missing or inconsistent hardware lifecycle data, and a plan to close the gaps before submission.
When this review is needed
- Hardware development is complete and the data needs checking against its design assurance level.
- A device was reused from an earlier program at a different DAL than this application requires.
- Verification of a programmable device relied on methods whose sufficiency for the DAL is unclear.
- A reviewer will read the hardware data against DO-254 and the applicant wants gaps found first.
The problem
DO-254 evidence for programmable devices is generated across design, synthesis, and test, and the assurance argument depends on the design assurance level the device inherited from the safety assessment. Verification that looks thorough may not reach the coverage the DAL expects, and design data reused from a lower-assurance program carries assumptions that no longer hold. The configuration records rarely keep pace with late device revisions, so the data set describes a version that is not the one built.
What gets reviewed
- Hardware plans and standards checked for presence against the assigned design assurance level
- Design data checked to support the assurance argument the DAL requires
- Verification results checked to meet the coverage the DAL expects
- Configuration records reconciled to the actual device revision built and tested
- Reused or previously developed hardware assessed against this application's DAL
- Elemental analysis or other DAL-driven methods checked where the level requires them
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
- The hardware plans and standards match the assigned design assurance level
- Design data supports the assurance argument for the assigned DAL
- Verification results provide the coverage the DAL requires for the device
- Configuration records identify the exact device revision that was built and verified
- Reused hardware is shown to meet this application's DAL rather than resting on its original one
Evidence normally required
- The hardware plans, including the hardware verification and configuration plans
- The hardware design data and requirements for the device
- The verification results, including test and analysis records
- The hardware configuration index and revision records
- The provenance of any reused or previously developed hardware
Common discrepancies
- Verification coverage below what the assigned DAL expects for the device
- Design data reused at a lower assurance level than this application requires
- Configuration records that point at a device revision other than the one tested
- DAL-driven analysis expected by the level that is absent from the data set
What is at stake
Hardware lifecycle data that falls short of its DAL produces findings that are expensive to close, because additional verification of a fabricated device is slow and sometimes requires a new build. Reused design data that no longer fits the assurance argument has to be re-justified or replaced. If the configuration records point at the wrong device revision, every downstream claim is suspect, and the reviewer widens the review to check them all.
How the work runs
Fix the DAL
Confirm the assigned design assurance level and what it demands of the hardware data.
Test the assurance argument
Check design data and verification against the coverage and methods the DAL requires.
Reconcile the revision
Confirm the configuration records point at the exact device that was built and tested.
Order the closures
Sequence the gaps, flagging additional verification or a new build so it starts first.
What the buyer receives
- A DAL-coverage assessment across the hardware lifecycle data
- A gap list of missing, inconsistent, or under-covered hardware data
- A closure plan flagging where additional verification or a new build is needed
Who uses the output
- Certification leads who present the hardware data in review
- Hardware and verification engineers who close the DAL gaps
- Configuration managers who tie the data to the correct device revision
How the work fits into the transaction or program
The hardware lifecycle data is a discipline's evidence under the compliance map, and its assurance argument rests on the DAL the safety assessment assigned to the hardware. This review confirms the data supports that DAL before it is offered as compliance evidence, alongside the software data set that shares the same safety-driven levels. It follows the safety assessment and feeds the compliance map.
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, and both agree the assurance approach with the applicant early, but acceptable verification methods and the treatment of commercial devices can differ in detail. The review reads the data against the approach agreed for the target authority rather than a single interpretation of the standard.
Regulatory limits
This work checks whether the hardware lifecycle data supports its assigned design assurance level. It does not develop or verify hardware, does not make a compliance finding, and does not determine airworthiness or grant approval. Those remain with the applicant and the authority.
What this review does not cover
- Performing hardware development or verification activities
- Revising the hardware plans or design data
- Making the compliance finding for the hardware
Specific to this review
- The design assurance level is inherited from the safety assessment, so a device can be short of evidence purely because this application assigned it a higher DAL than its original program did.
- Additional verification of a fabricated device is far slower to add than for software, which makes a late DAL shortfall one of the hardest package findings to recover from.
- Configuration records for programmable devices lag late revisions easily, and a wrong revision reference casts doubt on every claim built on top of it.
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. FAA type certification process, certification basis establishment, and compliance findings.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
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
Can we reuse hardware qualified at a lower DAL?
Only after it is shown to meet this application's DAL. A device developed to a lower assurance level carries verification and design assumptions that may not reach the higher level, so the reuse has to be justified or supplemented. This review identifies exactly where the reused data falls short.
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.