What the F is Going On? (F is for Failure)

My experience

When I first studied reliability engineering, one term kept popping up: “failure mode.” It was introduced in my very first class. I remember the professor explaining its definition, but honestly, I didn’t pay much attention. Back then, I was more interested in calculations such as fitting Weibull distributions, estimating acceleration factors, and crunching numbers. To me, failure mode and failure mechanism were just fancy synonyms for “failure.”

A failure mode is simply any event that causes a functional failure.

I didn’t realize how critical these terms were until I started my first job as a reliability engineer.

My first role was working on surgical robots. One of my initial responsibilities was building a Failure Reporting, Analysis, and Corrective Action System (FRACAS), which is like a platform for reporting failures observed during testing, demonstrations, or field use. Essentially, it’s a database for capturing product failure information.

My task sounded straightforward: extract insights and present findings such as:

• Which components fail most frequently
• What types of failures or root causes are associated with specific components
• Quantitative metrics like failure rates for individual parts

But reality was different. Failure reports varied wildly:

• Some documented only functional failures without root cause analysis.
• Others noted vague symptoms like “error code popped up” with no context.
• Some described components by appearance alone, forcing me to investigate part numbers and locations.

I spent weeks cleaning and restructuring data, filling gaps, standardizing terminology, and organizing failures into meaningful categories. Eventually, I realized the root problem:

there was no clear, consistent way to describe and report failures effectively.

That’s why I’m writing this, to share my thoughts on why describing failures matters and how to do it better.

Why does Failure Descriptions Matter?

Clear failure descriptions are essential for reliability work because they improve:

• Communication
• Documentation
• Analysis

Without a shared framework, the same failure can be described in many ways, causing confusion and wasted time. Structured reporting turns raw data into actionable insights by grouping failures, identifying patterns, and building searchable records. Precise descriptions also support analysis by tracking failure frequency, prioritizing critical issues, and guiding design improvements. In short, describing failures well is the foundation for understanding and improving system reliability.

How to Describe Failures: Think in Chains

To describe a failure effectively, we first need to break it down: what makes a failure instance? Failures in a product or system typically result from a combination of interconnected events (failure modes). Each failure mode has a cause-and-effect relationship with another, forming a chain. One failure mode exists due to the next level failure mode.

Engineers use failure analysis (or root cause analysis) to trace and link these modes. The result is a structured view of the failure: starting from the top-level functional failure, moving through subsystem-level symptoms, and ending at the root causes: such as a faulty component, a physical or chemical reaction, human error, or environmental stress.

What is a failure instance

Example: System Initialization Failure

A surgical robot

Consider a surgical robot system. When powered on, it begins an initialization process that verifies connections and communication between all stations (robot, camera, PC). Only after these checks succeed can the user proceed to the next step. The example below illustrates a failure description for one specific case of system initialization failure.

Failure break down into failure modes

In this example, the top-level failure mode (Level 0) is a functional failure. Each subsequent level represents a deeper cause, linked by the phrase “due to.” For instance:

• Level 0 failure is due to Level 1: The system fails to initialize due to the connection test failing.
• Level 1 failure is due to Level 2: The connection test fails due to the robot-PC connection not being established.
• And so on.

Each failure mode is described using the format: [Subject] + [Verb], such as “the wire fractures” or “the cable is discontinuous.”

Through failure analysis, we identified failure modes from Level 0 to Level 5, forming a detailed chain for this initialization failure. This hierarchy clearly illustrates the cause-and-effect relationships behind the failure, making it easier to understand and address.

What level should failure analysis stop?

The next question is: how deep should we go? Digging into another level of failure mode adds cost and effort. If we reach a level where we have no control or cannot take meaningful action, continuing the analysis becomes wasted labor. That’s why it’s critical to identify the right level of detail, one that is both actionable and meaningful for resolution.

For practical purpose, a root failure mode is defined as the last cause we choose to pursue in the failure analysis. Root failure mode is where the failure analysis should stop at. It is not necessarily the lowest-level physical cause, but rather the point where:

1. A specific physical object or condition is clearly identified. For example, “The connection between the robot station and the PC is not established” is not an appropriate root failure mode, since there can be several components involved in the connection between robot station and PC and we cannot isolate the cause.
2. The root failure mode should be actionable, meaning the subject described in root failure mode can be repaired, replaced, redesigned, or controlled. Going beyond this level would not add practical value based on your role, scope, or authority.

The determination of root failure mode also depends on different scenarios, the following uses the same initialization failure, but due to different scenarios, the root failure modes are different.

• If the connection cable is a commercial off-the-shelf part, and engineers simply replace it when it fails, then cable discontinuity is a sufficient root failure mode.
• If the cable is a proprietary design, and your team has control over its internal structure, then it makes sense to go deeper and identify Ethernet wire fracture as the root failure mode.

In short, the root failure mode is where failure analysis stops, because further investigation would not lead to more actionable insights or is outside the scope of control.

Key Takeaways

• Language matters: precise failure descriptions enable better communication, documentation, and analysis.
• Think in terms of chains of failure modes, not just symptoms.
• Define a root failure mode that is specific and actionable.
• Good failure reporting is the foundation for reliability improvement.

Reference:

Failures vs. Functional Failures vs. Failure Modes vs. Failure Mechanism

What is the Difference Between Failure Analysis (FA), Root Cause Analysis (RCA) and Root Cause Failure Analysis (RCFA)?