Functional hazard assessment, from aircraft function to DAL

The functional hazard assessment is where an aircraft safety program starts and where most of its later trouble is decided. Every failure condition you classify here becomes a top event with a probability target, a set of development assurance levels for the systems that implement the function, and a stack of safety requirements that has to be verified before certification. Classify one condition a band too mild and the error is invisible until a fault tree closes against the wrong target.

Safety Lab Aero treats the FHA (ARP4761A, SAE ARP 4761A) as the spine of the program, not a spreadsheet at the front of it. Rows carry their basis, their traces and their sign-off, and everything downstream reads from them.

AFHA and SFHA in one connected workbook

• Aircraft-level functions and failure conditions (loss, malfunction, inadvertent operation) in the AFHA; system-level conditions in the SFHA, each traced to the aircraft-level condition it supports.
• Effects on the aircraft, the crew and the occupants captured per flight phase, following the ARP 4761A Table A5 matrix, with one governing severity per row.
• An advisory invariant that flags any governing severity milder than the worst of its own phases: an understatement wearing a reviewed look.
• Detection, crew action, exposure and classification rationale on the row, so the reasoning travels with the classification.

Severity that carries its own numbers

The project declares its certification basis once: AC 25.1309 for transport category, AC 23.1309 by aircraft class, or SC-VTOL for eVTOL. Every FHA row then carries the probability target and the development assurance level that its basis assigns to its severity. When a failure condition becomes the top event of a fault tree, the tree inherits the target; when DAL is allocated under ARP 4754B, the allocation starts from the FHA classification. Nothing is retyped between the three.

Classification by rule where a rule exists

Two safety engineers given the same function will not always agree on a severity, and the same engineer on two programs will not either. Safety Lab Aero derives the two axes that can be derived. The aircraft axis is graded from the minimum acceptable configuration for the function: a partial loss that leaves the rule held is slight, significant or large depending on how much redundancy remains. The crew axis is read from the crew task analysis: the tasks the condition demands, against the time the phase allows, expressed as workload. Where no rule exists the engineer's judgment stands, and it lands in the assumptions register as an assumption to be validated, not as a fact.

Import that refuses to guess

Existing FHAs import from spreadsheets and from requirements tools over ReqIF (Jama Connect, Polarion, IBM DOORS), with identifiers, attributes, hierarchy and trace links intact. Severity wording that maps unambiguously to the five classes is classified; anything else arrives unclassified with a warning. Rows deleted at the source are flagged for disposition, never silently removed while a fault tree still references them.

What the FHA connects to

• Fault trees: each failure condition is a top event with an inherited target.
• DAL allocation: severity seeds the top-down allocation, including the ARP 4754B AND-gate options.
• Safety requirements: derived from the classification and traced back to it, so a change in severity flags every requirement it touches.
• Human factors: severity is reconciled against crew workload, and a Minor classification sitting under a task the model says drives excessive workload is called out on the row.
• Dispatch: the MEL cross-check flags any credited protection the MMEL allows to be dispatched inoperative, because the dispatched aircraft is not the aircraft that was classified.

Frequently asked questions

What is a functional hazard assessment?

A functional hazard assessment (FHA) is the first step of the ARP 4761A safety process. For each aircraft or system function, it identifies the ways the function can fail (loss, malfunction, inadvertent operation), describes the effect of each failure condition on the aircraft, the crew and the occupants in each phase of flight, and classifies its severity: Catastrophic, Hazardous, Major, Minor or No Safety Effect. The severity sets the probability the design must meet and the development assurance level the implementing systems must achieve.

What is the difference between an AFHA and an SFHA?

The aircraft functional hazard assessment (AFHA) works at the aircraft level: functions such as controlling pitch or providing cabin pressure, and their failure conditions across the whole aircraft. The system functional hazard assessment (SFHA) repeats the exercise for each system that implements those functions, after the architecture has allocated them. In Safety Lab Aero the SFHA rows trace up to the AFHA failure conditions they support, so a system-level classification that is milder than the aircraft-level one it inherits is flagged.

How is severity mapped to a probability target and a DAL?

By the certification basis the project declares. Under AC 25.1309 a Catastrophic failure condition must be extremely improbable (on the order of 1e-9 per flight hour) and is assigned DAL A; Hazardous is extremely remote (1e-7) at DAL B; Major is remote (1e-5) at DAL C; Minor is probable at DAL D. AC 23.1309 scales the targets by aircraft class, and SC-VTOL uses its own table for eVTOL. Safety Lab Aero carries the project's basis and applies the matching targets to every FHA row, so the target on a fault tree is never typed in by hand.

Can severity differ by phase of flight?

Yes, and ARP 4761A's own worked example depends on it: loss of high-lift is Catastrophic on takeoff and approach and has no effect at the gate. Safety Lab Aero captures effects and severity per flight phase on the FHA row (the Table A5 matrix) while keeping one governing severity for the row, and checks that the governing severity is never milder than the worst phase.

Can I import an existing FHA?

Yes. Failure conditions import from spreadsheets and from requirements tools over ReqIF (Jama Connect, Polarion, IBM DOORS) with their identifiers, attributes and trace links. The importer maps severity wording to the five classes only when the mapping is unambiguous; anything it cannot map with certainty arrives unclassified with a warning rather than guessed, because a misread classification is worse than a blank one.