Safety-assessment evidence review under ARP4761A

When this review is needed

• A safety case is being assembled and the assessment products need a read before they set the assurance levels.
• The architecture changed and the failure-condition classifications may no longer reflect the design.
• Software or hardware reviews surface derived requirements with no home in the safety assessment.
• A latent-failure or common-cause concern was raised and the supporting analysis needs checking.

The problem

The safety assessment is a set of linked products, and the link between them is where it breaks down. The FHA classifies failure conditions, the PSSA sets requirements to control them, and the SSA shows they are met, yet the three are often produced at different times and stop agreeing. Fault trees use failure rates the FMEA never supplied, classifications outlive the architecture that justified them, and derived safety requirements never reach the teams meant to implement them.

What gets reviewed

• The functional hazard assessment and its failure-condition classifications
• The preliminary system safety assessment and the requirements it sets
• The system safety assessment and the evidence the conditions are met
• The fault tree analyses and the failure data feeding them
• Failure mode and effects analyses and their summaries
• The derived safety requirements and where they land in the development data

What gets validated

• The FHA, PSSA, and SSA classify and address the same failure conditions consistently
• Each failure-condition classification is supported by the analysis behind it
• Failure data in the fault trees is consistent with the FMEA that supplies it
• Each derived safety requirement is allocated and traces into the development data
• Latent failures and common-cause effects are addressed where the architecture exposes them
• Assigned assurance levels follow from the classifications the assessment produced
• The assessment products reflect the current architecture rather than an earlier one

Evidence normally required

• The functional hazard assessment and failure-condition list
• The PSSA and SSA and their supporting analyses
• The fault tree and failure mode analysis material
• The architecture description the assessment applies to
• The derived safety requirements and their allocation records

Common discrepancies

• A failure-condition classification the supporting analysis does not justify
• A fault tree quantified with failure rates absent from the FMEA
• Derived safety requirements that never reached the implementing teams
• Classifications carried over from an architecture the design has since changed
• Common-cause or latent-failure effects unaddressed in an exposed architecture
• Assurance levels inconsistent with the classifications the FHA produced

What is at stake

A failure-condition classification that the analysis does not support can drive the wrong assurance level across software and hardware, either over-building or leaving a gap. A derived safety requirement that never lands forces a late change once the omission is found. When the assessment products disagree, the safety case is reworked under review pressure, and the assurance levels it feeds are unsettled until it is.

How the work runs

What the buyer receives

• A consistency status across the FHA, PSSA, and SSA
• A list of failure-condition classifications without supporting analysis
• An orphaned-requirement view for derived safety requirements that never landed
• A prioritized closure list ordered by assurance-level impact

Who uses the output

• Certification leads assembling the safety case
• Safety engineering teams reconciling the assessment products
• Systems and certification teams confirming the assurance levels the case sets

How the work fits into the transaction or program

The review checks the assessment that sets the assurance levels a systems-development review depends on, and it traces the derived safety requirements into the software and hardware lifecycle data. It closes the loop those reviews open through their derived requirements.

Regulatory limits

Endeavor Elements reviews the applicant's safety-assessment products for consistency against ARP4761A. It does not make airworthiness or safety determinations, set classifications on an authority's behalf, or guarantee acceptance of the safety case.

What this review does not cover

• Making airworthiness or safety determinations
• Issuing any compliance finding or approval
• Producing the missing analyses or derived requirements

Specific to this review

• ARP4761A products form a loop, FHA to PSSA to SSA, and the assessment is only as sound as the weakest agreement between them, which is why cross-product consistency is checked before any single product is deepened.
• A failure-condition classification drives the assurance level for the functions involved, so an unsupported classification can misset the rigor for every implementing item.
• Fault trees and FMEAs are meant to use consistent failure data, so a fault tree quantified with rates the FMEA never produced is a recurring internal contradiction.
• Derived safety requirements are an output of the assessment that must reach development, so their failure to land is a break in the loop rather than a documentation detail.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits