Skip to main content

​
Two Worlds, One Safety Story

Think of the hierarchy in terms of scope. A failure mode is a localized, component-level event — “the pressure sensor output becomes stuck high.” A failure condition is an aircraft-level consequence — “loss of accurate air data leads to controlled flight into terrain.” The same aircraft-level failure condition can be caused by hundreds of different failure modes across dozens of subsystems. This difference in scope drives everything about how the Aerospace Safety Solution organizes its five risksheet templates and the work item types that underpin them.

​
The Four-Level Analysis Hierarchy

The hierarchy runs from aircraft function down to design characteristic: diagram The key structural insight: failure modes propagate upward through causes links, while safety requirements flow downward through allocatesTo links. The hierarchy is not just a reporting structure — it is a bidirectional traceability graph enforced by the data model.

​
FailureCondition: The ARP 4761 Core Entity

The FailureCondition work item is the primary subject of FHA, PSSA, and SSA analysis. Its fields directly reflect the ARP 4761 standard:
FieldTypePurpose
classificationEnum (5 levels)Severity: Catastrophic, Hazardous, Major, Minor, No Safety Effect
flightPhaseEnum (7 phases)Mission phase where the condition is evaluated
safetyObjectiveFree textFormal objective statement for certification
probabilityTargetEnumAllocated probability budget
dalAllocationEnum (DAL A–E)Auto-derived from classification
gateTypeEnumAND / OR / Inhibit / K-of-N for fault tree use
The dalAllocation field is not entered manually — the FHA risksheet applies an automatic formula: Catastrophic → DAL A, Hazardous → DAL B, Major → DAL C, Minor → DAL D, No Safety Effect → DAL E. This prevents the classification and DAL from diverging.

​
The Bridge Between FMEA and FHA

The most architecturally significant relationship in the hierarchy is the causeOf link from FailureMode to FailureCondition. This is the formal bridge between the FMEA world (component-level, RPN-based, design-oriented) and the FHA world (aircraft-level, probability-based, certification-oriented).
Without causeOf links, you have two disconnected analyses: an FMEA that shows which components are risky, and an FHA that shows which failure conditions are hazardous — but no path to demonstrate that your FMEA work actually addresses your FHA obligations. The causeOf link is what makes that demonstration traceable and auditable.
In the PSSA risksheet, the classification column for each failure condition is auto-populated by reading back through this link — so reviewers see the severity level directly alongside the safety requirement allocation, without manual data entry.

​
How Classification Flows Through the Hierarchy

The five-level ARP 4761 classification palette is applied consistently across all analysis levels:
  • Catastrophic — red
  • Hazardous — orange
  • Major — yellow
  • Minor — green
  • No Safety Effect — grey
This color coding appears not just in cells but in row headers via the rowHeaderClassification decorator, making severity immediately visible when scrolling through large risksheets. The consistency is intentional: a reviewer moving from FHA to PSSA to SSA should see the same color for the same failure condition at every stage.
ARP 4754A requires that Safety-Critical (SC) and Design-Critical (CC) classifications flow consistently from failure conditions through to design characteristics. The Classification Consistency Report enforces this — a failure condition classified as Catastrophic implies DAL A requirements, which must propagate through all characteristics that affect the functions involved in that failure condition. Inconsistencies are a certification finding.

​
The FHA → PSSA → SSA Progression

The three safety assessment documents represent different stages of evidence maturity, not different analyses:
  • FHA — Identifies and classifies failure conditions at the system function level. DAL allocations are established here.
  • PSSA — Allocates safety requirements to subsystems. The allocatesTo link role connects failure conditions to safetyRequirement work items. Contributing failure modes are made visible.
  • SSA — Provides final verification. Evidence records (using the riskControl task type) and compliance status confirm that each failure condition has been adequately addressed.
The same FailureCondition work item appears in all three risksheets. The FHA creates it; PSSA and SSA read and extend it with additional traceability.

​
Fault Tree Analysis as a Parallel View

The FTA risksheet reuses the FailureCondition work item type but applies the gateType field to model fault tree logic. Gate types carry their own color coding: AND gates (blue), OR gates (red), Inhibit gates (orange), K-of-N gates (purple). This means a single work item can appear both in the qualitative FHA analysis and in the quantitative fault tree, maintaining a single source of truth for the failure condition properties while supporting both analysis methods.
The exact column layout, view switching behavior, and formula configurations in the FHA, PSSA, SSA, and FTA risksheets should be verified in the Aerospace Safety Solution project UI. The field definitions above reflect the data model configuration; presentation details may vary by risksheet version.

​
Common Misconceptions

“Failure modes and failure conditions are the same thing at different names.” They are fundamentally different work item types with different fields, different link roles, and different analysis purposes. A failure mode is analyzed for RPN; a failure condition is analyzed for DAL. They connect through causeOf, but they are not interchangeable. “The FHA is filled in manually from the PSSA.” The causal direction is reversed: FHA is created first, PSSA reads back from it. Classification in PSSA is populated automatically from the FHA failure condition, not entered by the safety engineer. “Characteristics are only for DFMEA.” Characteristics are the bridge between requirements and DFMEA — they carry SC/CC classification that must remain consistent with the failure condition classification at the top of the hierarchy. For practical guidance on building the hierarchy in the Aerospace Safety Solution, see the concept pages on System Element Hierarchy and V-Model Traceability Chain.
Code: .polarion/nextedy/sheet-configurations/DO-160G Environmental Qualification.yaml, Component RTM.yaml, Configuration Index.yaml, Design Verification Sheet.yaml, Interface Control Matrix.yaml, Problem Report Tracker.yaml, Process Steps.yaml, Review Action Item Tracker.yaml, SOI Stage Gate Dashboard.yaml, Use Steps Specification.yaml, User Need Validation Sheet.yaml, characteristics.yaml, component-characteristics.yaml, customer-requirements.yaml, design-requirements.yaml, subsystem-functions.yaml, subsystem-verification.yaml, system-elements.yaml, test-verification.yaml (0.63) · .polarion/nextedy/models/rtm.yaml (0.60) · modules/RiskTemplates/System-FMEATemplate/attachments/risksheet.json (0.54) · .polarion/tracker/fields/failureCondition-custom-fields.xml (0.53) · modules/RiskTemplates/FTATemplate/attachments/risksheet.json (0.53) · modules/RiskTemplates/SSATemplate/attachments/risksheet.json (0.53) · modules/RiskTemplates/PSSATemplate/attachments/risksheet.json (0.52) · modules/RiskTemplates/SubSystem-FMEATemplate/attachments/risksheet.json (0.52) · .polarion/tracker/fields/hazard-hazardCategory-enum.xml, hazard-operationalPhase-enum.xml, hazard-acceptanceAuthority-enum.xml (0.52) · modules/RiskTemplates/FHATemplate/attachments/risksheet.json (0.52)