Safety assessment evidence review for equipment suppliers

When this review is needed

• The FHA, PSSA, and SSA were produced at different phases and no one has read them against each other since the design settled.
• A safety requirement or an assigned assurance level from the PSSA may never have made it back into the requirement set.
• A design change alters a failure path and the classification of an affected failure condition needs revisiting.
• A finding challenges whether the SSA actually closes the failure conditions the FHA identified.

The problem

The safety assessment is written as a sequence, but it is judged as a whole. The FHA names failure conditions and severities, the PSSA turns those into safety requirements and assurance levels, and the SSA is supposed to show they were met. In practice these documents drift apart: a classification changes in one and not the others, a safety requirement is written but never allocated, an assurance level is assigned but never flows to the software or hardware that inherits it.

What gets reviewed

• Consistency check across the FHA, PSSA, and SSA for failure conditions and classifications
• Confirmation that safety requirements from the PSSA appear in the requirement set
• Trace of assigned assurance levels into the software and hardware that inherit them
• Read of the SSA to confirm each identified failure condition is addressed and closed
• Review of how design changes propagated through the safety assessment
• Identification of safety results that do not trace to requirements or verification

What gets validated

• Failure conditions and their classifications match across the FHA, PSSA, and SSA
• Every safety requirement from the PSSA is present in the requirement set
• Each assigned assurance level flows to the software or hardware that must meet it
• The SSA addresses every failure condition the FHA identified, with none left open
• Safety results trace to the requirements and verification that substantiate them

Evidence normally required

• The functional hazard assessment with failure conditions and classifications
• The preliminary system safety assessment with safety requirements and assigned levels
• The system safety assessment showing the implemented design
• The requirement set the safety requirements should appear in
• The change history for design changes that touched safety-relevant paths

Common discrepancies

• A failure condition reclassified in the SSA but left unchanged in the FHA
• Safety requirements written in the PSSA that never entered the requirement set
• An assurance level assigned in the PSSA that the software was not actually built to
• SSA closure resting on a mitigation the verification evidence does not demonstrate

What is at stake

When the safety chain has a break, the consequences reach past the safety documents. An assurance level that never reached the software means the DO-178C data was built to the wrong target. A failure condition the SSA does not close is an open safety claim, which is the kind of finding that holds a certification rather than merely delaying a document. Late discovery can reopen software, hardware, and verification at once.

How the work runs

What the buyer receives

• A gap list of inconsistencies and unclosed failure conditions across the safety set
• An evidence map from each failure condition to its requirement, level, and closure
• A closure sequence ordering fixes by the downstream data each inconsistency touches

Who uses the output

• Engineering leadership judging how far a safety inconsistency reaches into the design data
• Certification leads presenting the safety argument to the authority
• Safety engineers reconciling the FHA, PSSA, and SSA and the requirements they feed

How the work fits into the transaction or program

The safety assessment sets the assurance levels the DO-178C and DO-254 branches are built to, so its consistency is checked before those data sets are trusted. Its findings can reopen the requirements trace, since safety requirements that never entered the requirement set leave the trace itself incomplete.

Jurisdiction-specific considerations

ARP4761A supplies the safety assessment methods and ARP4754B ties them to development assurance, and both FAA and EASA expect the assurance levels to originate here and propagate outward. Classification thresholds and acceptable probabilities are anchored in each authority's regulations, so this review flags where a classification would be read differently across the two.

Regulatory limits

This review evaluates the internal consistency and feedback of the safety assessment. It makes no airworthiness determination, approves no safety claim, and does not decide whether the assessment satisfies the authority. That acceptance rests with the authority and its delegated safety specialists.

What this review does not cover

• Performing the FHA, PSSA, or SSA or their supporting analyses
• Reclassifying failure conditions or reassigning assurance levels
• Judging the adequacy of the system's safety design itself

Specific to this review

• The safety assessment is graded as one argument even though it is written as three documents, so a classification that changes in one and not the others is a common and consequential break.
• An assurance level that stops at the PSSA and never reaches the software or hardware means downstream data was built to the wrong target long before anyone noticed.
• A safety requirement can exist in the PSSA and be absent from the requirement set, which makes the requirements trace itself quietly incomplete.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits