Building Software That Saves Lives: Common Safety Techniques in Safety-Critical Systems

When it comes to safety-critical software—whether in aircraft avionics, medical devices, nuclear control systems, or automotive braking—failure isn’t just an inconvenience; it can be catastrophic. That’s why safety-critical software engineers don’t just focus on functionality—they focus on fault detection, error prevention, and fail-safe design.

Over decades of practice and research, engineers have developed a range of techniques to make sure that when something goes wrong, it is either detected, mitigated, or rendered harmless. Below are some of the most widely used safety-related implementation techniques that help ensure such software performs reliably under all conditions.

---

1. Checksums and Cyclic Redundancy Checks (CRC)

Data corruption during transmission or storage can cause unpredictable behavior in safety-critical systems. To guard against this, developers use checksums and CRC (Cyclic Redundancy Checks) to verify the integrity of data.

A checksum works by computing a numerical value from a block of data, which is then compared at the receiver’s end to detect alterations. CRCs go a step further by using polynomial division to detect even subtle bit errors. For example, in an aircraft’s data bus or an automotive ECU, CRC ensures that every message received is exactly what was sent—no bit lost, no corruption undetected.

Figure 1: Illustration of how CRC works

2. Range and Plausibility Checks

Before any data or input is used in computation, it is first validated to ensure it falls within an expected range and makes logical sense. For instance, if a sensor reports that the engine temperature is –50°C when the system is running, that’s physically impossible—and a plausibility check flags it immediately.

These checks help prevent erroneous sensor readings or software faults from propagating into dangerous control actions. It’s a simple but powerful defense line that often prevents larger failures.

3. Interlocks and Mutual Exclusion Checks

Interlocks are mechanisms that ensure two conflicting operations cannot occur simultaneously. For example, an aircraft’s landing gear cannot retract while the weight-on-wheels sensor indicates that the aircraft is still on the ground.

Similarly, mutual exclusion checks prevent two control units from commanding the same actuator in opposite directions at the same time. Interlocks maintain logical consistency and physical safety, ensuring the system operates only in valid and safe states.

4. Watchdog Timers

A watchdog timer is a hardware or software timer that continually monitors system health. If the software becomes stuck in an infinite loop or stops responding, the watchdog timer resets the system to a known safe state.

In safety-critical domains, watchdogs prevent “hangs” or “frozen states” that could leave actuators unresponsive or control loops unstable. For example, in an automotive braking system, a watchdog ensures the microcontroller is alive and processing data continuously—if not, it triggers an immediate safe shutdown.

Figure 2: Illustration of how Watchdog Timer works

5. Redundancy and Cross-Monitoring

Redundancy is one of the cornerstones of safety-critical design. It means using multiple independent systems to perform the same function and compare results.

For example, modern aircraft flight control systems use triplex or quadruplex redundancy, where three or four processors independently compute control commands. If one gives a deviating result, it’s outvoted or isolated.

Similarly, cross-monitoring involves one subsystem checking another’s output for consistency. These techniques ensure that no single fault leads to system failure, embodying the principle of “no single point of failure.”

6. Safe State and Graceful Degradation

When an unavoidable fault occurs, the system should transition to a safe state—a condition that minimizes risk to life or property. For instance, a train control system may apply emergency brakes, or an infusion pump may halt operation and alert medical staff.

Some systems are also designed for graceful degradation, where instead of complete shutdown, the system continues partial operation in a restricted but safe mode. This approach helps balance safety and availability in real-world scenarios.

7. Memory Protection and Partitioning

In systems with multiple software components, one faulty module can corrupt others if memory is shared freely. To prevent this, safety-critical architectures use memory protection units (MPU) or partitioned operating systems (like ARINC 653 in avionics).

This ensures that faults remain contained within their boundaries, preventing cascading errors and maintaining overall system stability. It’s like having fireproof walls between rooms—if one catches fire, the whole building doesn’t burn down.

8. Error Detection and Correction Codes (EDAC / ECC)

In high-radiation or noisy environments (like aerospace or space systems), bit flips in memory are a serious risk. Error Detection and Correction (EDAC) or Error-Correcting Codes (ECC) automatically detect and correct such memory errors before they affect program execution.

This low-level protection ensures that software can continue running safely even under physical stress conditions where hardware is imperfect or degraded.

9. Defensive Programming

Defensive programming is a mindset that assumes anything can go wrong—from invalid inputs to hardware malfunctions. Developers write code that checks preconditions, handles unexpected values gracefully, and always fails safe rather than fail dangerously.

Figure 3: What is defensive programming

This principle ensures the system remains predictable and controlled even in the face of abnormal conditions. As the saying goes in safety engineering: “Hope is not a safety strategy.”

Conclusion: Engineering for the Unexpected

Safety-critical software isn’t just about writing code that works—it’s about writing code that keeps working safely when things go wrong. Techniques like checksums, interlocks, watchdogs, redundancy, and memory protection form the defensive layers that make this possible.

In these systems, every bit, every check, and every state transition is deliberate—because the cost of failure is far too high. The goal isn’t perfection, but controlled imperfection—a design resilient enough to detect, handle, and recover from the unexpected, ensuring safety above all else.