Safety Design Patterns

Safety design patterns are proven architectural solutions for meeting ISO 26262 safety requirements: redundancy patterns (homogeneous and heterogeneous), monitoring patterns (master-monitor, checker-corrector, cross-channel), voting architectures (2oo2, 2oo3, k-of-n), graceful degradation, plausibility checking, watchdog timers and end-to-end communication protection. The standard does not prescribe specific patterns - it demands architectural measures for fault detection, control and tolerance scaled by ASIL - and these patterns are the industry vocabulary for satisfying those demands, each with known failure independence properties, diagnostic coverage characteristics and ASIL applicability that can be cited as evidence in the safety case.

In a 2oo2 (two-out-of-two) architecture, two channels compute the result and both must agree for the output to be considered valid - it detects a single channel failure reliably, but cannot tell which channel failed, so disagreement forces a transition to the safe state and availability suffers. A 2oo3 architecture adds a third channel and votes majority: a single failed channel is outvoted, so the system detects the fault and keeps operating correctly. 2oo3 buys fault tolerance at the cost of hardware and a voter that becomes safety-critical itself - voter failure modes and common cause failures across channels must be analyzed explicitly.

A simple watchdog only proves the processor is alive enough to kick it. A windowed watchdog requires the kick inside a defined time window - too early is as suspicious as too late - which catches runaway loops that kick constantly. A question-and-answer watchdog goes further: the monitored processor must compute correct answers to challenges, proving it can still execute logic correctly, and a logical watchdog checks program flow sequence. Each step up increases the diagnostic coverage you can defensibly claim, which is why the guide pairs each configuration with coverage analysis rather than treating all watchdogs as equal.

ASIL D architectures typically combine patterns rather than rely on one: heterogeneous redundancy or a monitoring channel with an argued independence claim, hardware-supported monitoring such as a separate watchdog IC, end-to-end protection on safety-relevant communication, and defined graceful degradation into safe states. The production reference is the E-Gas 3-level concept: functional level, independent monitoring controller and dedicated watchdog IC, achieving ASIL D through heterogeneous redundancy with an explicit independence argument. The guide maps every pattern against ASIL A through D with diagnostic coverage claims and standard references, so the selection is evidence-based rather than habit.

The guide has 12 chapters spanning redundancy, monitoring, voting, graceful degradation, plausibility checking, watchdog, communication and software safety patterns, plus ASIL mapping and implementation guidelines. Six interactive diagrams let you explore redundancy configurations, voting design, degradation state machines, watchdog coverage, E2E profile selection and the pattern-by-ASIL matrix, and the E-Gas 3-level monitoring case study anchors everything in a production architecture. A free account starts you off, and the Pro and Expert plans unlock more of the library.