Electronics Guide

Faults, Errors, and Failures

The fault-error-failure chain describes how problems propagate through a system. A fault is the underlying cause of a problem, such as a manufacturing defect, a design mistake, or environmental stress. When a fault is activated, it produces an error, which is an incorrect internal state within the system. If the error propagates to the system's outputs and causes deviation from correct behavior, a failure occurs. Understanding this chain is essential because fault tolerance mechanisms can intervene at different points: preventing faults, detecting and correcting errors, or containing failures.

Faults are classified by their temporal behavior and cause. Permanent faults persist until repair, such as a failed transistor or broken trace. Transient faults appear temporarily due to environmental factors like cosmic rays or electromagnetic interference, then disappear. Intermittent faults recur unpredictably, often due to marginal components or loose connections that manifest problems under certain conditions. Each fault type requires different detection and handling strategies.

Reliability Metrics

Reliability is quantified using several related metrics. Mean Time Between Failures (MTBF) measures the average time a repairable system operates between failures. Mean Time To Failure (MTTF) applies to non-repairable systems. Failure rate, usually denoted lambda, represents failures per unit time; it is the reciprocal of MTBF only while the failure rate is constant, which is the flat middle region of the classic bathtub curve between early-life (infant mortality) failures and end-of-life wear-out. Mean Time To Repair (MTTR) captures restoration time, and steady-state availability is MTBF divided by the sum of MTBF and MTTR. Component failure rates are frequently expressed in FIT units, where one FIT is one failure per billion device-hours.

For safety-critical systems, the governing metric is the probability of dangerous failure rather than the failure rate as a whole, because only failures that leave the system unable to perform its safety function matter. IEC 61508 expresses this two ways depending on how the safety function is used. For continuous or high-demand operation, the measure is the average frequency of dangerous failure per hour (PFH): SIL 4 requires a PFH of at least 10^-9 but less than 10^-8, SIL 3 at least 10^-8 but less than 10^-7, and so on by decades. For low-demand operation, where the safety function is called upon rarely, the measure is the average probability of failure on demand (PFD_avg), with SIL 4 spanning 10^-5 to 10^-4. Achieving such low probabilities requires combining multiple independent protection layers, each contributing to overall system safety, because no single layer can credibly be claimed to those numbers on its own.

Common Cause Failures

Common cause failures occur when a single event causes multiple redundant components to fail simultaneously, defeating the protection that redundancy provides. A power supply failure that affects all redundant processors, a software bug present in all identical software instances, or an environmental event that damages all sensors simultaneously are examples of common cause failures. These failures are particularly dangerous because they can cause complete system failure despite extensive redundancy.

Defending against common cause failures requires diversity: using different designs, different manufacturers, different technologies, or different implementation approaches for redundant components. Physical separation prevents localized events from affecting all redundant elements. Independent power supplies, separate cable routes, and isolated enclosures reduce the likelihood that a single event can defeat redundancy.

Coverage and Latent Faults

Fault coverage is the probability that a fault, once it occurs, will be detected by the system's fault detection mechanisms. High fault coverage is essential for fault tolerance because undetected faults cannot be handled. However, achieving 100% coverage is impractical; some faults will escape detection. The residual undetected faults, called latent faults, can accumulate over time and reduce the actual redundancy of the system below its designed level.

Periodic testing and diagnostics detect latent faults before they accumulate to dangerous levels. Built-in self-test (BIST) routines exercise components and verify correct operation. Comparison of redundant outputs reveals discrepancies indicating latent faults. The interval between diagnostic tests must be short enough that the probability of multiple latent faults accumulating remains acceptably low.

Static Redundancy

Static redundancy, also called masking redundancy, uses voting among multiple redundant components to mask faults automatically without any reconfiguration. Triple Modular Redundancy (TMR) is the classic example: three identical components perform the same computation, and a majority voter selects the output that at least two components agree upon. A single faulty component is outvoted and its incorrect output is masked, with no switchover transient and no dependence on a diagnostic algorithm noticing the fault first.

TMR masks single faults well but costs at least triplication of hardware, power, and mass, and it introduces a subtlety that is easy to overlook: the voter itself is a single point of failure. Practical designs either triplicate the voters, so each redundant channel drives its own voter and the replication extends all the way to the actuators, or implement the voter in a simple, highly verifiable form whose failure rate can be argued to be negligible against the channels it arbitrates.

N-modular redundancy (NMR) generalizes the concept to any number of channels with appropriate voting thresholds. Aerospace flight controls commonly use quadruplex channels, described in the trade's shorthand as fail-operational, fail-operational, fail-safe: after a first channel failure the system continues in a triplex voting configuration, after a second it continues as a comparison pair that can detect but no longer mask disagreement, and a third failure forces a reversion to a safe or degraded mode. A triplex system by comparison is fail-operational then fail-safe. The choice of redundancy level follows from the required reliability, the acceptable cost and weight, the expected fault rate, and whether the application must keep functioning after failures or may instead shut down safely.

Dynamic Redundancy

Dynamic redundancy uses fault detection and reconfiguration rather than voting to achieve fault tolerance. A primary component performs the function while standby components remain ready to take over. When fault detection mechanisms identify a failure in the primary, the system switches to a standby. This approach requires less hardware than static redundancy but depends critically on effective fault detection.

Hot standby configurations keep backup components powered and synchronized with the primary, enabling rapid switchover. Cold standby saves power but requires initialization time before the backup can assume control. Warm standby represents an intermediate approach where backups are powered but not fully synchronized. The choice depends on allowable switchover time and power constraints.

Hybrid Redundancy

Hybrid redundancy combines static and dynamic approaches. A typical hybrid system uses N-modular redundancy with voting but can replace failed modules with spares. This approach provides the fault masking benefits of voting while extending system lifetime through replacement of failed components. Hybrid approaches are common in long-duration missions where component failures are expected over the operational lifetime.

Self-purging redundancy automatically identifies and removes faulty components from the voting pool, preventing a failed component from corrupting system outputs after its fault is detected. The remaining components continue voting, albeit with reduced fault tolerance until the failed component is replaced or repaired.

Graceful Degradation

Graceful degradation allows a system to continue operating with reduced capability when redundancy is exhausted. Rather than complete failure, the system provides a subset of its normal functionality. An aircraft flight control system might lose certain autopilot modes while retaining manual flight capability. A medical device might continue basic monitoring while disabling advanced features.

Designing for graceful degradation requires careful analysis of which functions are essential and which can be sacrificed. The system must clearly indicate its degraded state to operators. Degraded modes must be thoroughly tested to ensure they provide adequate safety and functionality. The transition from normal to degraded operation must be smooth and must not itself introduce hazards.

N-Version Programming

N-version programming applies the concept of voting redundancy to software. Multiple development teams independently implement the same specification, producing diverse software versions. These versions run on separate hardware, and their outputs are compared through voting. The assumption is that independent development will produce different bugs, so a fault in one version will not appear in others, enabling the correct output to be selected by voting.

The effectiveness of N-version programming depends on achieving true independence between versions, and that assumption does not hold as well as the technique's early advocates hoped. The best-known evidence is an experiment published by John Knight and Nancy Leveson in 1986, in which twenty-seven independently written versions of the same specification failed on common inputs far more often than statistical independence would predict. Programmers given the same problem tend to misunderstand the same ambiguous requirement and to stumble over the same hard corner of the algorithm, so their mistakes correlate.

The practical response is not to abandon diversity but to be honest about what it buys. Careful, unambiguous specification removes the largest shared source of correlated error. Diverse development environments, different programming languages, different compilers, and genuinely different algorithms where the problem admits them all widen the separation between versions. Reliability claims, however, should not assume independence between versions; certification authorities generally require diversity to be argued on its merits rather than credited with a multiplicative reduction in failure probability. Because N-version programming multiplies development and maintenance cost by the number of versions, many projects now prefer a single rigorously developed version paired with an independent, much simpler monitor that checks its outputs.

Recovery Blocks

Recovery blocks provide software fault tolerance through acceptance testing and alternate algorithms. The primary algorithm executes first, and its result is checked by an acceptance test. If the test passes, the result is used. If the test fails, indicating a potential error, an alternate algorithm executes and its result is tested. Multiple alternates can be chained, each providing another chance for successful completion.

The effectiveness of recovery blocks depends on the quality of the acceptance test. The test must reliably distinguish correct from incorrect results without duplicating the computation. Simple range checks or reasonableness tests can catch gross errors. More sophisticated tests compare results against simplified models or verify invariant relationships. Designing effective acceptance tests requires deep understanding of the computation and its expected outputs.

Checkpointing and Rollback

Checkpointing periodically saves system state to stable storage, enabling rollback to a known-good state after errors are detected. When an error is detected, the system restores the most recent checkpoint and resumes execution. Transient faults that do not recur will not cause the error to reappear, enabling recovery without understanding the specific fault.

Checkpoint frequency involves trade-offs between recovery time and overhead. Frequent checkpoints minimize lost work after rollback but impose overhead for saving state. Infrequent checkpoints reduce overhead but may require repeating substantial computation after errors. Incremental checkpointing, which saves only changed state, reduces overhead while maintaining fine checkpoint granularity.

Exception Handling

Robust exception handling enables software to respond to unexpected conditions without crashing. Rather than propagating errors to cause system failure, well-designed exception handlers contain problems and initiate recovery actions. Exception handling should be comprehensive, covering all potential error conditions, with default handlers for unexpected exceptions.

Defensive programming practices complement exception handling. Input validation rejects invalid data before it can cause problems. Assertions verify assumptions and detect logic errors during development. Watchdog timers detect infinite loops or deadlocks. These techniques help prevent errors from occurring and detect them quickly when they do, enabling timely recovery.

Coding Techniques

Error-detecting and error-correcting codes add redundant information that enables detection or correction of bit errors. A single parity bit detects any odd number of bit errors in a data word but cannot locate or correct them. Cyclic redundancy checks (CRC) are strong against the burst errors typical of serial links and storage; a well-chosen 32-bit polynomial detects all bursts up to 32 bits and the overwhelming majority of longer ones. A basic Hamming code corrects any single-bit error. Adding one overall parity bit produces the extended Hamming code, which raises the minimum distance to four and yields the single-error-correction, double-error-detection (SEC-DED) behavior that conventional error-correcting code (ECC) memory relies on: single-bit upsets are corrected transparently, and double-bit errors are detected and reported but not corrected. Memories exposed to higher upset rates, such as those in spacecraft, use stronger codes or interleave the bits of each codeword across physically separated cells so that one particle strike cannot corrupt two bits of the same word.

Arithmetic codes enable error detection in computational results. Residue codes check that computation results are consistent with expected residues. AN codes multiply data by a constant, enabling verification through divisibility checks. These techniques detect errors in arithmetic units without fully duplicating the computation.

Watchdog Timers

Watchdog timers detect software hang conditions where a processor stops executing its intended program. The watchdog timer must be periodically reset by the software; if the software fails to reset it within the timeout period, the watchdog triggers a recovery action such as system reset. Properly implemented watchdogs verify that software is not merely running but is making meaningful progress through its control flow.

Window watchdogs require reset within a specific time window, detecting both hung software (no reset) and runaway software (reset too quickly). Sequence watchdogs require resets in a specific pattern or sequence, verifying that software is executing the expected control flow. These enhanced watchdogs provide more thorough monitoring than simple timeout watchdogs.

Comparison and Voting

Comparison of redundant outputs is a powerful error detection technique. Dual redundancy with comparison detects any fault that causes the two units to disagree but cannot determine which unit is faulty. Triple redundancy with voting both detects and masks single faults, identifying the faulty unit as the one that disagrees with the majority.

Comparison must account for acceptable variations in analog signals and timing differences in digital systems. Comparison thresholds must be tight enough to detect meaningful errors but loose enough to avoid false alarms from normal variations. For time-critical comparisons, synchronization ensures that redundant units are comparing corresponding data.

Built-In Self-Test

Built-in self-test (BIST) provides on-demand or periodic verification of hardware and software function. Hardware BIST exercises circuits with known test patterns and verifies expected responses. Memory BIST writes and reads test patterns to detect stuck bits, addressing faults, and coupling faults. Processor BIST executes instruction sequences that verify correct operation of all processor functions.

BIST can run during system initialization, detecting faults before normal operation begins. Periodic BIST during operation detects faults that develop over time. Background BIST runs continuously at low priority, testing components when they are not needed for normal operation. The diagnostic coverage of BIST determines what fraction of possible faults it can detect.

Reasonableness Checks

Reasonableness checks verify that data values and system states fall within expected ranges and exhibit expected relationships. Range checks verify that sensor readings fall within physically possible limits. Rate-of-change checks detect impossibly rapid variations indicating sensor failure or noise. Cross-checks verify consistency between related measurements, such as altitude from different sensors agreeing within tolerance.

Model-based checking compares actual system behavior against predicted behavior from a simplified model. Significant deviations indicate either model error or system malfunction. Signal processing techniques such as filtering and outlier detection distinguish genuine signals from noise-induced errors. These techniques leverage domain knowledge to detect errors that simpler checks would miss.

Safe State Identification

Identifying safe states is the first step in fail-safe design. In some systems, the safe state is obvious: a railway signal defaults to showing a stop indication. In others, analysis is required to determine which state minimizes harm. For a medical infusion pump, the safe state might be to stop infusion and alarm, preventing overdose. For a vehicle brake system, the safe state might be to apply brakes, though this requires careful consideration of driving scenarios.

Some systems have no single safe state; the safest action depends on the operating context. An aircraft control system cannot simply shut down during flight. These systems require more sophisticated fault tolerance that maintains critical functions rather than transitioning to a static safe state. Fail-operational requirements are more demanding than fail-safe requirements.

Fail-Safe Hardware Design

Hardware can be designed to fail toward safe states. Normally-open relay contacts ensure that power is removed from controlled equipment when the relay coil fails or loses power. Mechanical interlocks physically prevent dangerous configurations. Spring-return actuators move to safe positions when power is lost. These passive safety mechanisms do not depend on detection or active response.

Redundancy can be arranged to favor safety or availability, and the voting architecture is where that choice is made. In one-out-of-two (1oo2) voting, either channel alone can command a shutdown, so any single channel failure toward the tripped state stops the process: this maximizes safety but roughly doubles the rate of spurious trips, which is costly in a continuous process and can itself introduce hazards. Two-out-of-three (2oo3) voting requires two channels to agree before tripping, so a single channel failing in either direction is outvoted rather than obeyed. That masks one dangerous failure and suppresses spurious trips at the same time, which is why 2oo3 is the workhorse architecture for safety instrumented systems that must be both trustworthy and available. Diagnostics matter here: once a channel is diagnosed as failed and removed, a 2oo3 group is normally degraded to 1oo2 for a limited repair window rather than left voting with a known-bad channel.

De-energize-to-trip wiring complements these arrangements by making loss of power a protective action rather than a silent loss of protection. The safety function is held off by the presence of current, so a broken wire, a blown fuse, or a dead power supply produces the same result as a genuine trip demand. Energize-to-trip designs, sometimes unavoidable when the safe state requires positive action such as firing a suppression system, must add line monitoring and backup power to compensate for the fact that they fail silent by default. These choices build safety into the fundamental architecture rather than delegating it to software.

Safe Shutdown Sequences

When a system must shut down due to detected faults, the shutdown sequence itself must be safe. Abrupt shutdown might leave actuators in dangerous positions or release stored energy unsafely. Controlled shutdown sequences bring the system to a safe state in an orderly manner, verifying each step before proceeding to the next.

Shutdown sequences must be robust against the very faults that triggered them. If a processor fault triggered shutdown, the same processor cannot reliably execute the shutdown sequence. Independent safety processors or hardwired shutdown logic ensure that shutdown completes even when the main control system has failed. Testing shutdown sequences is critical, as they execute rarely and problems may go unnoticed.

Fail-Safe Software

Software fail-safe design ensures that software failures lead to safe outcomes. Default outputs should be safe values, not uninitialized or unpredictable. Control loops should include limits that prevent actuators from reaching dangerous positions even if software requests them. Output monitoring can detect software outputs that violate safety constraints and override them.

Defensive programming prevents many failure modes from occurring. Validated inputs cannot carry corrupted data into calculations. Bounded loops cannot run indefinitely. Checked array accesses cannot corrupt adjacent memory. Memory protection prevents runaway code from modifying critical data. These techniques make software more robust and ensure that when failures do occur, their effects are contained.

Health Monitoring

Continuous health monitoring tracks the status of all redundant components. Each component reports its operational status through health messages or by successfully completing assigned tasks. Monitoring systems collect this information, identify components showing signs of degradation, and maintain overall system health status.

Predictive health monitoring uses trends and patterns to identify components likely to fail soon, enabling proactive replacement before failure occurs. Temperature monitoring, error rate tracking, and performance degradation detection all provide early warning of impending failures. Addressing problems before they cause failures improves both safety and availability.

Fault Isolation

When faults are detected, they must be isolated to prevent propagation to other components or subsystems. Electrical isolation prevents faults from affecting power distribution. Communication isolation prevents faulty components from corrupting shared buses. Logical isolation removes faulty components from voting pools and marks them as unavailable for activation.

Fault containment regions define the boundaries within which faults are contained. Components within a containment region may affect each other, but faults cannot cross containment boundaries. Careful design of containment regions ensures that single faults cannot defeat redundancy by affecting multiple redundant components simultaneously.

Switchover Mechanisms

Dynamic redundancy requires switchover mechanisms to transfer control from failed primary components to backups. Switchover must be fast enough that the interruption does not cause system problems. It must be complete enough that no state is lost or corrupted during transition. It must be reliable enough that the switchover mechanism itself does not become a single point of failure.

State synchronization ensures that backup components have current information needed to assume control. Hot standby systems maintain continuous synchronization, enabling immediate switchover. Cold standby systems may require initialization and state loading, extending switchover time but reducing steady-state power and complexity. The choice depends on allowable switchover time and operational requirements.

Reconfiguration Strategies

System reconfiguration after failures determines how remaining resources are allocated to maintain required functions. Simple reconfiguration substitutes a backup for a failed primary. Complex reconfiguration might redistribute workload among surviving components, assign lower-priority functions to reduced-capability backups, or shed non-essential functions to preserve resources for critical ones.

Reconfiguration logic itself must be fault-tolerant. Reconfiguration decisions based on faulty diagnostic information can make matters worse by deactivating healthy components or activating faulty ones. Distributed reconfiguration, where multiple managers coordinate rather than depending on a single manager, improves robustness but increases complexity.

Design Diversity

Design diversity uses different approaches for redundant implementations. Different algorithms solving the same problem, different circuit topologies implementing the same function, or different software architectures providing the same capability all contribute to design diversity. The assumption is that different designs will have different weaknesses, making simultaneous failure less likely.

The effectiveness of design diversity depends on how independent the different designs truly are. Common requirements, common development tools, or common assumptions can introduce correlated failures despite superficial differences. Achieving effective diversity requires conscious effort to make designs genuinely different in ways that matter for fault independence.

Technology Diversity

Using different technologies for redundant components provides protection against technology-specific failure modes. Combining analog and digital implementations, different semiconductor processes, or different component types reduces vulnerability to systematic defects in any single technology. A pressure measurement system might combine piezoresistive and capacitive sensors to guard against failure modes specific to either technology.

Technology diversity increases design and maintenance complexity since different skills and tools are required for each technology. The benefits must be weighed against these costs, considering the specific failure modes of concern and whether diversity effectively addresses them.

Physical Separation

Physical separation prevents localized events from affecting multiple redundant components. Redundant equipment installed in separate enclosures, separate rooms, or even separate buildings cannot all be affected by a single fire, flood, or other local event. Separate cable routes ensure that a single cable break or fire does not disrupt all redundant communications.

The degree of separation required depends on the hazards being protected against. Protection against equipment fires might require only separate enclosures. Protection against aircraft breakup might require distribution across different aircraft sections. Protection against site-wide events might require geographically distributed redundancy.

Temporal Diversity

Temporal diversity executes redundant operations at different times, providing protection against transient faults that occur at specific moments. If a cosmic ray corrupts a calculation, repeating the calculation moments later will likely produce the correct result. Temporal diversity is often combined with other redundancy approaches, repeating operations when comparison detects a discrepancy.

The interval between redundant operations must be long enough that transient faults have cleared but short enough that the system state has not changed significantly. For real-time systems, the delay introduced by temporal redundancy must be compatible with response time requirements.

Fault Injection Testing

Fault injection deliberately introduces faults to verify system response. Hardware fault injection might disconnect power to redundant units, corrupt signals, or disable components. Software fault injection might modify memory, delay messages, or corrupt data. Simulation-based fault injection enables testing of faults that would be impractical or dangerous to inject into real hardware.

Systematic fault injection tests the system's response to each postulated fault, verifying detection, isolation, and recovery. Coverage analysis ensures that testing addresses all significant fault types. Fault injection campaigns typically inject thousands of faults to build statistical confidence in system behavior.

Reliability Analysis

Reliability analysis quantifies the probability of system failure and demonstrates that it meets requirements. Fault tree analysis works backward from system failure to identify combinations of component failures that could cause it. Reliability block diagrams model how component reliabilities combine to determine system reliability. Markov models capture the dynamics of fault tolerance including detection delays and repair.

Common cause failure analysis extends basic reliability analysis to account for failures affecting multiple components. Beta factor and other methods estimate the probability of common cause failures based on design and operational factors. This analysis often reveals that common cause failures dominate system failure probability despite extensive redundancy.

Safety Assessment

Safety assessment demonstrates that residual risk from potential system failures is acceptably low. Hazard analysis identifies what could go wrong and its consequences. Risk assessment combines failure probability with consequence severity to quantify risk. Comparison against risk criteria determines whether the system is acceptably safe.

Safety cases document the argument that a system is safe for its intended use. They compile evidence from analysis, testing, and operational experience to support safety claims. Independent assessment by qualified reviewers verifies the validity of safety arguments before systems are approved for deployment.

Operational Testing

Operational testing exercises the complete system under realistic conditions. Long-duration testing reveals problems that shorter tests miss, including memory leaks, clock drift, and wear mechanisms. Environmental testing verifies operation under temperature, vibration, and electromagnetic stress. Stress testing pushes the system beyond normal conditions to find margin limits.

Regression testing after changes verifies that modifications have not degraded fault tolerance. Test automation enables frequent regression testing without excessive cost. Configuration management ensures that tested configurations match deployed configurations, preventing untested code from reaching the field.

Aviation Systems

Aviation demands the highest levels of fault tolerance because of the catastrophic consequences of failure and the impossibility of repair during flight. Flight control systems use multiple redundant computers, often built from dissimilar processors and dissimilar software, so that a single design error or a single silicon erratum cannot disable every channel. Development assurance follows DO-178C for airborne software and DO-254 for complex airborne electronic hardware, with the rigor of the objectives scaled to the design assurance level, from level A for functions whose failure is catastrophic down to level E for functions with no safety effect.

The architectural requirement comes from the airworthiness rules themselves. CS-25.1309 and the equivalent FAR 25.1309 require that catastrophic failure conditions be extremely improbable and that they not result from a single failure. Advisory material puts a number on "extremely improbable": an average probability on the order of 10^-9 per flight hour. Meeting both halves of that requirement at once is what drives triplex and quadruplex architectures, physical and electrical segregation between channels, and painstaking common cause analysis, since redundancy alone satisfies the single-failure clause but does nothing for the probability target if the channels can be lost together.

Backup strategies have shifted with the generations. The Airbus A320 family retains a mechanical backup path, with the rudder and the trimmable horizontal stabilizer controllable through pedals and trim wheels without electrical power or computers, and the Boeing 777 similarly keeps limited direct-cable control of selected surfaces. Newer designs have dropped mechanical reversion entirely: the Airbus A350 and the Boeing 787 rely on segregated electrical backup paths, independent power sources, and simplified backup control units rather than cables and pushrods. The long service life of aircraft also demands attention to aging, corrosion, and wear mechanisms that could quietly reduce redundancy over decades of operation.

Medical Devices

Medical devices present unique fault tolerance challenges because failures can directly harm patients. Infusion pumps must not deliver incorrect doses. Ventilators must continue providing respiratory support. Monitoring systems must not give false reassurance, and must not generate so many false alarms that staff learn to ignore them, a well-documented hazard in its own right. IEC 62304 governs the medical device software life cycle and scales its requirements by software safety class, from class A where no injury is possible through class C where death or serious injury may result. ISO 14971 supplies the risk management process that determines those classifications, and IEC 60601-1 covers the basic safety and essential performance of electrical medical equipment, including single-fault conditions that the device must survive without becoming hazardous.

Many medical devices must fail safe rather than fail operational, since continuing incorrect operation could be more harmful than stopping. Clear alarms and manual override capabilities enable clinical staff to respond when devices fail. The clinical context, including trained operators and backup procedures, is part of the overall safety system.

Automotive Systems

Automotive fault tolerance faces cost constraints that limit redundancy while still meeting safety requirements. ISO 26262 establishes Automotive Safety Integrity Levels (ASIL) that determine required fault tolerance for different functions. Braking systems might require ASIL D, the highest level, while comfort features require minimal safety measures.

Automotive architectures traditionally use simpler redundancy than aviation, relying on rapid fault detection and transition to a safe state within a defined fault tolerant time interval rather than on continued operation. A common pattern is the safety monitor: a main processor performs the function while a smaller, independent watchdog or companion device checks its outputs and can force the actuator to a safe condition on its own authority. ISO 26262 also permits decomposition, in which a high-ASIL requirement is discharged by two sufficiently independent lower-ASIL elements, an economically important alternative to full duplication.

Driver-in-the-loop designs treat the human driver as the fallback, an assumption that holds only while the driver is expected to be attentive. Higher levels of driving automation remove that fallback and force genuinely fail-operational architectures, with redundant power distribution, redundant steering and braking actuation, and redundant perception and compute paths, so that the vehicle can still reach a minimal risk condition after a failure. Automation also introduces hazards that are not failures at all: a sensor or algorithm can work exactly as designed and still be inadequate for the situation. ISO 21448, which addresses the safety of the intended functionality (SOTIF), complements ISO 26262 by covering these performance limitations and foreseeable misuse, and cybersecurity engineering under ISO/SAE 21434 addresses malicious causes that classical safety analysis does not model.

Industrial Control Systems

Industrial control systems protect against hazards in manufacturing, chemical processing, and other industrial operations. IEC 61508 establishes the generic framework for functional safety that other domain standards reference, and IEC 61511 applies that framework specifically to the process industries. Safety instrumented systems (SIS) provide protection layers that are independent of the basic process control system, so that a fault in normal control cannot also disable the protection against its consequences. Layer of protection analysis assigns the required risk reduction across these layers and determines the SIL that each safety instrumented function must achieve.

Industrial systems often have operational lifetimes measured in decades, requiring fault tolerance to address aging, drift, and component obsolescence. Redundant programmable logic controllers with hot standby capability maintain control despite component failures, and field devices are commonly arranged in 1oo2 or 2oo3 groups according to the balance wanted between safety and plant availability. Periodic proof testing is central rather than incidental: the SIL calculation for a low-demand function depends directly on the proof test interval, because undetected dangerous failures accumulate between tests, and a proof test regime that is not actually performed at the assumed interval invalidates the safety claim. Partial stroke testing of valves and continuous diagnostics reduce the burden by catching a fraction of those failures without a full shutdown. Security increasingly intersects with safety as connected industrial systems face cyber threats, and IEC 62443 addresses the industrial automation security practices that protect the integrity of these protection layers.

Space Systems

Space systems face extreme environmental conditions and the impossibility of repair after launch. Radiation acts on electronics in several distinct ways, and each calls for a different countermeasure. Single event upsets flip the state of a memory cell or register without damaging it. Single event transients inject glitches into combinational logic that may or may not be captured by a downstream latch. Single event latchup triggers a parasitic structure that draws destructive current until power is cycled. Total ionizing dose accumulates over the mission and gradually shifts thresholds and leakage until parts fall out of specification. Thermal cycling and vacuum add mechanical stress to solder joints and connectors.

The architectural responses follow directly. Triple modular redundancy with voting is common in spacecraft computers and is applied inside radiation-tolerant FPGAs at the flip-flop level. Because TMR alone only masks upsets rather than removing them, SRAM-based FPGAs pair it with configuration memory scrubbing, which continuously reads back and rewrites the configuration so that accumulated upsets cannot eventually outvote a majority. Memories use error-correcting codes with bit interleaving to handle upsets, and latchup protection circuits sense excess current and power-cycle the affected device. Cold spares conserve power while providing replacement capability for failed units, and watchdog-driven safe modes place the vehicle in a stable, sun-pointed, communicative state when onboard software cannot resolve a fault itself. Long-duration missions such as interplanetary probes require fault tolerance that remains effective for decades with light-time delays that rule out real-time intervention from the ground, which is why autonomous fault detection, isolation, and recovery is designed in from the start rather than added as a contingency.