Why having a backup isn't the same as actually surviving a failure.
Bolt a second sensor, motor, or controller onto a system and it's tempting to call the system "fault-tolerant." It usually isn't. Redundancy just means duplicate hardware exists — two encoders where one would do, a spare motor, a backup controller sitting on standby. Fault toleranceis a behavior: the system keeps operating correctly through a failure. Redundancy is an ingredient. Fault tolerance is what happens when that ingredient is combined with two things redundancy alone never provides — a way to notice a component has actually failed, and logic that automatically switches operation over to the one that hasn't. Skip either of those and the spare part is just unused inventory sitting next to a single point of failure.
Picture a robot joint fitted with two position encoders, Sensor A and Sensor B, both wired to the controller and both fully capable of reporting the joint's angle. On paper that's a redundant design — the kind of bullet point that shows up on a spec sheet as "dual-redundant position feedback." What that spec sheet doesn't say is what the controller actually does with the second sensor. If the control logic simply always reads Sensor A and has no path that ever looks at Sensor B, the two diagrams below show exactly the same hardware producing two completely different outcomes when Sensor A fails.
Redundancy on its own answers only one question: is there a working spare somewhere in the system? It says nothing about whether the system knows when to reach for it. Fault tolerance requires two more pieces of engineering layered on top. First, fault detection — some mechanism that actively recognizes a specific component has failed, rather than just trusting whatever it reports. That's usually a cross-check against the redundant unit, a plausibility test (does this value make physical sense?), or a rate-of-change sanity check (can the joint really have moved 90° in one control cycle?). Second, switchover — logic that automatically reconfigures the system to use the working component's output in place of the failed one, without waiting for a person to intervene. Redundant hardware makes switchover possible. Detection is what tells the system when to do it. Neither one exists automatically just because a second sensor was bolted on.
False, and it's one of the most dangerous assumptions in safety-critical design. A duplicate-parts count on a spec sheet — "dual redundant sensors," "backup controller," "secondary motor" — describes hardware, not behavior. A system can have fully redundant sensors, motors, or controllers and still fail catastrophically on a single component fault if nothing is actively watching for that failure and routing around it. In the diagrams above, both configurations have identical hardware — the same two encoders. Only the logic differs, and that logic is the entire difference between a system that quietly keeps using a dead sensor's bad data (often until a safety incident makes the failure obvious the hard way) and one that catches the fault and reroutes around it in real time. This is exactly why fault-tolerant system design in robotics, aerospace, and industrial safety standards specifies detection and switchover requirements explicitly — coverage, detection latency, switchover time — rather than simply counting spare parts. Redundancy is a necessary ingredient. It is not the recipe.
Explains why simply having duplicate or backup components (redundancy) does not automatically make a system fault-tolerant. Real fault tolerance requires redundancy plus two additional mechanisms — active fault detection and automatic switchover/reconfiguration — illustrated with a robot joint carrying two position encoders, one setup that lacks detection logic and one that has it.
Redundancy means a system has more than one component capable of performing the same function — a second sensor, a spare motor, a standby controller. It is purely a statement about what hardware exists. Nothing about the definition of redundancy implies that anything in the system is checking whether the primary component has failed, or that anything would happen automatically if it did. A robot arm can ship with two fully functional, identically wired position encoders and still have zero built-in resilience to either one failing, if the control logic only ever reads one of them.
Fault tolerance is the property that a system continues to operate correctly through a fault. Achieving it requires three things working together: (1) redundant components capable of taking over the function, (2) fault detection — logic that actively recognizes a specific component has failed, typically via cross-checking it against a redundant unit, a plausibility test, or a rate-of-change/rate-limit check, and (3) switchover (or reconfiguration) — logic that automatically routes the system to the working component in place of the failed one, without waiting for a human to notice. Redundancy supplies the raw material; detection and switchover are the engineering that turns that material into actual protection.
A textbook version of this gap: a robot joint has two position encoders, Sensor A and Sensor B, both wired into the controller. If the controller's logic simply always reads Sensor A with no path that ever consults Sensor B, then when Sensor A fails — freezes, drifts, or reports a plausible-looking but wrong value — the controller keeps commanding motion based on that bad data. Sensor B, despite being perfectly healthy, contributes nothing, because nothing in the system ever asks it a question. The failure typically surfaces only when something downstream notices the consequence: a collision, an out-of-tolerance part, a safety system tripping on unrelated evidence — not because the "redundant" design caught it. This is why real fault-tolerant systems in robotics, aerospace, and industrial safety design specify detection coverage and switchover time as explicit requirements, rather than treating a duplicate-parts count as sufficient evidence of resilience.
Redundancy is the presence of duplicate or backup components capable of performing the same function — for example, two position sensors on one joint. Fault tolerance is the system-level behavior of continuing to operate correctly when a fault occurs, which requires redundancy plus active fault detection and an automatic switchover mechanism. Redundancy is necessary for fault tolerance but not sufficient on its own.
Yes, and it is a common real-world failure mode. If a system has duplicate hardware but the control logic always reads a single, fixed source with no check on its validity and no path to the backup, the redundant component provides zero actual protection. The system will keep using a failed component's bad output indefinitely, exactly as if the backup did not exist.
Fault detection is the mechanism that actively recognizes when a specific component has failed, rather than assuming its output is always valid. Common techniques include cross-checking a value against a redundant sensor, plausibility checks (does the value make physical sense given known limits), and rate-of-change or rate-limit checks (is this change physically possible in one control cycle). Without detection, a system has no way to know a switchover is even needed.
Switchover (sometimes called reconfiguration or failover) is the automatic action a system takes once a fault is detected — routing control to the working redundant component in place of the failed one, without requiring a person to intervene. It is the step that actually converts detected redundancy into continued correct operation.
Because the value of fault tolerance depends on how fast and how reliably the detection-and-switchover chain works, not just on whether it exists in principle. A system that eventually detects a failed sensor after a long delay, or that only sometimes catches certain failure modes, provides much weaker protection than one with fast, high-coverage detection. That is why fault-tolerant system specifications in robotics, aerospace, and industrial safety standards call out detection coverage and switchover time as explicit, measurable requirements rather than a simple yes/no "has a backup" checkbox.
Not by itself. Adding a third or fourth redundant sensor without also extending the detection and switchover logic to actually use them provides no additional protection — it is more unused spare hardware. Fault tolerance improves when the detection logic is extended to cover the new components (for example, voting among three sensors instead of a simple two-way check) and the switchover logic is updated accordingly.
Try our Robotics & Automation Studio
More calculators, simulators, and guides for this discipline.