Safety assessment evidence review for software assurance teams

When this review is needed

• A submittal depends on the safety assessment and no one has checked that its results feed the requirements the design was built to.
• The authority questioned whether a failure condition classification is supported by the analysis behind it.
• A design change moved a failure condition and the assessment has to be re-flowed to catch what shifted.
• The FHA, PSSA, and SSA were authored at different points and their assumptions may no longer agree.

The problem

The safety assessment is a chain, and each link is often produced by a different engineer at a different phase. An FHA sets failure condition classifications, the PSSA turns them into requirements, and the SSA is supposed to show the design meets them. When the design shifts between those steps, the SSA can quietly diverge from the FHA it started with, and the derived safety requirements can stop matching what verification actually tested.

What gets reviewed

• The FHA and its failure condition classifications at aircraft and system level
• The PSSA and the derived safety requirements it produces
• The SSA and the argument that the implemented design meets those requirements
• Requirement feedback linking safety results to the system and item requirements
• Consistency of assumptions and failure conditions across the three documents
• Alignment between failure condition severity and the assurance levels assigned downstream

What gets validated

• Each failure condition in the FHA carries through to a derived requirement in the PSSA
• Derived safety requirements trace to verification evidence that closes them
• The SSA argues against the same failure conditions the FHA classified, with no silent reclassification
• Assumptions stated in one document are not contradicted by another
• Assurance levels assigned to software and hardware match the severity the assessment established

Evidence normally required

• The FHA at aircraft and system level
• The PSSA with derived safety requirements
• The SSA and its supporting analyses
• Requirement feedback and the system requirements it connects to
• The change history if a design change prompted the review

Common discrepancies

• A failure condition classified in the FHA that never became a derived requirement
• An SSA that argues against a failure condition the FHA later reclassified
• A derived safety requirement with no verification evidence closing it
• An assumption in the PSSA that a design change has since invalidated

What is at stake

A safety case that does not close leaves failure condition claims unsupported, which is exactly what an authority reviewer probes first. A late break in the chain can force reclassification, new requirements, and fresh verification at a point in the program where none of that was budgeted, and it can unravel the design assurance levels that flow from the classifications.

How the work runs

What the buyer receives

• A gap list keyed to the failure conditions and requirements that do not close
• An evidence map connecting each safety claim to the requirement and verification behind it
• A closure sequence ordering the re-analysis and re-verification a break requires

Who uses the output

• Assurance leads confirming the safety case will hold under authority review
• Certification leadership answering a finding on a failure condition or classification
• Engineering leads scoping the re-analysis a design change forced into the assessment

How the work fits into the transaction or program

The safety assessment sits upstream of nearly everything else in the submittal, since it sets the assurance levels that DO-178C and DO-254 evidence are then held to. Reading it for internal consistency before submittal keeps a break from propagating into every downstream package that depends on its classifications.

Jurisdiction-specific considerations

FAA and EASA both recognize the ARP4761A and ARP4754B framework, but they express the acceptable safety objectives and the required analyses through different advisory material, and EASA certification review items can pin specific expectations on how a failure condition is argued. The review notes where a safety argument would satisfy one authority and draw a question from the other.

Regulatory limits

This review reads the safety evidence for consistency and traceability. It does not perform the safety analysis, classify a failure condition, or make a compliance finding. The safety determination and its acceptance rest with the applicant and the authority.

What this review does not cover

• Authoring or re-running the FHA, PSSA, or SSA analyses
• Classifying or reclassifying a failure condition
• Any compliance finding on the safety case

Specific to this review

• The FHA-to-SSA divergence is the classic break, because the SSA is finished long after the FHA and rarely re-checked against it.
• A reclassified failure condition ripples into every assurance level derived from it, so a late change is more expensive than it first looks.
• Derived safety requirements are the ones most often left without verification, since they appear during analysis rather than in the initial requirement set.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits