TSO authorization
DO-254 hardware lifecycle data support for TSO authorization
A DO-254 hardware lifecycle data review confirms that the electronic hardware evidence supports the design assurance level assigned to the article. Equipment suppliers use it before submission, so the delivered data matches the DAL the plan set rather than falling short of it. It checks the hardware plans against the assigned DAL, confirms the design and verification data satisfy the objectives that level requires, and reconciles the configuration records with the hardware the package describes. You get a gap assessment against the DAL objectives, a map from each objective to its hardware lifecycle data, and a closure plan for the objectives the data does not yet meet.
When this review is needed
- The hardware lifecycle data is assembled and has to be checked against the assigned DAL before submission.
- The hardware DAL was raised and the design and verification data have to meet the harder objective set.
- A complex custom device such as an FPGA needs its verification evidence checked against DAL expectations.
- The hardware configuration records have to be reconciled with the fabricated device before the package is finalized.
The problem
DO-254 objectives tighten with the design assurance level, and hardware data that satisfies a lower DAL does not silently rise to a higher one. Plans, design data, verification, and configuration records are generated across the hardware development, and whether they collectively meet the objectives for the assigned DAL is rarely reconciled until the package is being assembled. Complex custom devices carry additional verification expectations that are easy to under-scope early.
What gets reviewed
- Hardware plans checked against the assigned design assurance level
- Requirements and design data confirmed to support the DAL objectives
- Verification evidence appropriate to the DAL, including for complex custom devices
- Configuration management and process assurance records for the hardware
- The reconciliation between the recorded configuration and the fabricated device
- Objectives the assigned DAL requires that the data does not yet address
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 commit to the objective set the assigned DAL requires
- Design and requirements data trace consistently to the verification that addresses them
- Verification evidence for complex custom devices meets the DAL's added expectations
- Configuration records identify the exact device the verification was run against
- Process assurance records cover the hardware development the package claims
Evidence normally required
- The hardware plans and the assigned design assurance level
- Requirements and design data for the electronic hardware
- Verification results including for any complex custom devices
- Hardware configuration management records
- Process assurance records for the hardware development
Common discrepancies
What is at stake
Hardware data that falls short of its DAL is a finding that reopens verification, and for a complex device the missing verification can mean re-work on the design itself rather than added documentation. Configuration records that do not match the fabricated hardware undermine every objective claimed against that configuration, so a reviewer who finds the mismatch questions the whole hardware case.
How the work runs
Set the DAL target
Establish the objective set the assigned design assurance level requires.
Check design to verification
Confirm requirements, design data, and verification trace and meet the DAL objectives.
Reconcile the configuration
Confirm the records identify the exact device the verification was run against.
Close the objectives
List the unmet objectives and sequence the hardware work that closes them.
What the buyer receives
- A gap assessment against the assigned DAL objectives
- A map from each objective to the hardware lifecycle data that meets it
- A closure plan for the objectives the data does not yet satisfy
Who uses the output
- Certification leads presenting hardware compliance to the FAA
- Hardware leads resolving objectives the assigned DAL requires but the data misses
- Program managers tracking which hardware objectives still block the package
How the work fits into the transaction or program
The DO-254 data is the hardware evidence the compliance matrix and the trace point to, so this review runs after the lifecycle data is assembled and before the package closes. Its closure plan drives the remaining hardware verification, and its objective map is how a reviewer works through the hardware case.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
DO-254 is the hardware assurance standard the FAA accepts for the article, so objective coverage is judged against FAA-accepted use of it. The same lifecycle data can support a program under another authority, but the assigned DAL and objective expectations are re-checked rather than assumed identical.
Regulatory limits
The review checks that the hardware data supports the objectives for its assigned DAL. It does not design or verify the hardware, set the DAL, or make a finding that the hardware complies with DO-254.
What this review does not cover
- Designing or verifying the electronic hardware
- Assigning the design assurance level as a regulatory decision
- Issuing an FAA finding on the hardware lifecycle data
Specific to this review
- Complex custom devices such as FPGAs carry verification expectations beyond the base objective set, and those are the ones most often under-scoped when the DAL is set.
- Configuration records that do not pin the exact fabricated device poison every objective claimed against it, because a reviewer cannot tell what was actually verified.
- Raising the DAL late rarely means re-documentation alone: the added objectives often demand design-level verification the hardware was never built to demonstrate.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
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
Does DO-254 apply to all the hardware in the article?
It concentrates on the custom electronic hardware whose failure could affect safety, particularly complex devices. The review scopes the lifecycle data to those items at the assigned DAL, since a complex custom device is where the objective set and the verification expectations are hardest to satisfy.
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.