Fault tolerance — fail-safe vs fail-operational

Overview

Fault tolerance is the ability of a system to continue operating correctly even when components fail. Two fundamental strategies define how systems respond to faults: fail-safe (shut down to prevent harm) and fail-operational (continue functioning despite failures).

[!intuition] Core Intuition

Think of an elevator versus an airplane:

• Elevator (fail-safe): If the cable sensors detect a problem, the emergency brakes CLAMP immediately. The elevator stops. Passengers are stuck but safe. The system chooses "do nothing" over "do something wrong."
• Airplane (fail-operational): If one engine fails, the plane MUST keep flying using the remaining engine(s). Shutting down mid-flight is catastrophic. The system must maintain critical functions despite component loss.

WHY do we need different strategies? Because the cost of failure differs:

• Fail-safe: Loss of function is SAFER than incorrect function (nuclear reactors, railway signals, medical devices)
• Fail-operational: Loss of function is MORE DANGEROUS than degraded function (aircraft, spacecraft, pacemakers, self-driving cars at highway speeds)

[!definition] Formal Definitions

Fail-Safe

A system that, upon detecting a fault, transitions to a safe state where it cannot cause harm. The safe state is typically:

• Passive safe: System powers down, locks out, or physically disconnects (e.g., E-stop button)
• Active safe: System actively maintains safety (e.g., holding brakes engaged)

Mathematical model: If fault detected at time $t_f$, system must reach safe state $S_{safe}$ within deadline $\Delta t_{max}$: $P(\text{reach } S_{safe} | t< t_f + \Delta t_{max}) \geq 1 - \epsilon$ where $\epsilon$ is acceptably small (e.g., $10^{-9}$ for SIL 4 safety integrity level).

Fail-Operational

A system that continues to perform critical functions despite faults, usually with redundancy. Key properties:

• Graceful degradation: Non-critical features may be lost, but safety-critical functions persist
• No single point of failure: Multiple components can fail without total loss

Availability requirement: For mission time $T$ and fault arrival rate $\lambda$: $A(T) = P(\text{system operational at } T) \geq A_{target}$ Typically $A_{target} > 0.9999$ (four nines) for critical systems.

[!formula] Deriving Reliability from First Principles

Fail-Safe: Mean Time to Dangerous Failure (MTTDf)

Start with: A component fails with constant hazard rate $\lambda$. We want to compute the probability that a failure leads to danger.

Step 1: Define safe failure fraction $\beta$. When a failure occurs:

• Probability $\beta$: failure is detected and system enters safe state
• Probability $(1-\beta)$: failure is undetected (dangerous)

Step 2: Total failure rate $\lambda$ splits: $\lambda = \lambda_s + \lambda_d$ where $\lambda_s = \beta \lambda$ (safe failures), $\lambda_d = (1-\beta)\lambda$ (dangerous).

Step 3: Dangerous failure probability over time $t$: $P_{\text{dangerous}}(t) = 1 - e^{-\lambda_d t}$

Step 4: Mean Time to Dangerous Failure: $\text{MTTDf} = \int_0^\infty e^{-\lambda_d t} \, dt = \frac{1}{\lambda_d} = \frac{1}{(1-\beta)\lambda}$

WHY this matters: For a safety system with $\lambda = 10^{-5}$ failures/hour and $\beta = 0.99$ (99% safe failures): $\lambda_d = (1-\beta)\lambda = 0.01 \times 10^{-5} = 10^{-7}\ \text{h}^{-1}$ $\text{MTTDf} = \frac{1}{\lambda_d} = \frac{1}{10^{-7}} = 10^{7}\ \text{hours} \approx 1141\ \text{years}$ (since $10^7\ \text{h} \div 8760\ \text{h/yr} \approx 1141\ \text{yr}$). Making failures self-revealing (high $\beta$) buys three orders of magnitude of safety.

Fail-Operational: Redundancy and MTBF

Scenario: Triple Modular Redundancy (TMR) — three identical units with majority voter.

Step 1: Single unit has failure rate $\lambda$, MTTF = $1/\lambda$.

Step 2: System fails only if 2+ units fail. Use binomial:

• Probability all 3 work at time $t$: $[e^{-\lambda t}]^3 = e^{-3\lambda t}$
• Probability exactly 2 work (1 failed): $\binom{3}{1}e^{-2\lambda t}(1-e^{-\lambda t})$

Step 3: System operational if 2+ units work: $R_{\text{sys}}(t) = e^{-3\lambda t} + 3e^{-2\lambda t}(1-e^{-\lambda t})$

Step 4: For small $\lambda t$ (early life), expand $(1-e^{-\lambda t}) \approx \lambda t$: $R_{\text{sys}}(t) \approx e^{-3\lambda t} + 3\lambda t\, e^{-2\lambda t}$

Step 5: MTTF for TMR (integrate $R_{\text{sys}}$ from 0 to $\infty$): $\text{MTTF}_{\text{TMR}} = \frac{5}{6\lambda}$

WHY surprising: With 3x components, MTTF is only ~0.83x a single component! But: Early-life reliability is much better. At $t = 0.1/\lambda$ (so $\lambda t = 0.1$):

• Single: $R(0.1/\lambda) = e^{-0.1} \approx 0.905$
• TMR (exact): $R_{\text{sys}} = e^{-0.3} + 3e^{-0.2}(1-e^{-0.1}) \approx 0.7408 + 3(0.8187)(0.0952) \approx 0.9746$
• TMR (first-order approx): $e^{-0.3} + 3(0.1)e^{-0.2} \approx 0.7408 + 0.2456 \approx 0.9864$

So TMR reduces the failure probability from ~9.5% to ~2.5% at this early-life point — a big win where it matters most.

[!example] Example 1: Railway Signal System (Fail-Safe)

Scenario: Track signal controls train entry. Must show RED if uncertain.

Design:

1. Lamp filament: Monitored continuously. If current drops (burnt filament), system detects failure.
2. Fail-safe relay: Spring-loaded to de-energize. Requires continuous power to show GREEN.
3. Fault response: Any sensor fault → relay de-energizes → signal defaults to RED.

WHY each step?

• Filament monitoring: Detects if the signal physically cannot show red/green
• Spring-loaded relay: Guarantees safe state (RED) on power loss — no software needed
• Default RED: Trains will stop. Causes delay, not accident.

Code check (simplified):

enum State { GREEN, RED };
State signal_state = RED;  // Default safe
 
void update_signal() {
    if (filament_ok() && track_clear() && power_ok()) {
        signal_state = GREEN;
    } else {
        signal_state = RED;  // ANY fault → safe state
    }
}

Key property: Code defect can't make signal stay GREEN when unsafe — hardware relay enforces RED on any anomaly.

[!example] Example 2: Aircraft Flight Control (Fail-Operational)

Scenario: Fly-by-wire Airbus A320 — pilot stick inputs go through computers to control surfaces. MUST tolerate computer failures at cruise altitude.

Design:

1. Triple redundancy: 3 identical flight control computers (FCCs), each running same software.
2. Dual redundancy: 2 elevator computers (ELACs), 3 spoiler/aileron computers (SECs).
3. Voting: Each control surface receives commands from multiple computers. Physical actuator averages or votes.
4. Dissimilar redundancy: Some backup uses different hardware + software implementation.

WHY each step?

• 3 FCCs: If 1 fails, majority vote (2 vs 1) identifies and overrides the faulty one.
• Multiple surface controllers: If ELAC-1 fails, ELAC-2 takes over elevator control immediately.
• Dissimilar backup: Protects against common-mode failures (e.g., software bug affects all identical units).

Graceful degradation path:

• Normal: All systems → full fly-by-wire with envelope protection (Normal Law)
• Some computers lost: Alternate Law — reduced protections, still full software fly-by-wire
• Further loss: Direct Law — stick maps directly to control surfaces with no envelope protection, but STILL software-driven fly-by-wire (not a mechanical cable-and-lever system). The aircraft remains controllable.
• The very limited mechanical backup on the A320 is only rudder + trimmable horizontal stabilizer, used purely to keep the aircraft steady while computers/power are restored — not full manual flight.

Math check: With 3 FCCs, $\lambda = 10^{-4}$ failures/hour, 10-hour flight: $P(\text{≥2 fail}) = P(\text{exactly 2}) + P(\text{all 3}) = \binom{3}{2}p^2(1-p) + p^3$ where $p = 1- e^{-10^{-4} \cdot 10} \approx 10^{-3}$: $P(\text{≥2 fail}) \approx 3 \times (10^{-3})^2 + (10^{-3})^3 \approx 3 \times 10^{-6}$

One in ~333,000 flights would lose voting. With backup ELACs/SECs and degraded control laws, actual risk is orders of magnitude lower.

[!example] Example 3: Insulin Pump (Hybrid Approach)

Scenario: Implanted insulin pump must deliver precise doses. Overdose is fatal; underdose causes hyperglycemia.

Design:

1. Fail-operational for short faults: Dual processors cross-check. If one glitches, the other takes over.
2. Fail-safe for persistent faults: If error persists >3 checks, pump stops delivery and alarms.
3. Watchdog timer: Independent hardware timer. Pump must "pet" watchdog every 100ms. Miss → shutdown.

WHY hybrid?

• Transient faults (cosmic ray bit flip): Fail-operational. Resume quickly.
• Persistent faults (processor damage): Fail-safe. Stop before causing harm.

Verification:

• Dual-processor compare on every dose calculation. Mismatch → halt.
• Watchdog ensures software hasn't crashed (infinite loop). Hardware forces safe state.

[!mistake] Common Mistakes

1: "Redundancy always improves safety"

Why it feels right: More backups = more reliability, right?

The reality: Redundancy can introduce new failure modes:

• Complexity: More components = more interaction failures. Byzantine faults where one unit gives conflicting outputs.
• Common-mode failures: All redundant units share the same bug, power supply, or environmental stress.
• Voting logic errors: If the voter itself is faulty, redundancy is useless.

Example: Boeing 737 MAX MCAS used TWO angle-of-attack sensors but ONLY read ONE at a time per flight (alternating flights). A single bad sensor caused crashes because the system didn't compare both simultaneously.

Fix:

• Use dissimilar redundancy (different hardware/software).
• Make voters simpler and independently verified.
• Test for common-mode failures (thermal, radiation, power transients).

Mistake 2: "Fail-safe just means 'turn off'"

Why it feels right: Safe state = no power = off.

The reality: Some systems need active safe states:

• Holding brakes: Must APPLY brakes (active), not release them.
• Containment: Nuclear reactor control rods must INSERT (active) on fault.
• Ventilation: Biolab must maintain negative pressure (active) even during faults.

Fix: Safe state is application-specific. Ask: "What state prevents harm if all control is lost?" Then design hardware defaults + fail-safe actuators to enforce that state.

Mistake 3: "Fail-operational can always degrade gracefully"

Why it feels right: Lose one subsystem, the rest picks up.

The reality: Some systems have cliff failures:

• Threshold effects: Aircraft with 2 engines can fly. Aircraft with 0 engines cannot glide indefinitely.
• Cascading failures: One overloaded redundant unit fails, increasing load on others, causing chain collapse.

Example: Power grid blackouts. Lose one line → neighbors pick up load → neighbors overload → cascade.

Fix:

• Design for spare capacity (N+2 redundancy, not just N+1).
• Implement load shedding (drop non-critical functions before catastrophic failure).
• Model cascading failure paths.

[!recall]- Explain to a 12-Year-Old

Imagine you have a really important toy robot that needs to keep working no matter what.

Fail-safe is like having a big red STOP button. If something goes wrong (like a wire gets loose), the robot immediately freezes and turns off. It won't do anything dangerous. This is perfect for things like a robot that could hurt someone if it went crazy — better to stop than to keep going the wrong way.

Fail-operational is like having TWO brains in the robot. If one brain breaks, the other brain keeps the robot working! The robot might move a little slower or can't dance anymore, but it still walks and doesn't fall over. This is perfect for things that MUST keep working, like a robot on Mars (can't just stop — no one is there to fix it!).

Think about your bicycle:

• Brakes = fail-safe: If the brake cable snaps, the brake pads stop touching the wheel. You can't brake anymore, but the wheel won't get stuck (which would make you crash).
• Two wheels = fail-operational: If you get a flat tire, you can still ride (slowly, carefully) on the other wheel instead of being stranded.

The big idea: Some things are safer if they STOP when broken (fail-safe). Other things are safer if they KEEP GOING even when broken (fail-operational). Engineers choose based on what's more dangerous!

[!mnemonic] Memory Aids

FAIL-SAFE = "Stop And Freeze Everything"

• Stop immediately
• Alarm/Alert
• Freeze in known-good state
• Ensure no harm

FAIL-OPERATIONAL = "Keep Running Despite Damage"

• Keep critical functions alive
• Redundancy required
• Degrade gracefully

When to use which?

• "STOP is safe" → Fail-safe (elevators, e-stops, traffic lights defaulting red)
• "STOP is danger" → Fail-operational (planes, spacecraft, life support)

Connections

• Watchdog timers and health monitoring — How fail-safe systems detect faults
• Redundancy patterns (N+1, TMR, DMR) — Architectures for fail-operational systems
• Safety Integrity Levels (SIL) — Quantifying required MTTDf
• Common-mode failures and diversity — Why redundancy isn't enough
• Byzantine fault tolerance — Handling malicious or inconsistent failures
• Real-time scheduling with fault recovery — Timing guarantees after failover
• Hardware safety mechanisms — Physical fail-safe relays, watchdogs
• Formal verification of safety properties — Proving fail-safe transitions

Flashcards

Concept Map

Hinglish (regional understanding)

Hinglish (regional understanding)