The Analysis That Defines the Safety Floor
Every avionics program eventually faces the same question from a certification authority: how do you know your system is safe enough? The answer begins with a Functional Hazard Assessment.
An FHA is a structured, systematic examination of aircraft or system functions that asks: what happens if each function fails, partially fails, or operates when it shouldn’t? For each identified failure condition, the FHA assigns a severity classification — from No Safety Effect through Minor, Major, Hazardous, to Catastrophic. Those classifications then generate quantitative probability targets and Development Assurance Level (DAL) assignments that propagate down through every subsequent design and verification activity.
That sequence matters. The FHA does not describe hardware. It does not analyze specific components or failure modes. It operates at the functional level — the level of what the aircraft or system is supposed to do — and it establishes the safety objectives that every lower-level analysis must eventually demonstrate have been met. Get the FHA wrong, and the entire safety argument is built on a flawed foundation.
Where FHA Sits in ARP4754A and ARP4761
Two SAE standards define the aerospace systems safety process. Understanding how they divide the work clarifies why FHA is where it is.
ARP4754A — Guidelines for Development of Civil Aircraft and Systems — governs the aircraft and system development process. It defines how safety requirements are established, allocated, verified, and traced. It is the process standard.
ARP4761 — Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment — provides the analytical methods: FHA, Preliminary System Safety Assessment (PSSA), System Safety Assessment (SSA), Fault Tree Analysis (FTA), Failure Modes and Effects Analysis (FMEA), Common Cause Analysis (CCA), and others. It is the methods standard.
The FHA appears at the beginning of both the aircraft-level and system-level safety assessment processes. ARP4754A describes it as the starting point for establishing safety requirements; ARP4761 defines how to conduct it. Together they place FHA in the position of top-level gatekeeper: no safety objective is valid unless it derives from an FHA.
Aircraft-Level vs. System-Level FHA
ARP4761 distinguishes between two tiers:
Aircraft-Level FHA (A-FHA): Conducted by the aircraft manufacturer (or a prime integrator), this analysis examines functions the aircraft must perform — maintain controlled flight, provide crew alerting, sustain structural integrity under normal loads — and identifies what failure conditions at the aircraft level are hazardous. The A-FHA produces top-level safety objectives expressed as maximum allowable probability of failure conditions.
System-Level FHA (S-FHA): Conducted at the system level (avionics suite, flight control system, hydraulic system, etc.), this analysis refines and allocates the aircraft-level objectives into system-specific terms. An S-FHA takes the aircraft-level objective — for example, “loss of all flight control surface authority shall be Catastrophic, probability < 1×10⁻⁹ per flight hour” — and translates it into specific failure conditions and safety requirements for that system’s functions.
Both tiers follow the same analytical structure. The output is always the same type of artifact: a list of failure conditions, their severity classifications, their probability targets, and the preliminary DAL assignments for software and hardware that must implement the mitigating functions.
Severity Classification and What It Drives
The five-level severity scale in ARP4761 is not arbitrary. Each classification carries specific consequences for probability requirements and development assurance.
| Classification | Effect on Aircraft/Crew/Passengers | Probability Target | Typical DAL |
|---|---|---|---|
| Catastrophic | Loss of aircraft or multiple fatalities | < 1×10⁻⁹ /FH | DAL A |
| Hazardous | Large reduction in safety margins, serious crew injury, fatal injuries to a small number of occupants | < 1×10⁻⁷ /FH | DAL B |
| Major | Significant reduction in safety margins, physical distress to occupants | < 1×10⁻⁵ /FH | DAL C |
| Minor | Slight reduction in safety margins, some inconvenience | < 1×10⁻³ /FH | DAL D |
| No Safety Effect | No effect on safety | No target | DAL E |
These probability targets are per-flight-hour figures for the failure condition — not for individual components. That distinction drives the entire architecture of redundancy, independence, and dissimilarity that characterizes certified avionics. When an FHA classifies a failure condition as Catastrophic, the design team must demonstrate that the probability of that condition occurring, considering all possible contributory failure paths, is below 1×10⁻⁹ per flight hour. The FTA, FMEA, and ultimately the SSA exist to provide that demonstration.
DAL, derived from severity, then feeds directly into DO-178C (software) and DO-254 (hardware) requirements. A DAL A software component requires the full suite of requirements-based testing, structural coverage analysis to MC/DC, and independence in verification activities. A DAL D component requires substantially less. The FHA classification is therefore not just a safety analysis artifact — it is an economic and schedule driver for the entire development program.
FHA Outputs as Requirements Sources
This is where many programs make a consequential error. FHA outputs are often treated as analysis documentation rather than requirements sources. The distinction has certification implications.
An FHA conclusion such as “Loss of [Function X] is classified as Hazardous; probability of loss shall not exceed 1×10⁻⁷ per flight hour” is a safety objective. When that objective is allocated into a system specification — expressed as a verifiable requirement on the system’s architecture, redundancy, or monitoring capability — it becomes a safety requirement. The traceability chain connecting FHA objective to system requirement to subsystem requirement to verification activity is what certification authorities examine.
ARP4754A Section 5 describes this flow explicitly. Safety requirements derived from the FHA (and subsequently from the PSSA) must be identified as such, allocated to items within the system architecture, and verified during the SSA. The SSA closes the loop: it demonstrates, using completed FTAs, FMEAs, and other analyses, that the implemented design actually achieves the safety objectives the FHA established.
If the FHA conclusion exists only in a standalone safety analysis document with no traced connection to the system specification, the certification team cannot demonstrate compliance. The analysis exists, but the requirements chain does not.
The PSSA: FHA’s Immediate Downstream Consumer
The Preliminary System Safety Assessment takes the FHA’s system-level failure conditions and safety objectives and begins the work of allocating them to architecture. The PSSA asks: given this proposed architecture, can we plausibly achieve the required probability targets? It uses preliminary FTAs to explore whether the proposed redundancy strategy, failure independence assumptions, and common cause mitigations are sufficient.
The PSSA is iterative. Early architectural decisions — how many channels, where monitors are placed, what functions are implemented in hardware versus software, which items must be physically separated — are tested against the FHA’s safety objectives. When a PSSA shows that a proposed architecture cannot meet an FHA target, the architecture changes. This is the intended design loop: FHA sets the objectives, PSSA tests whether a candidate design can meet them, design evolves until PSSA confirms feasibility, then SSA verifies that the built system actually achieves them.
Every requirement generated during this loop — every allocation from aircraft level to system level to LRU to software component — must be traceable back to its originating FHA failure condition. That chain of traceability is what makes the safety argument coherent.
Why Traceability from FHA Is Not Optional
Certification under FAR Part 25 (fixed-wing transport) or Part 27/29 (rotorcraft), in combination with FAA AC 25.1309 or EASA AMC 25.1309, requires a safety assessment that demonstrates the design meets its safety objectives. The safety objectives originate in the FHA. The demonstration exists in the SSA. What connects them is a requirements traceability structure.
Without that structure, several failure modes emerge in certification programs:
Orphaned safety requirements. FHA conclusions that were never translated into verifiable system requirements. The analysis exists but the design intent was never formally specified — meaning it may or may not have been implemented, and verification against it is impossible.
Untraced DAL assignments. Software or hardware items assigned a DAL without a documented rationale linking that assignment to a specific FHA failure condition. Certification reviewers will ask for that rationale; without traceability, the answer requires manual reconstruction through multiple document layers.
Requirement drift. System requirements change during development. Without a live traceability link back to the FHA, a changed requirement may inadvertently relax a safety-driven constraint without triggering the appropriate safety review.
Incompleteness in the SSA. The SSA is supposed to verify that all FHA failure conditions have been addressed. If the traceability from FHA to design to verification is maintained in disconnected documents, completeness checks are manual, error-prone, and time-consuming.
These are not theoretical concerns. They are common findings during certification audits and a primary driver of late-program safety compliance remediation work.
How Modern Tools Handle FHA-Derived Requirements
Managing the traceability chain from FHA through system and subsystem specifications has historically meant maintaining linked requirement databases in tools like IBM DOORS or DOORS Next, with safety attributes and allocation tables maintained semi-manually. The process works but requires discipline and carries significant manual overhead. Coverage analysis — confirming that every FHA failure condition has an allocated requirement and a verification activity — typically involves custom scripts or labor-intensive spreadsheet reviews.
Platforms built for connected systems engineering have made this more tractable. Flow Engineering is a requirements management platform designed for hardware and systems engineering teams, and it handles FHA-derived safety requirements as a native use case. Safety objectives from the FHA can be instantiated as requirement nodes with explicit severity classifications and DAL attributes. System and subsystem requirements derived from those objectives are linked with bidirectional traceability, so the full chain from aircraft-level failure condition to LRU specification is navigable in a single graph model rather than across disconnected documents.
When a system requirement changes, Flow Engineering’s graph-based model surfaces the impact on linked FHA objectives and downstream verification activities immediately — addressing the requirement drift problem before it becomes a certification finding. Safety teams can run coverage queries to confirm that every FHA failure condition has been allocated and every allocation has a corresponding verification record, without manually assembling the picture from multiple document exports.
For programs operating under ARP4754A, where the requirements traceability structure is not just good practice but a compliance artifact, that kind of live, navigable traceability reduces both the risk of gaps and the labor cost of demonstrating completeness to certification authorities.
Starting Points for FHA-Grounded Certification Programs
If you are entering or restructuring a program’s safety process, a few operational principles will reduce downstream pain:
Treat FHA conclusions as requirement source nodes, not analysis conclusions. Each identified failure condition should immediately generate a tracked safety objective in your requirements toolchain, with severity, probability target, and DAL attributes recorded. Analysis that lives only in a Word document or PDF does not drive design; requirements do.
Establish the FHA-to-PSSA-to-SSA traceability chain before architecture is frozen. Retrofitting traceability to a mature design is expensive. Building it incrementally as FHA conclusions are established and PSSA allocations are made keeps the chain current and coherent.
Assign ownership of FHA failure conditions. Each identified failure condition should have a responsible safety engineer and a system owner. Unowned safety requirements tend to drift.
Plan for FHA revision. Aircraft programs change. Functions are added, removed, or reallocated between systems. The FHA is a living analysis; its conclusions need configuration control with impact propagation to downstream requirements.
Verify completeness before entering SSA. Before the SSA effort begins, confirm that every FHA failure condition has an allocated requirement somewhere in the system hierarchy and that every DAL assignment has documented rationale. Discovering gaps during SSA is common and expensive.
The Analysis That Cannot Be Skipped or Shortcut
The FHA is structurally irreplaceable in the aerospace safety process. It is the point at which aircraft-level intent — what the aircraft must do and what cannot be allowed to happen — is translated into a set of binding safety objectives. Every PSSA, every FTA, every FMEA, every DO-178C software plan, and every DO-254 hardware plan traces back to an FHA conclusion, whether that trace is explicit or not.
When it is not explicit, programs discover the gap late, during certification review, when reconstructing the argument from disconnected documents. Making the FHA the active top of a live, managed requirements hierarchy — not an archived analysis report — is the engineering discipline that separates programs that certify predictably from those that spend their final year in compliance remediation.