ARP4761A safety-assessment support for airborne systems

When this review is needed

• A system is approaching review and the safety assessment chain has to be checked end to end, from hazard to objective to evidence.
• The FHA classified the failure conditions early and the architecture has since changed, so the PSSA and SSA may no longer reflect the design.
• Quantitative objectives in the fault trees rely on failure rates and exposure times that need to be confirmed against the latest data.
• Common cause analysis was deferred and whether the independence claimed in the fault trees actually holds needs to be established.
• A supplier wants an independent read of the safety assessment before it drives the DAL assignment in a wider submittal.

The problem

ARP4761A is the analysis that everything else hangs from, and its weakest link is usually continuity. The FHA classifies failure conditions, the PSSA derives the safety requirements and the architecture to meet them, and the SSA is supposed to show the built system actually does, but the three are often written at different times by different hands. Fault trees inherit independence assumptions that the common cause analysis never confirmed, and the derived safety requirements that the analysis produced do not always reach the software and hardware that must implement them.

What gets reviewed

• The functional hazard assessment and the failure-condition classifications it sets
• The preliminary safety assessment and the safety requirements and architecture it derives
• The system safety assessment and how it demonstrates the objectives are met
• Fault tree analyses and the quantitative objectives and exposure times behind them
• Failure modes and effects analyses and how they feed the fault trees
• Common cause analysis, including zonal, particular risks, and common mode
• Derived safety requirements and their flow-down to software and hardware items

What gets validated

• Each failure condition in the FHA carries a classification and a safety objective tied to it
• The PSSA architecture and safety requirements meet the objectives the FHA set
• The SSA demonstrates the built system meets each objective, not only the planned one
• Fault tree independence assumptions are confirmed by the common cause analysis
• Quantitative objectives use failure rates and exposure times traceable to a defensible source
• Latent failures and their exposure intervals are identified and bounded
• Derived safety requirements reach the software and hardware items that must implement them

Evidence normally required

• The functional hazard assessment and its failure-condition classifications
• The preliminary and final safety assessments and the safety requirements they produced
• The fault tree, FMEA, and common cause analyses assembled so far
• The architecture description the safety assessment was performed against
• The failure rate, exposure, and reliability data behind the quantitative claims
• The traceability from derived safety requirements to software and hardware items

Common discrepancies

• Fault tree independence assumed but never confirmed by the common cause analysis
• An SSA that demonstrates the planned architecture rather than the system as built
• Failure rates or exposure times in the fault trees with no traceable source
• Latent failures with no defined exposure interval or detection means
• Derived safety requirements that never reached the items meant to implement them
• Failure-condition classifications in the FHA inconsistent with the DALs they drive
• An FMEA that does not feed the failure modes the fault trees rely on

What is at stake

When the safety assessment does not close its objectives, the development assurance levels it drives are exposed, and the assurance claimed for the software and hardware can collapse with them. A latent failure that the common cause analysis missed, or an objective the SSA never demonstrates, can force redesign at the architecture level late in the program, where the cost lands on every item the safety assessment touches and on the certification schedule.

How the work runs

What the buyer receives

• A safety-assessment gap assessment across the FHA, PSSA, and SSA chain
• A traceability view from hazard to safety objective to the evidence that closes it
• A reconciliation of fault tree independence against the common cause analysis
• A prioritized list of the safety analysis to close before review

Who uses the output

• Certification leads preparing the safety-assessment submittal or review
• Safety engineering teams closing the analysis and common cause gaps
• Systems engineering teams reconciling the architecture with the analysis

How the work fits into the transaction or program

The support strengthens the safety assessment that drives the development assurance levels, so the DALs the rest of the program depends on rest on analysis that closes its objectives. It pairs directly with ARP4754B development-assurance support, since the safety requirements flow from here into the system and item development.

Aircraft-specific considerations

The safety assessment is performed against a function in a specific system and aircraft, so the same equipment can carry different failure-condition classifications depending on what its loss or malfunction means in that installation. A function that is catastrophic in one aircraft may be hazardous or major in another, which changes the safety objectives, the architecture needed to meet them, and the DALs the analysis drives, so the assessment cannot be lifted unchanged from one installation to the next.

Regulatory limits

Endeavor Elements supports the applicant's safety-assessment data. It does not act as the authority or a delegate, make compliance findings, issue any approval, make airworthiness determinations, or guarantee acceptance. The applicant and the authority keep their roles, and the classifications and objectives remain the applicant's, supported by the analysis.

What this review does not cover

• Making official compliance findings, airworthiness determinations, or acting as the authority
• Issuing any approval, authorization, or design approval
• Performing the system design or generating the underlying reliability data itself

Specific to this review

• ARP4761A structures the work as a chain, FHA to PSSA to SSA, so a break at any link leaves the safety objectives unproven even when each document looks complete on its own.
• Fault tree analyses depend on independence between branches, and the common cause analysis, zonal, particular risks, and common mode, is what either confirms or invalidates that independence.
• Latent failures matter because a hidden failure plus a later one can defeat redundancy, so the analysis has to define exposure intervals and detection means rather than assume the redundancy holds.
• Quantitative safety objectives are expressed as probabilities per flight hour tied to the failure-condition classification, so a misclassification in the FHA changes the entire quantitative target downstream.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits