STC program safety assessment evidence support

When this review is needed

• A modification changes an aircraft function and the safety assessment has to support the STC classification.
• The FHA, PSSA, and SSA were written across different teams and the modifier needs them read as one coherent set.
• A failure condition was reclassified during development and the downstream requirements and verification have to be re-checked.
• Software and hardware assurance levels were flowed down from the safety assessment and the modifier needs the flowdown confirmed.

The problem

Safety evidence is a chain, and it only holds if every link is intact: the FHA classifies a failure condition, the PSSA derives requirements to control it, and the SSA verifies they were met. When those artifacts are written at different times by different people, a reclassified hazard or a requirement that never got a verification result leaves the chain broken in a way that reads fine until an authority pulls on it. The assurance levels the software and hardware teams built to all trace back here, so a break propagates.

What gets reviewed

• The functional hazard assessment and the classification assigned to each failure condition
• Derived safety requirements traced from the hazards they control
• Preliminary and system safety assessment results against those requirements
• Assurance level flowdown to the software and hardware development
• Common-cause and particular-risk considerations for the installation
• Requirement feedback and its effect on the safety conclusions

What gets validated

• Each classified failure condition has a derived requirement that controls it
• Every derived safety requirement carries a verification result that closes it
• The assurance levels flowed to software and hardware match the classification the safety assessment assigns
• Reclassified failure conditions carry consistent requirements and verification after the change
• Common-cause and particular-risk analyses cover the installation as modified, not the base aircraft alone

Evidence normally required

• The functional hazard assessment for the modified function
• The preliminary and system safety assessments
• The derived safety requirements and their verification results
• The assurance level flowdown to software and hardware
• The certification basis and the classification criteria in use

Common discrepancies

• A failure condition classified without a derived requirement to control it
• A safety requirement with no verification result to close the loop
• An assurance level in the software or hardware that does not match the safety classification
• A reclassified hazard whose downstream requirements were never updated

What is at stake

A safety assessment whose conclusions do not trace draws a finding that reaches past the safety artifacts into the software and hardware evidence that inherited its assurance levels. A failure condition classified without a supporting requirement, or a derived safety requirement with no verification, can force re-analysis that unwinds work already closed. Late in the program, that is the finding most likely to move the certification date.

How the work runs

What the buyer receives

• A gap assessment across the FHA, PSSA, and SSA artifacts
• A trace map linking hazards, requirements, and verification results
• A closure plan for the analyses and verification that do not yet resolve

Who uses the output

• Safety engineers confirming the assessment chain is intact before submittal
• Certification leads reconciling assurance levels across safety, software, and hardware
• Program managers scheduling the safety closure against the STC date

How the work fits into the transaction or program

The safety assessment sits upstream of the software and hardware evidence, because it sets the assurance levels those disciplines build to. This review confirms the chain is whole before the derived levels are treated as settled, so a break here is caught before it has propagated into verification the modifier already paid for.

Jurisdiction-specific considerations

ARP4761A and ARP4754B underpin safety assessment for both FAA and EASA, but classification thresholds and the depth of particular-risk analysis an authority expects can vary, so the review notes where a validating authority may want the assessment extended.

Regulatory limits

The review reads the safety evidence for internal trace and consistency with the certification basis. It does not classify failure conditions on an authority's behalf, approve the safety assessment, sign a compliance finding, or determine that the modification is safe to fly.

What this review does not cover

• Authoring the FHA, PSSA, or SSA in the first instance
• Setting failure-condition classifications on the authority's behalf
• Signing off a safety compliance finding or clearing the change to fly

Specific to this review

• The safety assessment sets the assurance levels every software and hardware artifact builds to, so an unresolved break here quietly invalidates evidence downstream.
• A reclassified failure condition is the most common propagating defect, because the classification changes but the requirements and verification written to the old level often do not.
• Common-cause and particular-risk analyses have to cover the installation as modified, and a base-aircraft analysis carried forward unchanged is a frequent shortfall.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits