InsightFab
Knowledge Base/Fault Tree Analysis (FTA): Logical Modeling for System Reliability
Reliability6 min read

Fault Tree Analysis (FTA): Logical Modeling for System Reliability

This article provides a highly practical approach to tackle production line issues and plummeting yield rates. It introduces Fault Tree Analysis (FTA) as a powerful tool for systematically backtracking and identifying the root causes of complex problems, enabling a logical and efficient resolution instead of trial-and-error.

That day, the machine broke down again, and the yield rate plummeted to an alarming level

I remember one time, a critical piece of equipment on the production line inexplicably broke down again, and this time the impact was enormous. We were rushing an urgent order, and when the machine stopped, a whole series of subsequent processes got stuck. The yield report came out, showing a drop from the usual 99% to below 95%, and the Cpk also fell from 1.3 to 1.08. The atmosphere instantly froze. The boss, with an ashen face, asked, "What exactly happened? Which part went wrong?" What do you do in such a situation? Are we supposed to tell everyone to use trial-and-error, disassemble parts one by one, and adjust parameters one by one? Of course not. This is when us seasoned engineers bring out Fault Tree Analysis (FTA).

What went wrong, in essence, is "reverse thinking"

Honestly, Fault Tree Analysis sounds very academic, but in fact, it's a logical tool based on "reverse thinking." When a "negative event" occurs (e.g., machine crash, yield rate plummeting), what we need to do is to backtrack step by step, like a detective, to identify all possible causes that could lead to this event. It connects these causes using Boolean logic (AND, OR gates) and draws them into a tree diagram.

In other words, you're not thinking "what will I do to succeed," but rather "what bad things happened that led to this failure." It breaks down complex problems into independent and analyzable components, allowing you to clearly see the "vulnerability points" of the entire system at a glance.

How is it actually done? Unfold the problem with logic gates

We typically draw a fault tree as follows:

  1. Define the Top Event: This is the undesirable outcome you least want to see. For example: "Machine A unexpected shutdown."
  2. Identify Direct Causes: What events, when they occur, will "directly" lead to the Top Event? Assuming Machine A stops, it could be "power supply failure" OR "main control board crash" OR "software program crash." Here, an OR gate is used for connection.
  3. Continue Decomposition: For each direct cause, ask "What caused this cause to happen?"

* If "power supply failure," it could be "fuse blown" AND "voltage instability" occurring simultaneously (both conditions need to be met for it to fail). This is an AND gate.

* If "main control board crash," it could be "chip overheating" OR "firmware defect."

  1. Continue Decomposition until Basic Events: Keep breaking down until you find "Basic Events" that cannot be further subdivided and can be directly measured or replaced. For example, "blown fuse" is a Basic Event itself.

We once used FTA to analyze a process defect with a DPMO as high as 6210 and found that it ultimately traced back to three Basic Events: unstable purity of a certain batch of raw materials provided by the supplier, insufficient machine cleaning frequency, and operators not strictly following SOPs. When you list these root causes and estimate the probability of each occurring, you can calculate the probability of the Top Event occurring and know which link needs to be prioritized.

The most common pitfalls: thinking too much and thinking too little

During my experience with FTA, I've seen many people fall into common pitfalls.

  • Pitfall 1: Insufficient thinking, incomplete decomposition. Sometimes people only decompose to the second level and stop, thinking, "Oh, it's a software problem." But there are many possibilities under a software problem: is it memory overflow? Or a logic error? If you don't dig down to the lowest level Basic Event, you cannot truly solve the problem; you're just treating the symptoms, not the root cause. Last time, a newcomer analyzed a machine failure and only wrote "sensor anomaly," but didn't investigate whether the sensor itself was broken, the wiring was loose, or the parameters were set incorrectly, resulting in a day of wasted effort.
  • Pitfall 2: Overthinking, drawing in all possibilities. Sometimes, in pursuit of completeness, people include events with extremely low probability, almost impossible to occur, causing the fault tree to become incredibly huge and difficult to read, thereby losing analysis efficiency. Frankly speaking, time is money, and identifying high-probability critical points is key.

So, the key is to strike a good balance, decomposing to a level sufficient for you to take practical action.

One thing you can do today

Choose a problem you've recently encountered and try to use the FTA mindset to draw a preliminary fault tree for it.

Want to try it yourself?

Every tool mentioned in this article is available on InsightFab — just upload a CSV to analyze.

Go to Tools

More in this category

Reliability Fundamentals: The Relationship Between Failure Rate, MTBF, and Reliability Function

This article offers practical insights, starting with the author's experience of realizing reliability extends beyond just yield, focusing instead on a product's lifespan in customer hands. It uses relatable examples to clarify key reliability terms like failure rate, MTBF, and reliability function, helping engineers understand what truly matters to customers: stable, long-lasting product operation.

Weibull Analysis: Predicting Equipment Life from Failure Data

The Weibull distribution is the most commonly used life analysis tool in reliability engineering. Through the shape parameter β, it can be determined whether failures are early failures (infant mortality), random failures, or wear-out failures, thereby determining the correct maintenance strategy.

Reliability Prediction: Beyond MIL-HDBK-217, Reliability Estimation Engineers Can Do

Reliability prediction is not limited to consulting the MIL-HDBK-217 manual. This article explains reliability calculations for series and parallel systems, the benefits of derating design, the application of HALT testing, and how to avoid treating predicted values as guarantees.