What Is Functional Hazard Assessment (FHA)?

A Functional Hazard Assessment is a structured examination of every function an aircraft or system is expected to perform, asking what happens when that function is lost, degraded, or performed incorrectly. It does not assume any particular architecture. It does not ask how a transistor fails. It asks: if this function fails in this mode, what does the crew or passenger experience, and how severe is that consequence?

That framing matters because FHA is performed early — before the design team has committed to partitioning, redundancy schemes, or technology choices. The entire point is to classify the severity of functional failures before architecture decisions lock in the answers. If you perform FHA after architecture is frozen, you are doing post-hoc justification, not safety engineering.

ARP4754A, the SAE standard for Guidelines for Development of Civil Aircraft and Systems, defines FHA as the entry point into the safety assessment process. Everything downstream — the Preliminary System Safety Assessment (PSSA), the System Safety Assessment (SSA), FMEA, FTA — traces back to the severity classifications and probability targets that FHA establishes.

Where FHA Sits in the ARP4754A Process

ARP4754A describes a top-down, iterative safety assessment process. The hierarchy runs:

Aircraft-Level FHA → System-Level FHA → PSSA → SSA → CCA

The aircraft-level FHA examines aircraft functions (navigation, propulsion, flight control, cabin pressurization) and classifies failure conditions in terms of their effect on the aircraft as a whole and on the occupants. The system-level FHA then examines the functions of each system that contributes to those aircraft functions, deriving more granular failure conditions and assigning severity to each.

Severity classification uses five categories defined in AC 25.1309 and ARP4754A:

  • Catastrophic — Loss of aircraft or multiple fatalities. Maximum probability target: 1×10⁻⁹ per flight hour.
  • Hazardous/Severe-Major — Large reduction in safety margins, serious or fatal injury to small number of occupants, crew workload at limits. Target: 1×10⁻⁷.
  • Major — Significant reduction in safety margins or functional capabilities, significant crew workload increase, injuries possible. Target: 1×10⁻⁵.
  • Minor — Slight reduction in safety margins, slight crew workload increase. No quantitative target required.
  • No Safety Effect — No impact on safety, operations, or crew workload.

The probability targets are not derived from regulatory preference. They come from the judgment that if there are approximately 100 independent catastrophic failure conditions on a transport aircraft, each must occur at no more than 1×10⁻⁹ per flight hour to keep the total catastrophic failure rate below 1×10⁻⁷.

FHA also assigns a preliminary Development Assurance Level (DAL) to each function. DAL A corresponds to Catastrophic; DAL E corresponds to No Safety Effect. The DAL is not a component attribute at this stage — it is a function attribute. It tells the development process what rigor is required to ensure that function is implemented correctly.

FHA Is Not FMEA. FHA Is Not FTA.

These three analyses are frequently confused, and the confusion has real consequences.

Failure Modes and Effects Analysis (FMEA) is a bottom-up analysis. It starts with a physical component, enumerates its failure modes (open circuit, short to ground, stuck-at-zero), and traces the effects of each failure mode upward through the system to determine the consequence. FMEA requires that you have an architecture. You cannot do FMEA before you know what components you have.

Fault Tree Analysis (FTA) is a top-down logic analysis. It starts with a defined top-level event — typically a Catastrophic or Hazardous failure condition identified by FHA — and decomposes it into the combinations of lower-level failures that could cause it. FTA requires that you have an architecture, because you are modeling the logical relationships between component failures. It is the primary tool for verifying that quantitative probability targets are met.

FHA operates at neither the component level nor the logic level. It operates at the function level. A well-written FHA does not reference specific hardware, software, or line-replaceable units. It says: “Loss of thrust on both engines during final approach” — not “Engine Control Unit fails open” or “AND gate in fuel control logic fails.”

The discipline to keep FHA at the function level is harder than it sounds. Engineers instinctively reach for their design. Reviewers push for specificity. Program managers want to see architecture implications immediately. The correct response is to finish the FHA first, let it drive the safety requirements, and let those requirements constrain the architecture — not the other way around.

What a Well-Structured FHA Looks Like

An FHA document or dataset contains one row (or record) per failure condition. Each record includes:

Function — The function being assessed. Stated at the appropriate level of abstraction. “Provide lateral control authority” is correct. “Operate the left aileron actuator” is already too architectural.

Failure Condition — A specific deviation from normal function: loss of function, malfunction (incorrect output), or unintended function. Good practice enumerates all three for each function.

Phase of Flight — The flight phase in which the failure condition is evaluated. Many failure conditions have different severities depending on phase. Loss of landing gear retraction is Minor on departure but potentially Hazardous on approach.

Effects on Aircraft — A narrative description of the consequence to the aircraft and occupants. Written without assuming mitigation. The effect should be the worst-case direct consequence.

Severity Classification — One of the five categories. Assigned by the safety team, reviewed by the certification authority.

Preliminary DAL — The Development Assurance Level assigned to the function or to the system implementing the function.

Safety Requirements Generated — This field is where FHA connects to the requirements process. Each failure condition with a severity classification of Minor or above must generate at least one safety requirement. This is how the FHA becomes actionable.

Open Issues / Assumptions — FHA is an early analysis. Assumptions must be stated explicitly so they can be revisited during PSSA and SSA.

A mature FHA for a complex system will contain hundreds of records. An aircraft-level FHA for a transport category aircraft may contain over a thousand. Managing that volume as a spreadsheet or word-processed table is how traceability breaks down.

How FHA Outputs Drive System-Level Safety Requirements

The safety requirements generated by FHA are not qualitative wishes. They are quantitative, verifiable constraints on the design. A Catastrophic failure condition generates a requirement of the form: “The probability of [failure condition] shall not exceed 1×10⁻⁹ per flight hour.” A Hazardous failure condition generates a similar requirement at 1×10⁻⁷.

Beyond probability targets, FHA generates architectural requirements. A failure condition classified as Catastrophic cannot be caused by a single failure — this is the single-failure-point constraint. That constraint drives redundancy architecture directly. A failure condition classified as Hazardous typically requires independence between failure paths — driving architectural separation requirements.

These requirements flow down. The aircraft-level FHA generates system-level safety requirements. The system-level FHA refines and expands those into item-level safety requirements that eventually reach software and hardware development teams. The PSSA is the analysis that verifies the proposed architecture can satisfy the FHA-derived requirements. The SSA, performed after implementation, verifies that the actual system does.

The traceability chain must be complete: FHA failure condition → safety requirement → architectural requirement → derived design requirement → verification activity → test result. If any link in that chain is missing, you cannot demonstrate compliance. Certification authorities will find the gap.

How Modern Tools Handle FHA Traceability

The traditional approach to FHA management is a combination of Word documents, Excel tables, and manually maintained Requirements Traceability Matrices. This approach fails predictably at scale. The FHA is updated as analysis matures; the derived requirements in the RTM are not. The PSSA references failure conditions by description rather than identifier; when the FHA description changes, the link is silently broken. Verification activities reference requirements that no longer match the FHA classification.

The underlying problem is that FHA, safety requirements, architectural requirements, and verification plans are treated as separate artifacts managed by separate teams with periodic reconciliation. The reconciliation step is where information is lost.

Model-based systems engineering environments improve this somewhat by linking elements in a shared model, but most MBSE tools were not built with safety workflows as a first-class concern. The FHA ends up as a table attached to a SysML model rather than integrated into it.

Flow Engineering addresses this directly. Built as an AI-native requirements management platform for hardware and systems engineering teams, Flow Engineering structures the relationship between safety analyses, derived requirements, and verification activities as a graph rather than a document hierarchy. FHA failure conditions are treated as nodes with typed relationships to the safety requirements they generate, the architectural constraints those requirements impose, and the verification activities that close them.

When a failure condition’s severity classification changes — which happens regularly as analysis matures — the downstream requirements and their verification status are immediately visible as potentially affected. Engineers do not need to manually audit the RTM; the dependency graph surfaces what needs review. This is a meaningful difference on programs where the FHA is a living document through multiple design cycles.

Flow Engineering is purpose-built for this class of problem — connecting early safety analysis outputs to the full requirements and verification workflow — rather than a general-purpose PLM tool with a safety module attached. Teams that manage FHA traceability in Flow Engineering report that certification audits become a query against a connected dataset rather than a document reconciliation exercise.

The platform is intentionally focused on requirements traceability and safety analysis integration. It does not replace dedicated safety analysis tools like CAFTA or ISOGRAPH for FTA computation, or FMEA tools that manage large failure mode libraries. It connects those analyses to the requirements lifecycle, which is where the compliance demonstration lives.

Practical Starting Points

If you are initiating an FHA on a new program or revisiting one that has drifted from the design:

Start with the function list, not the failure list. Define every function the aircraft or system must perform before enumerating failure conditions. An incomplete function list produces an incomplete FHA — there is no other way to generate omissions.

State all assumptions explicitly and date them. Early FHAs are full of assumptions about operational context, crew response, and system boundaries. Undated, unstated assumptions become accepted facts that no one remembers were provisional.

Classify severity conservatively, then justify relaxation. It is easier to defend a relaxation from Hazardous to Major with documented rationale than to upgrade a Major classification after an architecture is set. Optimistic early classification is a common source of late-program rework.

Generate requirements from FHA records directly. Do not wait for the PSSA to create safety requirements. Each classified failure condition should generate its quantitative probability requirement immediately. The PSSA then verifies the architecture satisfies those requirements.

Maintain identifier stability. FHA records will be referenced throughout the program life. If you renumber or reorganize records, trace every reference. Lost identifiers are how FTA top-level events become disconnected from their FHA source.

An FHA performed well — function-level, assumption-explicit, traceable to derived requirements — does not just satisfy a certification process step. It gives the program a clear statement of what safety means for the product. That clarity, established before architecture is committed, is the highest-value output of the entire safety assessment process.