Skip to main content

​
What ARP 4761 Requires

The standard mandates a top-down, iterative cascade of safety analyses that flows from aircraft-level functions down to individual hardware and software components:
  1. Functional Hazard Assessment (FHA) — identify what can go wrong at the system function level
  2. Preliminary System Safety Assessment (PSSA) — allocate safety requirements down to subsystems
  3. System Safety Assessment (SSA) — verify that the implemented design meets the allocated requirements
  4. Supporting analyses — Fault Tree Analysis (FTA), Common Cause Analysis (CCA), and FMEA fill out the evidence picture
The key insight is that each stage produces outputs that become inputs to the next. An FHA failure condition generates the safety requirements that PSSA tracks. PSSA allocations drive the verification criteria that SSA closes out. The Aerospace Safety Solution captures these hand-offs as first-class traceability links, not manual cross-references in spreadsheets.

​
The Failure Condition as the Central Artifact

At the heart of ARP 4761 is the failure condition — a specific, flight-phase-aware description of what happens when a function fails. The failureCondition work item type captures this with precision:
  • Classification using the ARP 4761 five-level severity scale: Catastrophic, Hazardous, Major, Minor, No Safety Effect
  • Flight phase scoped to one of seven phases (Takeoff, Climb, Cruise, Descent, Approach, Landing, Ground) — because a pressurization failure is far more critical at cruise altitude than on the ground
  • Probability target drawn from the ARP 4761 standard scale: Extremely Improbable (<10⁻⁹) through Probable
  • DAL allocation automatically derived from the classification — a Catastrophic failure condition always requires DAL A; no manual override is needed or permitted
The Design Assurance Level is computed by formula from the failure condition classification. If you override it manually, the allocation will become inconsistent with the severity classification and will fail audit. The formula is intentional — it encodes the ARP 4761 Table 2 mapping.

​
How the Three Risksheet Templates Divide the Work

The FHA → PSSA → SSA cascade maps directly to three risksheet templates, each with its own risk type and column set: diagram FHA Risksheet — the discovery phase. Rows are organized by Function → Failure Condition → Flight Phase, giving safety engineers a systematic way to step through every function at every critical phase. The output is a set of classified failure conditions with DAL allocations. PSSA Risksheet — the allocation phase. Its risk type switches to safetyRequirement, each back-linked to the parent failure condition via the allocatesTo link role. Four custom fields on every safety requirement define where it must be implemented (allocatedSubsystem), how it will be verified (verificationMethod: Test, Analysis, Inspection, or Demonstration), and which failure modes from FMEA contribute to its evidence (contributingFMs). SSA Risksheet — the closure phase. Returns to failureCondition as the risk type, but now the nine-column view shows probability target, DAL, evidence records, verification status, and safety objectives side by side. The SSA is what a certification authority reviews to confirm the loop is closed. A common misconception is that safety requirements are simply documents alongside failure conditions. In the Aerospace Safety Solution, they are connected: the allocatesTo link role creates a traceable edge from each failureCondition to the safetyRequirement that addresses it. This link is what enables the PSSA risksheet to display the source failure condition’s classification and DAL without re-entering data — and it is what the SSA verification view traverses when checking whether all Catastrophic and Hazardous failure conditions have closed verification evidence.
Think of each safety requirement not as a narrative statement but as an obligation record: it documents that a specific failure condition must be mitigated, who is responsible for the subsystem, what evidence will demonstrate compliance, and which FMEA failure modes contribute. The ARP 4761 cascade is the mechanism by which obligations flow from aircraft-level functions down to certifiable design decisions.

​
Severity, Color, and the 5×5 Risk Matrix

The Safety Assessment Summary dashboard visualizes the complete ARP 4761 safety posture. The 5×5 risk matrix plots all failure conditions at the intersection of their five-level severity classification and five-level probability target. Color coding follows a straightforward scheme: green cells indicate combinations that are already acceptably improbable, amber cells warrant monitoring, and red cells demand action. This matrix is not a management artifact — it is a direct translation of ARP 4761 Table 2, which defines the maximum allowable probability for each severity level. A Catastrophic failure condition in a red cell means the design has not yet demonstrated the Extremely Improbable (<10⁻⁹) probability target required by the standard.

​
Supporting Analysis Integration

The FMEA layer (SFMEA for system-level, DFMEA for component-level) feeds back into the ARP 4761 cascade through the contributingFMs field on safety requirements. The riskControl work item type records mitigation actions, and the ARP 4761 Safety Assessment Traceability PowerSheet provides a cross-cutting view that links Safety-Critical Items, Design Requirements, and Failure Mode Analysis in a single matrix — useful when a certification auditor needs to verify that every Catastrophic failure condition has both a safety requirement and a demonstrated risk control.
The specific column layouts, view configurations, and dashboard widget behavior described here are drawn from source configuration files. Field names, enum values, and link role behavior should be verified against the live application before use in certification documentation.
For practical guidance on running the FHA analysis and assigning DAL levels, see Design Assurance Level (DAL) Classification and the Create Your First Functional Hazard Assessment tutorial.
Code: .polarion/tracker/fields/failureCondition-classification-enum.xml (0.74) · .polarion/nextedy/sheet-configurations/ARP 4761 Safety Assessment Traceability.yaml (0.68) · .polarion/pages/spaces/_default/Safety Assessment Summary/page.xml, Common Cause Analysis Report/page.xml, Security Threat Assessment/page.xml, Hara Risk Matrix Report/page.xml (0.67) · .polarion/tracker/fields/safetyRequirement-custom-fields.xml (0.64) · .polarion/nextedy/models/rtm.yaml (0.64) · datasets/sol-aero-ui-walkthrough/summary.md, navigation.md, dashboards/home-dashboard.md, dashboards/role-dashboards.md, dashboards/standards-compliance.md, risksheet-views/risksheet-views.md, work-item-types/data-model.md (0.63) · .polarion/tracker/fields/failureCondition-phase-enum.xml (0.61) · .polarion/tracker/fields/safetyObjective-probability-enum.xml (0.61) · modules/RiskTemplates/SSATemplate/attachments/risksheet.json (0.59) · modules/RiskTemplates/PSSATemplate/attachments/risksheet.json (0.58)