How to Do a Functional Hazard Assessment (FHA) and a Fault Tree Analysis (FTA)

chatgpt image apr 27, 2026, 12 10 00 am

Where FHA and FTA sit in safety engineering

Functional Hazard Assessment (FHA) and Fault Tree Analysis (FTA) are two of the main tools used in aviation safety engineering.

But they’re not standalone tasks—you don’t just “do an FHA” or “do an FTA” in isolation. They’re part of a bigger process that helps you understand how safe a system really is.

A simple way to think about it:

FHA happens early, when you’re still figuring out what the system is supposed to do

FTA happens later, when you’re digging into how things could actually fail

Another way to look at it:

FHA is top-down (starting from functions)

FTA is bottom-up (starting from failures)

Or even simpler:

FHA asks: “If this goes wrong, what happens?”

FTA asks: “How could it go wrong in the first place?”


 

What FHA actually does

FHA is about functions—not parts, not components, not hardware.

You’re not looking at what breaks. You’re looking at what the system is supposed to do, and what happens if it doesn’t do that properly.

Think of it like this: before worrying about wires, sensors, or computers, you ask:

“What is this system meant to achieve?”

Some simple examples of functions:

Maintain aircraft altitude

Provide airspeed information

Control pitch

Detect terrain proximity

Once you’ve got those, the question becomes:

“What if this function is wrong?”


 

Step-by-step: Functional Hazard Assessment (FHA)

Step 1: Define system functions

Start with what the system does.

Not the hardware—just the purpose.

For example:

Instead of saying “pitot system,”

you’d say:

“Provide accurate airspeed information to pilots and flight systems”

That shift is really important. You’re focusing on the outcome, not the equipment.

Step 2: Define failure conditions

Now take that function and imagine how it could go wrong.

Not just completely fail—there are different ways things can break:

complete loss

partial degradation

wrong output

intermittent behaviour

Using the airspeed example, that might look like:

no airspeed displayed

airspeed too high

airspeed too low

jumping or unstable readings

Each of these is a different failure condition, even though they come from the same function.

Step 3: Determine operational effects

Now ask the most important question:

“What does this actually do to the aircraft?”

This is where you step out of theory and think about real operation.

Consider things like:

pilot workload

how the autopilot reacts

how the aircraft behaves

what other systems might do in response

For example:

If the aircraft thinks it’s going faster than it actually is, the pilot or automation might reduce power or pitch down unnecessarily—which can push the aircraft into an unsafe situation.

Step 4: Assign severity classification

Now you classify how serious each failure is.

Typical levels are:

Catastrophic

Hazardous / Severe Major

Major

Minor

No safety effect

This part matters a lot, because it drives design decisions like:

how much redundancy you need

how the system is built

what regulators will require


 

Key idea in FHA

FHA is not about components failing.

It’s about:

what happens to the aircraft when a function is wrong


 

What FTA actually does

FTA works in the opposite direction.

Instead of starting with a function, you start with a bad outcome—and work backwards.

For example:

“Loss of control”

Then you ask:

“How could we end up here?”


 

Step-by-step: Fault Tree Analysis (FTA)

Step 1: Define top event

Start with a clear failure event.

Examples:

loss of pitch control

uncommanded descent

stall not recovered

loss of navigation capability

Be very specific—this is the thing you’re trying to explain.

Step 2: Identify immediate causes

Now break that failure into the most direct reasons it could happen.

For example:

Loss of control could come from:

bad attitude information

pilot input error

flight control system issues

extreme weather

At this stage, you’re just mapping out the main branches.

Step 3: Continue decomposition

Now you keep going deeper.

Take each cause and ask:

“Why would that happen?”

For example:

Bad attitude information might come from:

sensor failure

disagreement between sensors

data processing issues

power problems

You keep breaking it down until you reach basic things like:

hardware failures

software issues

human actions

environmental conditions

Step 4: Apply logic gates

This is where FTA becomes powerful.

You define relationships between causes:

OR = any one of these can cause the failure

AND = multiple things must happen together

For example:

Loss of control might happen if:

OR: flight control system fails

OR: structure fails

But in another case:

AND: sensor failure + pilot misinterpretation

This lets you model not just single failures, but combinations—which is where most real problems come from.


 

Key idea in FTA

FTA isn’t asking:

“What failed?”

It’s asking:

“What combination of things would need to happen for this to fail?”


 

How FHA and FTA work together

These two aren’t separate—they feed into each other.

Simple way to connect them:

FHA tells you what failures matter and how serious they are

FTA tells you how those failures could actually occur

For example:

FHA says: “Losing airspeed information is dangerous”

FTA says: “Here are all the ways you could lose airspeed information”


 

Common mistakes junior engineers make

Mistake 1: Treating FHA like a checklist

It’s easy to turn FHA into a spreadsheet exercise.

But that misses the point.

You’re supposed to be thinking about how the aircraft behaves—not just filling boxes.


Mistake 2: Jumping into FTA too early

If you skip proper FHA:

you focus on components instead of functions

you miss system-level effects

you oversimplify how failures actually happen


Mistake 3: Ignoring the human

In aviation, the pilot is part of the system.

If you ignore how humans interpret information:

your analysis will be incomplete


 

Simple mental model

If you remember nothing else, remember this:

FHA = what happens if a function is wrong

FTA = how that function becomes wrong

That’s the relationship.


 

Closing Thought

Safety analysis isn’t just paperwork—it’s about understanding how systems behave.

In real aircraft, failures rarely come from one thing breaking.

They come from multiple things interacting in ways that weren’t fully expected.

FHA and FTA help you see that from two directions:

one from the top (what goes wrong),

and one from the bottom (how it happens).

Related Posts