In this lesson, you will learn how to design hardware and software redundancy schemes to ensure your system remains operational even when a single component fails.
The Philosophy of Redundancy
At its core, fault tolerance is about removing single points of failure. If your system relies on one CPU or one sensor to keep the vehicle or medical device running, a single hardware defect leads to a total system failure. By adding redundant components, we ensure that if one unit fails, another can take over the workload or detect the error to reach a "fail-safe" state.
Hardware Redundancy: TMR
A classic architectural approach is Triple Modular Redundancy (TMR). In TMR, you run three identical modules in parallel. Their outputs feed into a "voter" circuit. If two modules agree and one disagrees, the voter ignores the outlier, allowing the system to continue working without interruption.
Software Redundancy: N-Version Programming
Software redundancy involves running multiple, independently developed versions of the same algorithm. If the primary version crashes or returns an invalid result (detected perhaps by an assertion or watchdog), the system switches to the secondary implementation.
Consider this simplified software switch:
// Redundant sensor processing
float get_sensor_data() {
float val1 = sensor_primary_read();
float val2 = sensor_backup_read();
if (is_valid(val1)) {
return val1;
} else if (is_valid(val2)) {
log_error("Primary sensor failed; using backup.");
return val2;
} else {
trigger_safe_shutdown();
return 0.0f;
}
}
Challenges in Redundancy
While redundancy increases reliability, it introduces the risk of Common Cause Failures. If both your primary and backup sensors are connected to the same faulty power rail, they may fail simultaneously regardless of the redundant logic. Furthermore, redundancy increases complexity, weight, and power consumption. You must weigh the Probability of Failure on Demand (PFD) against the overhead of adding extra hardware or software logic.
Key Takeaway: Fault tolerance is achieved by duplicating critical functions so that the failure of one component is masked by the operational integrity of the redundant counterpart.