Performing Failure Mode and Effects Analysis

In this lesson, you will learn how to systematically identify, classify, and prioritize potential failure points in your embedded design using Failure Mode and Effects Analysis (FMEA).

The Logic of FMEA

While fault trees help us understand how a top-level failure happens, FMEA is a bottom-up approach. We start at the component level—be it a sensor interface, a memory controller, or a specific interrupt service routine—and ask: "If this part fails, what happens to the rest of the system?"

For every identified failure mode, we score three criteria (usually on a scale of 1–10):

1. Severity (S): How catastrophic is the effect? (e.g., system reset vs. physical injury).
2. Occurrence (O): How likely is this failure?
3. Detection (D): How easily can our firmware catch this failure before it propagates?

Applying the FMEA Workflow

Imagine we are analyzing an I2C sensor reading function. We identify a failure mode: "Bus hang during transaction."

Potential Failure Mode	Effect	S	O	D	RPN
I2C clock stretching timeout	Device hangs indefinitely	8	3	2	48

The Risk Priority Number (RPN) is the product of $S \times O \times D$. An RPN of 48 tells us this is a high-priority risk requiring mitigation. We address this by implementing a hardware-software contract, such as a watchdog-protected transaction wrapper:

bool read_sensor_with_timeout(uint8_t addr, uint8_t *data) {
    uint32_t start = get_ticks();
    // Start I2C peripheral hardware
    while (!I2C_IsComplete()) {
        if ((get_ticks() - start) > TIMEOUT_THRESHOLD) {
            // Mitigate: Reset I2C block, log error for post-mortem
            I2C_Reset_Peripheral(); 
            return false;
        }
    }
    return true;
}

From Analysis to Action

Once you calculate RPNs, focus your engineering effort on the highest scores. If an RPN is high, you must either reduce the Occurrence (e.g., better signal integrity) or improve the Detection (e.g., adding an assertion-based verification check). FMEA is not a static document; as your firmware evolves, you must re-evaluate these risks to ensure your system remains robust against unforeseen interactions.

Key Takeaway: FMEA turns abstract system risks into quantifiable RPN scores, guiding your team to invest development time where it provides the greatest reliability impact.