Safety assessment evidence review for avionics suppliers

When this review is needed

• The safety assessment is heading into a data package and no one has checked that FHA, PSSA, and SSA tell one consistent story.
• A derived safety requirement was identified in the PSSA and the team is unsure it ever reached the design.
• A finding questions whether an assigned assurance level matches the failure condition classification behind it.
• A design change alters a function and the affected failure conditions need their assessment reopened.

The problem

A safety assessment is produced in stages by different people over a long span, and the seams between the FHA, the PSSA, and the SSA are where it comes apart. A failure condition gets classified early, the architecture shifts, the assurance level assigned in the PSSA is never reconciled against the SSA, and the derived safety requirements that were supposed to constrain the design get logged and forgotten. The document set looks complete while the argument inside it has gaps.

What gets reviewed

• Failure conditions traced from the FHA through the PSSA into the SSA with consistent classification
• Assurance levels reconciled so the PSSA assignment matches the SSA result and the item's DAL
• Derived safety requirements confirmed captured and fed back into requirements and design
• Quantitative and qualitative results in the SSA checked against the failure condition classifications
• Common cause and independence claims reviewed for the analysis that supports them
• Effects of any design change traced to the failure conditions and requirements it touches

What gets validated

• Each failure condition carries a consistent classification across the FHA, PSSA, and SSA
• Assigned assurance levels reconcile between the PSSA, the SSA, and the software and hardware evidence
• Every derived safety requirement traces into the design and on to its verification
• SSA results, quantitative or qualitative, meet the target set by the failure condition classification
• Common cause and independence claims rest on documented analysis, not assertion

Evidence normally required

• The functional hazard assessment with its failure conditions and classifications
• The preliminary system safety assessment and the derived safety requirements it produced
• The system safety assessment with its quantitative and qualitative results
• The requirement set and design data the safety requirements were meant to constrain
• Common cause analysis and any change records affecting assessed functions

Common discrepancies

• A failure condition classified one way in the FHA and carried at a different level into the SSA
• Derived safety requirements captured in the PSSA that never appear in the requirement baseline
• Assurance levels in the safety argument that the software or hardware evidence does not actually meet
• Independence claimed in the architecture without the common cause analysis to support it

What is at stake

A safety assessment that does not close is the most consequential kind of gap, because the assurance levels it sets drive the entire software and hardware effort beneath it. If a failure condition was underclassified, every objective downstream was scoped too low, and correcting it late reopens verification across the item. An authority reads the safety argument first, and a break there colors how it reads everything else.

How the work runs

What the buyer receives

• A gap list naming each break in the safety trace or reconciliation between the assessment stages
• An evidence map from failure condition to safety requirement to verification
• A closure sequence that treats classification and level gaps as upstream fixes ahead of downstream cleanup

Who uses the output

• Certification leadership judging whether the safety argument is ready to anchor the data package
• Safety and systems engineers who need the specific traces and requirements to reconcile
• The team responding to a safety finding an authority has raised about level or classification

How the work fits into the transaction or program

The safety assessment sits at the top of the assurance chain; it sets the levels the DO-178C and DO-254 evidence must meet and defines the derived requirements the design must honor. This review checks that top layer for consistency, so a classification or level error is caught before it has propagated into thousands of downstream objectives.

Jurisdiction-specific considerations

FAA and EASA both accept the ARP4761A and ARP4754B framework for the safety and development assurance argument, though the classification of a failure condition and its target can be argued differently under each basis. The review reads the assessment against whichever failure condition definitions and acceptable means of compliance the program is working to, since the target that flows down depends on that choice.

Regulatory limits

This review checks the internal consistency and traceability of the supplier's safety assessment and reports where it breaks. It does not classify failure conditions on the authority's behalf, does not accept the safety argument, and does not make an airworthiness determination. Those judgments stay with the authority and the applicant.

What this review does not cover

• Performing the FHA, PSSA, SSA, or common cause analysis the gaps call for
• Reclassifying a failure condition or setting its target as an authority would
• Accepting the safety argument or issuing a compliance finding on it

Specific to this review

• The costliest gap in the whole certification is an underclassified failure condition, because every assurance level and objective beneath it was scoped to the wrong target.
• Derived safety requirements are the connective tissue of the assessment and the thing most often lost, since they are born in the analysis and have no home in the original requirement set.
• Assurance level reconciliation is a three-way check: the PSSA assignment, the SSA result, and the actual software and hardware evidence all have to agree, and they are usually maintained by different people.
• Independence claimed in the architecture is only as good as the common cause analysis behind it, and that analysis is frequently asserted rather than documented.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits