Safety assessment evidence review for qualification test teams

When this review is needed

• The safety assessment is being folded into the submittal and its results have not been traced through to verification.
• A finding questioned whether a hazard classification was carried into a requirement.
• A design change altered a failure condition and the assessment has to be revisited.
• The DALs the assessment set have to be reconciled against the software and hardware actually built.

The problem

The safety assessment produces conclusions that are supposed to become requirements: a hazard classification sets a DAL, a failure condition drives a mitigation, a PSSA assumption becomes something design has to honor. The break happens between the assessment and the requirement set. A conclusion is reached in the SSA and never becomes a verified requirement, or design assumes a safety requirement the assessment never actually generated. The documents each look complete on their own, and the gap sits in the handoff between them.

What gets reviewed

• FHA failure conditions traced to the requirements meant to address them
• PSSA assumptions confirmed to have become requirements the design honors
• SSA results traced to the verification that closes them
• DALs set by the assessment reconciled against the levels the design was built to
• Safety requirements the design assumes confirmed to exist in the assessment
• Open safety findings and their status carried into the closure argument

What gets validated

• Each significant failure condition traces to a requirement that addresses it
• Every PSSA assumption is reflected in a requirement the design actually honors
• SSA conclusions trace to verification, beyond the analysis alone
• The DALs the assessment assigns match the levels the software and hardware were built to
• No safety requirement the design relies on is absent from the assessment

Evidence normally required

• The FHA, PSSA, and SSA and their supporting analyses
• The requirements baseline the safety results are meant to drive
• The verification evidence closing the safety-driven requirements
• The DAL assignments and their basis
• The change record for anything that disturbed a failure condition

Common discrepancies

• An SSA conclusion that never became a verified requirement
• A safety requirement the design assumes but the assessment never generated
• A DAL in the assessment that does not match the level the evidence was built to
• A PSSA assumption left unconfirmed by the delivered design

What is at stake

A safety conclusion that never became a verified requirement is a serious finding, because it means the argument that the design is acceptably safe has a hole the whole certification rests on. Reconciling it late can reopen the DAL assignment, which cascades into the software and hardware evidence built against those levels. A safety gap is the kind that does not stay contained; it pulls other evidence stacks back open with it.

How the work runs

What the buyer receives

• A gap list of orphaned safety conclusions and missing safety requirements
• A traceability map linking safety results to requirements and verification
• A closure order ranking gaps by how much dependent evidence each reopens

Who uses the output

• Test leadership sizing the requirements and verification the safety argument still owes
• Certification leadership defending the safety argument to an authority
• Engineering leads reconciling DAL assignments with the evidence actually built

How the work fits into the transaction or program

The safety assessment sets the DALs and the safety requirements the rest of the evidence is built to satisfy, so a gap here undermines the software, hardware, and verification stacks downstream. This review runs so those dependencies are sound before the package is submitted. Its findings often send work back into the trace and lifecycle data reviews, because a changed DAL changes what those stacks owe.

Jurisdiction-specific considerations

ARP4761A and ARP4754B are recognized by both the FAA and EASA as means of conducting and integrating the safety assessment, but the two can weight the qualitative and quantitative arguments differently for a given failure condition. The review notes where a safety argument accepted on one side would need reinforcement on the other for a dual-validation program.

Regulatory limits

The review confirms that safety results trace coherently into requirements and verification. It does not perform the safety assessment, judge whether a hazard classification is correct, or determine that the design is acceptably safe. That determination rests with the authority.

What this review does not cover

• Conducting or revising the FHA, PSSA, or SSA
• Assigning hazard classifications or DALs
• Any airworthiness or safety determination on the design

Specific to this review

• The safety gap lives in the handoff, where a conclusion in the SSA never becomes a verified requirement, so neither document alone reveals it.
• A DAL that the evidence was not actually built to is the costliest safety finding, because it reopens the software and hardware stacks that assumed the level.
• Design sometimes honors a safety requirement the assessment never wrote down, which reads as compliance but leaves the argument unsupported.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits