TSO finding closure
Closing hardware data that does not support its assigned design assurance level
This helps equipment suppliers whose complex hardware lifecycle data does not support the design assurance level the article was assigned. A specialist takes the assigned hardware DAL and the DO-254 objectives it carries, then checks the hardware lifecycle data, including its configuration records, to find where evidence is missing, thin, or not tied to the configuration it claims to cover. The work happens during the program, usually after a reviewer questions whether the hardware data matches the assigned DAL. You receive a closure brief listing the shortfalls, an evidence request list for the analyses or verification records to produce, and a disposition package mapping hardware lifecycle data to objectives and to the configuration it belongs to.
When this review is needed
- A reviewer questions whether the hardware lifecycle data matches the objectives for the assigned DAL.
- The hardware DAL was raised after the safety assessment, but the verification data was produced for a lower level.
- Elemental analysis or advanced verification expected at the level is absent from the submitted data.
- The verification records do not identify the exact device configuration and revision they were run against.
The problem
A hardware DAL sets how much design assurance the lifecycle data has to carry, and for complex electronic hardware the objectives climb with the level, adding verification methods and configuration rigor that lower levels do not require. The device also moves under the data: a programmable part goes through revisions, and a verification result only means something against the exact configuration it ran on. When the assigned DAL and the level the data was built to disagree, or when verification records float free of the configuration they cover, the hardware data looks complete but does not stand up against the objectives.
What gets reviewed
- The assigned hardware DAL confirmed against the safety assessment and the DO-254 objectives it carries
- Each applicable objective checked against the hardware lifecycle data for satisfaction and for method
- Verification records checked for the device configuration and revision they were run against
- Advanced verification such as elemental analysis assessed where the assigned level expects it
- Configuration records reconciled so every result ties to a known device configuration
- The path to produce each missing analysis or verification record scoped with an owner
What gets validated
- Every applicable DO-254 objective for the assigned DAL maps to hardware lifecycle data that satisfies it
- Each verification result identifies the device configuration and revision it was produced against
- Advanced verification the assigned level requires is present rather than assumed from the lower level
- The assigned hardware DAL is consistent with the failure condition the hardware contributes to
- Configuration records match the device the verification evidence actually covers
Evidence normally required
- The plan for hardware aspects of certification and the assigned hardware DAL
- The hardware lifecycle data: requirements, design, and verification results
- Configuration records for the device, including revisions and identifiers
- The safety assessment output that sets the hardware DAL
- Any reviewer comments or audit findings on the hardware data
Common discrepancies
- Verification data built to a lower DAL than the safety assessment finally assigned
- A verification result that does not name the device configuration it was run against
- Elemental analysis expected at the assigned level that was never performed
- Configuration records that lag the device revision the results actually cover
What is at stake
Hardware assurance is expensive to reconstruct late, because closing a DAL shortfall can mean regenerating verification against a frozen configuration, running an elemental analysis that was never scoped, or re-tracing results to the device revision they actually cover. These land near the end of the program when the board and its configuration are supposed to be settled. Hardware data that ships claiming a DAL it does not support puts the article's most safety-relevant electronics under a reviewer's closest read, and that is not a finding a supplier closes quickly.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Fix the DAL and its objectives
Confirm the assigned hardware DAL against the safety assessment and enumerate the DO-254 objectives it carries.
Check data and configuration
Test the lifecycle data against each objective and tie every result to the device configuration it covers.
Scope each gap
For every shortfall, scope the analysis or verification record that closes it and name the owner.
Reconcile and hand over
Deliver objectives and results mapped to a known configuration with a disposition package.
What the buyer receives
- A closure brief listing each objective and configuration shortfall at the assigned hardware DAL
- An evidence request list for the analyses and verification records each gap requires
- A disposition package mapping hardware lifecycle data to objectives and to configuration records
Who uses the output
- Certification leadership deciding new verification versus re-argument for each DAL gap
- Hardware leads scheduling verification and analysis against a frozen configuration
- Program management tracking hardware closure against the submittal date
How the work fits into the transaction or program
This checks the hardware submission against the DAL the safety assessment assigned and against the configuration the device actually reached. It sits between hardware development and the compliance submittal, catching the case where the level rose or the device revised while the data stood still, so the objectives evidence ties to a known configuration.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
FAA and EASA both accept DO-254 as the means of compliance for complex hardware, and both expect the objective set and configuration rigor that come with the assigned DAL. The objective and configuration checks are authority-neutral, though a reviewer's depth of hardware engagement can vary with the article and the level.
Regulatory limits
The work maps hardware lifecycle data to objectives and configuration and identifies where it falls short of the assigned DAL. It does not perform the hardware verification, does not assign or approve the DAL, and does not grant any authorization; the level and its acceptance stay with the safety assessment and the authority.
What this review does not cover
- Producing the missing verification records or elemental analyses
- Reassigning the hardware DAL to fit the existing data
- Redesigning the device to reduce the objectives that apply
Specific to this review
- For complex hardware the device revises under the data, so a verification result is only valid against the exact configuration it ran on.
- Elemental analysis is a common shortfall because it is an advanced method the lower levels do not require and the team never scoped.
- A verification record with no configuration identifier cannot be trusted, because nobody can prove which device revision it covers.
- Late DAL increases hit hardware harder than software, since re-verifying against a frozen board competes with the board actually being frozen.
Sources
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.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Frequently asked questions
Why does every hardware verification result need a configuration identifier?
Complex hardware revises during development, so a result run on one device revision may not hold on the next. Without a configuration identifier, a reviewer cannot confirm which revision the evidence covers, and the objective it was meant to satisfy stays open. Tying each result to a named configuration is what makes the assurance argument stand up at the assigned DAL.
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.