Safety assessment support for a type-design data package

When this review is needed

• The safety assessment is drafted and the applicant needs its links to requirements and verification checked.
• The design changed after the PSSA and the SSA may not reflect the current architecture.
• Assigned software or hardware assurance levels came from the safety assessment and need to reconcile with it.
• A reviewer will test whether the safety results actually close and the applicant wants breaks found first.

The problem

A safety assessment is a chain of documents produced at different phases, and the chain is only as good as the links between them. The FHA names failure conditions, the PSSA allocates safety requirements, and the SSA is supposed to show they were met, but the design moves between phases and the SSA can validate an architecture that no longer exists. Safety requirements that were derived from the assessment slip out of the main requirements set, so the verification side never picks them up.

What gets reviewed

• The FHA failure conditions traced into safety requirements in the requirements set
• The PSSA allocation checked against the current architecture and the assigned assurance levels
• The SSA results traced back to the failure conditions and the safety objectives
• Derived safety requirements checked for capture and verification
• Consistency between the assessment phases and the design they describe
• The assurance levels the assessment assigns reconciled with the software and hardware data sets

What gets validated

• Each FHA failure condition maps to a safety requirement in the requirements set
• The PSSA allocation matches the current architecture, not a superseded one
• SSA results trace back to the failure conditions and show the safety objectives met
• Derived safety requirements appear in the requirements set and carry verification
• Assurance levels assigned by the assessment match those claimed by the software and hardware data

Evidence normally required

• The FHA with its identified failure conditions and classifications
• The PSSA with allocated safety requirements and assigned assurance levels
• The SSA with its results and closure of the failure conditions
• The requirements set, to confirm safety requirements are captured
• The current architecture description the assessment should reflect

Common discrepancies

• Failure conditions in the FHA with no matching safety requirement in the requirements set
• A PSSA allocation made against an architecture the design has since changed
• SSA results that do not close back to the failure conditions they address
• Derived safety requirements that were never verified because they left the main set

What is at stake

A safety assessment that does not close leaves the central argument of the whole package unproven, and a reviewer treats that as fundamental rather than a detail. When SSA results do not trace to requirements and verification, the applicant is asked to reconstruct the safety argument late, often after the design has changed again. The assurance levels assigned to software and hardware depend on the assessment, so a break here can invalidate work far downstream.

How the work runs

What the buyer receives

• An assessment of the safety loop from FHA through PSSA to SSA closure
• A break list of results that do not trace to requirements or verification
• A closure plan ordering the breaks, with assurance-level conflicts flagged early

Who uses the output

• Certification leads who present the safety argument in review
• Safety and systems engineers who reconnect the assessment to requirements and verification
• Configuration managers who reconcile the assessment against the current architecture

How the work fits into the transaction or program

The safety assessment is where the assurance levels for software and hardware come from, and where the compliance map's safety requirements originate. This review confirms the assessment closes to requirements and verification before those downstream data sets are checked against the levels it sets. It sits early in the evidence chain and constrains almost everything after it.

Jurisdiction-specific considerations

FAA and EASA both expect a safety assessment consistent with ARP4761A and the surrounding development-assurance process, and both look for the assessment to close, but the classification of failure conditions and the acceptable analysis depth can be negotiated per project. The review checks the assessment against the approach agreed for the target authority.

Regulatory limits

This work checks whether the safety assessment closes to requirements and verification and is internally consistent. It does not perform the safety analysis, does not make a compliance finding, and does not determine airworthiness or grant approval. Those remain with the applicant and the authority.

What this review does not cover

• Performing the FHA, PSSA, or SSA analysis
• Setting failure-condition classifications or assurance levels
• Making the compliance finding for the safety requirements

Specific to this review

• The safety assessment assigns the assurance levels the software and hardware data are held to, so a break here quietly undermines evidence produced months later.
• The PSSA is the phase most likely to describe an architecture that no longer exists, because the design keeps moving after it is written.
• Derived safety requirements are easy to lose because they originate in the assessment rather than the main requirements set, and what is lost is never verified.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits