Hardware lifecycle data
Closing STC hardware data inconsistent with its design assurance level
This closure work confirms that an STC's complex electronic hardware carries lifecycle data consistent with its assigned design assurance level under DO-254. It is run for the modifier when the DAL claimed for a hardware item is not matched by the objective evidence, or when the lifecycle data and the configuration records point at different versions of the item. The work compares the delivered hardware data against the objectives the DAL expects, marks the objectives with no supporting evidence, and reconciles the data to the configuration actually installed. You receive an objective map, an evidence request list for the gaps, and a disposition package aligning the hardware DAL, its lifecycle data, and its configuration.
When this review is needed
- Complex hardware is claimed at a DAL the lifecycle data does not fully support.
- The hardware evidence describes a device revision different from the one installed.
- A supplier delivered hardware assured to a lower DAL than the function requires.
- A reviewer asked how the DO-254 objectives are met and the mapping is absent.
The problem
DO-254 governs complex electronic hardware, and each item's DAL sets the objectives its lifecycle data must satisfy. The mismatch shows up two ways: the evidence does not reach the objectives the assigned DAL expects, or the lifecycle data and the configuration records describe different device revisions. Hardware compounds the second problem because a device can be respun during development, and the requirements, verification, and configuration data do not always move together. A DAL stated on a plan is only real if the objective evidence stands behind the exact device that ships in the modification.
What gets reviewed
- The DAL assigned to each complex hardware item
- The DO-254 objective set the DAL expects, mapped to the delivered data
- Objectives with no supporting hardware lifecycle evidence marked as gaps
- The device revision in the lifecycle data reconciled to the configuration records
- A determination of whether the fix is missing evidence, a mis-set DAL, or a configuration mismatch
What gets validated
- Each objective the DAL requires maps to a hardware lifecycle data item
- The device revision in the evidence matches the revision in the configuration records
- The assigned DAL agrees with the level the system safety assessment requires
- Verification evidence covers the installed device, not a superseded respin
- No objective is credited on the plan without a corresponding artifact
Evidence normally required
- The hardware DAL assigned in the plan and the safety assessment
- The DO-254 lifecycle data for the hardware item
- The plan for hardware aspects of certification and the accomplishment summary
- Configuration records identifying the installed device revision
- Supplier data agreements where the hardware was developed elsewhere
Common discrepancies
- Lifecycle evidence describing a device revision that a later respin replaced
- Objectives credited in the plan with no verification artifact behind them
- Hardware assured to a DAL below what the function's safety assessment requires
- Configuration records and requirements data that name different device versions
What is at stake
Hardware evidence short of its DAL can require additional verification or added analysis, and if the DAL itself was set below what the function needs, the shortfall reaches back into the system safety work. A configuration mismatch is worse in one respect: the data may be complete for a device that is not the one installed, so the compliance looks sound until the revisions are compared. A reviewer who finds either will hold the hardware compliance, and the function that depends on the hardware waits with it.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Confirm the DAL and device
Establish the DAL for each hardware item and the device revision the configuration records name.
Map objectives to data
Match each DO-254 objective the DAL expects to a lifecycle data item and flag the gaps.
Reconcile the revision
Check the evidence describes the installed device, not a superseded respin.
Diagnose and package
Separate missing evidence, mis-set DAL, and configuration mismatch, then assemble the disposition.
What the buyer receives
Who uses the output
- Certification leads confirming the hardware meets its DAL before submittal
- Hardware engineering owners producing missing objective or revision evidence
- Program managers scoping rework when a respin or a mis-set DAL is found
How the work fits into the transaction or program
Hardware DAL compliance links the system safety assessment that sets the level to the DO-254 data and the configuration records that have to agree with it. This work runs during finding closure, in step with the software and requirements checks, so a revision or DAL mismatch is caught before a reviewer accepts the hardware compliance the installation relies on.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
DO-254 is recognized by both authorities as the assurance framework for complex hardware, but the acceptance of supplier lifecycle data and the treatment of previously developed hardware can vary between them. The closure work identifies where hardware accepted for one authority needs additional objective evidence or configuration reconciliation to satisfy the other on a validating filing.
Regulatory limits
This work maps hardware data to DO-254 objectives and reconciles it to configuration. It does not develop or verify hardware, set the DAL, approve the modification, or grant the STC. Whether the objective evidence supports the DAL remains the authority's finding.
What this review does not cover
- Performing or re-running hardware verification or lifecycle activities
- Assigning or changing the hardware design assurance level
- Any determination that the hardware satisfies its DAL
Specific to this review
- Hardware carries a configuration risk software does not: a device respin can leave complete lifecycle data attached to the wrong revision.
- A DAL on a plan means nothing until the objective evidence is tied to the exact device that ships in the modification.
- Because a mis-set hardware DAL reaches into the system safety assessment, confirming the level early is cheaper than reworking the safety case later.
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
How does a hardware DAL mismatch differ from a software level mismatch?
Both compare assigned level against objective evidence, but hardware adds a configuration dimension. A device can be respun during development, so the lifecycle data may be complete yet attached to a revision that is not installed. The hardware closure work reconciles the evidence to the configuration records as well as to the objective set.
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.