RAMS Core

PublishedSAE ARP4761 · ARP4754A · AC 25.1309-1B

Functional Hazard Analysis

Functions, the ways they fail, what that does to the aircraft, and the classification that sets every safety objective downstream.

Every other analysis in this knowledgebase needs a design to work on. A prediction needs a parts list, an FMECA needs items to fail, an RBD needs an architecture to arrange. The functional hazard assessment needs none of them. It takes the functions the product is supposed to perform, asks what happens when each one is lost, degraded or performed wrongly, and classifies the answer by how bad it is for the people on board.

The activity has two names in common use. ARP4761 calls it a functional hazard assessment; the platform, and much of the industry, calls it functional hazard analysis. They denote the same thing, and this module uses them interchangeably.

That is why it comes first, and why it is the most consequential document a safety programme writes. Every probability objective, every development assurance level, every no-single-failure rule and every fault tree top event in the rest of the programme descends from a classification decided here, usually before a single item has been chosen.

Where it sits

The chain from functions to evidence. The aircraft FHA runs on aircraft functions, the system FHA on the functions allocated to each system, the PSSA asks whether the proposed architecture can meet the objectives, and the SSA shows that the built one does. Common cause analysis runs alongside all of it.
The chain from functions to evidence. The aircraft FHA runs on aircraft functions, the system FHA on the functions allocated to each system, the PSSA asks whether the proposed architecture can meet the objectives, and the SSA shows that the built one does. Common cause analysis runs alongside all of it.

In the ARP4761 process the assessment happens twice, and the second time is not a repeat:

LevelRuns onProduces
Aircraft FHAFunctions of the whole aircraft, before functions are allocated to systemsFailure conditions, classifications, and the aircraft-level safety objectives
System FHAThe functions allocated to a system, including combinations the allocation createdThe same for the system, plus requirements traceable up to the aircraft level

Between them and the evidence sit two more assessments. The PSSA works downward: it takes each objective and asks whether the proposed architecture can meet it, deriving item budgets and assurance levels along the way. The SSA works upward: it collects what was built and shows that it does. Both are usually carried by a fault tree, and ARP4761 is explicit that a dependence diagram or a Markov analysis may be used instead wherever a fault tree is called for.

What comes out of it

Six consumers, each taking a different column of the same worksheet, and all six taking delivery before the architecture is fixed. That timing is the whole argument for doing the assessment first.
Six consumers, each taking a different column of the same worksheet, and all six taking delivery before the architecture is fixed. That timing is the whole argument for doing the assessment first.
OutputConsumer
The list of failure conditions, with phases and annunciation statesEverything downstream; this list is the safety scope of the programme
A classification per conditionThe probability objective, and the assurance level
A quantitative objective per conditionThe fault tree top event it will be compared against
Qualitative requirements, above all the no-single-failure ruleThe architecture, before it is fixed
A verification plan per conditionThe certification plan: which analysis or test will show compliance

Where the discipline comes from

SAE ARP4761 (1996) is the document that turned this into a defined method with a worksheet, a process around it and a worked example running from aircraft function to item requirement; ARP4761A and ARP4754B were issued in December 2023 and restructured that material, so an assessment written today should say which edition it follows. ARP4754A supplies the development assurance side: the levels, and the rules that connect them to the classification.

On the regulatory side the anchor is 14 CFR 25.1309 with its advisory circular, and CS-25 with AMC 25.1309 in Europe. That anchor moved recently and it is worth knowing why: in August 2024 the FAA amended 25.1309 to add the Hazardous classification, and issued AC 25.1309-1B, which cancelled AC 25.1309-1A of 1988 after thirty-six years. The 1988 circular defined three severity classes and three probability terms; the five-class ladder that every engineer draws from memory was European practice, carried into the ARP documents, and only became the FAA's published position in 2024. Material written before that date describes a different American baseline, and material citing "AC 25.1309-1B" before 2024 is citing a draft that was never issued.

Outside aviation the same analysis appears under other names, with the same shape and different vocabulary: the preliminary hazard analysis of MIL-STD-882, the hazard analysis and risk assessment of ISO 26262, the hazard identification of the EN 50126 railway lifecycle. The safety concept pages map those onto each other; this module is about how the aviation form is actually performed.


Want to see this on a live system model? Request a walkthrough.