EC-20.8 Reliability and Functional Safety in a Product That Ships

What this is and why it exists

A device that can hurt somebody is held to a different standard, and the difference is mostly about evidence.

The technical measures are not exotic. Watchdogs, safe states, redundancy and self-checks are all straightforward. One thing separates a safety-related product from an ordinary one. Somebody wrote down what could go wrong, decided how bad each case was, showed what the design does, and kept the record.

This topic is that argument. It is the last one in the module because it depends on everything before it. You cannot argue a device is safe without knowing its timing, its failure modes and its behaviour offline.

The vocabulary

• Hazard — a condition that could lead to harm.
• Failure mode — a specific way a part or function can stop working correctly.
• Severity — how bad the consequence is when a failure occurs.
• Detectability — how likely the failure is to be noticed before it causes harm.
• Safe state — the condition the system is designed to fall into when it cannot continue.
• Watchdog — a timer that resets the system when software stops confirming progress.
• Redundancy — a second means of achieving the same function.
• Common-cause failure — one cause that defeats every redundant copy at once.
• Mean time between failures — an average that assumes a constant failure rate.

The mental model

Start with the walk-through. Take the design part by part and ask what happens if this one fails open, fails shorted, or gets stuck at a value. This finds hazards that no amount of testing would, because testing only exercises the failures you thought to inject. The output is a table, and the table is the deliverable.

Each row gets three scores, and keeping them separate is what stops the assessment collapsing into one unexamined opinion. Severity is how bad the outcome is. Likelihood is how often it happens. Detectability is whether anything notices in time. A rare, severe, undetectable failure is far more dangerous than a common, harmless, obvious one.

Then the defences. A watchdog resets a system that has stopped confirming progress, and it helps only if the state it resets into is safe. What "safe" means for your product is a design decision, made explicitly. A heater turns off, a motor stops, a valve closes. Guessing at it afterwards is how a watchdog makes things worse.

Redundancy buys less than it appears to. Two identical units fail identically when the cause is a design fault, a shared supply or a common environment. Diversity — in implementation, in supply, in physical location — is what turns duplication into real protection.

A functional safety standard mostly governs process. What analysis was done, what evidence exists, who reviewed it, how changes are controlled, how tools are qualified. Teams meeting one for the first time are usually surprised by how little of it is about code. That is not bureaucracy for its own sake: the argument that a product is safe is an argument about the process that produced it.

Last, a caution about numbers. A large mean time between failures says nothing about wear-out, and assumes a constant failure rate the product may not have. Quoting it without its assumptions is one of the more common pieces of engineering dishonesty.

What you should now be able to explain or do

• Work through a small design part by part and produce a failure mode table.
• Score a hazard on severity, likelihood and detectability, and say why separately.
• Define the safe state for a given product, and explain what a watchdog needs from it.
• Explain why identical redundancy is weaker than it looks.
• Say what a functional safety standard asks of a development process.
• Read a reliability figure and state the assumptions it hides.

Check yourself