Hardware closure evidence
Hardware Accomplishment Summary (HAS) review
A Hardware Accomplishment Summary review checks that an article's HAS reports the airborne electronic hardware program honestly: that the design assurance level, the verification results, and the configuration match what the Plan for Hardware Aspects of Certification committed to under DO-254. It is used by avionics and equipment suppliers closing a complex-hardware program. You receive a reviewed HAS and a list of the claims that lack supporting data, depart from the plan, or do not match the hardware baseline.
When this review is needed
- A complex electronic hardware program is closing and the summary must show the plan was carried through.
- An FPGA or ASIC respin late in the program changed the baseline the data has to reflect.
- Verification methods were substituted during the program and the summary has to account for the change.
- A supplier wants the closure record read before it is folded into the equipment submittal.
The problem
The HAS is where a complex-hardware program proves it followed its plan, and hardware programs are unusually prone to late device changes that the summary fails to track. A respin shifts the baseline, verification that ran against the prior device is reported as if it still applies, and the design assurance argument quietly loses its footing. A reviewer who pulls the device version against the verification records finds the seam fast.
What gets reviewed
- The design assurance level and its consistency with the system safety inputs
- The device baseline each verification result was produced against
- Consistency between the HAS and the commitments made in the PHAC
- Coverage of the DO-254 objectives appropriate to the hardware complexity
- Tool assessment, problem reports, and the disposition stated for each open item
- The device part number and revision the summary reports the program closed against
What gets validated
- Every verification result maps to the device baseline that actually ships
- Each commitment in the PHAC is addressed by a corresponding statement in the HAS
- The design assurance level is consistent with the failure conditions the hardware contributes to
- Tool assessment outcomes support the verification credit the summary claims
- Open and deferred problem reports are disclosed with their disposition
- Verification method substitutions are recorded with the rationale for the change
Evidence normally required
- The current Hardware Accomplishment Summary draft
- The agreed PHAC and companion hardware plans
- The verification results and the device configuration baseline
- The tool assessment records and the problem report register
Common discrepancies
- Verification results reported against a device baseline that a respin superseded
- PHAC commitments the summary never closes
- A design assurance level inconsistent with the contributing failure conditions
- Tool-supported verification credit claimed without a supporting assessment
- Open problem reports omitted from the disposition list
What is at stake
A summary that reports verification against a superseded device baseline forces the program to re-establish coverage on the device that actually ships. That rework lands after the team believed the hardware was done, and it pushes the equipment-level submittal with it.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Pin the device
Identify the device part number and revision the summary closes against and confirm it is the version that ships.
Map verification to baseline
Check that each verification result was produced against the shipping device baseline, not a superseded respin.
Answer the plan
Walk each PHAC commitment and the DO-254 objectives appropriate to the complexity, confirming the summary closes each.
Reconcile and flag
Return the reviewed summary with unsupported claims flagged and a baseline reconciliation attached.
What the buyer receives
- A reviewed HAS with each claim confirmed or flagged
- A list of accomplishment statements that lack supporting data or depart from the plan
- A baseline reconciliation tying verification results to the shipping device version
Who uses the output
- Certification leads folding the closure record into the equipment submittal
- Hardware engineering leads re-establishing coverage on the shipping device
- Program management deciding whether the hardware can close
How the work fits into the transaction or program
The review mirrors the software closure check on the hardware side, holding the summary against the PHAC and the device that ships. Where complex hardware sits inside a TSO article, it feeds the broader certification data the equipment submittal depends on.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
The review checks the applicant's summary against its own plan, verification results, and device baseline. It does not make compliance findings, accept the closure on the authority's behalf, or guarantee the authority will agree the objectives are met.
What this review does not cover
- Accepting the closure or making findings on the authority's behalf
- Performing the hardware verification or re-running coverage on the shipping device
- Assigning the design assurance level or conducting the safety assessment
Specific to this review
- Late device respins make baseline drift the signature HAS finding, distinct from the configuration issues that dominate software closure.
- A HAS is judged against the PHAC; design assurance credit only holds if the verified device is the device that ships.
- Tool-supported verification credit requires a tool assessment to stand behind it, and missing assessments surface during HAS review.
- An FPGA or ASIC carries a part number and revision; a summary that does not pin verification to a specific device revision cannot prove its coverage applies.
Sources
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
SAE International. Safety assessment methods (FHA, PSSA, SSA, FTA, FMEA) supporting development assurance level assignment.
Frequently asked questions
Why does a device respin matter so much to the summary?
Design assurance credit applies to a specific device baseline. If a respin shipped after verification ran, the summary has to show coverage was re-established on the device that ships, or the credit does not hold.
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.
Walk through your situation with an engineer who has done this work.