Watchdog and Safe State Management
Overview
Watchdog timers and safe‑state mechanisms ensure that the system transitions into a predictable and controlled condition when a fault occurs.
The watchdog supervises software execution and detects stalls, deadlocks, or timing violations.
Safe‑state logic defines how each function behaves after a fault—whether it must be disabled, reset, isolated, or driven to a predefined output.
Together, they form the backbone of system‑level fault reaction and functional safety compliance.
Role of the Watchdog
The watchdog timer (WDOG) monitors software execution and triggers a reaction when the system fails to refresh it within a defined time window.
- detects software failures such as infinite loops, deadlocks, or missed deadlines
- enforces timing constraints by requiring periodic servicing
- triggers fault reactions such as reset, interrupt, or safe‑state activation
- supports windowed operation to detect both early and late refreshes
- acts as an independent supervisor separate from the main CPU
- is often complemented by an external watchdog for redundancy and diversity
Types of Watchdog Timers (from basic to ASIL‑capable)
Different watchdog architectures provide different levels of diagnostic coverage.
In safety‑critical systems, the watchdog must detect not only absence of servicing, but also incorrect or malicious servicing.
1. Basic Watchdog (Pattern Refresh: 55h → AAh)
- simplest form
- software writes a fixed sequence (e.g., 0x55 → 0xAA)
- detects stalls, infinite loops, missed deadlines
- limitations:
- a faulty loop may still refresh it
- no protection against early refresh
- no protection against repeated patterns
- diagnostic coverage: low
2. Windowed Watchdog
- refresh must occur not too early and not too late
- detects:
- software running too fast (e.g., runaway loops)
- software running too slow
- missing refresh
- prevents refresh in tight loops
- diagnostic coverage: medium
- required for many ASIL‑B/ASIL‑C systems
3. Challenge‑Response Watchdog (LFSR / Algorithmic)
- the value to write changes over time
- often generated by an LFSR or cryptographic sequence
- watchdog verifies the correctness of the written value
- prevents:
- repeated refresh patterns
- spoofing
- refresh from unintended code paths
- diagnostic coverage: high
- used in ASIL‑C/ASIL‑D MCUs
- often paired with an external watchdog for diversity
This progression (basic → windowed → challenge‑response) reflects increasing robustness and safety integrity.
Safe State Concept
A safe state is a predefined condition that ensures the system cannot cause harm after a fault.
Each function must define its own safe state based on its role and safety goals.
Examples:
- actuators → disabled, open‑circuit, neutral position
- power stages → shut down or limited
- communication interfaces → silent mode or error frames
- control loops → freeze outputs or degrade operation
- sensors → report invalid values or trigger fallback logic
Safe states must be deterministic, reachable within bounded time, and verifiable.
Fault → Reaction → Safe State
Fault handling follows a structured sequence:
1. Fault detection
Detected by FCCU, watchdog, PMIC, ECC, or peripheral diagnostics.
2. Fault classification
Critical, non‑critical, recoverable.
3. Reaction mechanism
The system may:
- trigger an interrupt
- assert a reset
- activate safe‑state outputs
- isolate faulty domains
- notify external devices (PMIC, watchdog, actuators)
4. Transition to safe state
Each function moves to its predefined safe state within the required reaction time.
5. Recovery or shutdown
The system may attempt controlled recovery or remain in safe state until reset.
Watchdog and Safe State Integration
The watchdog is tightly coupled with safe‑state logic:
- if the watchdog expires, the system must enter a safe state immediately
- watchdog resets must be routed through the FCCU or safety manager
- safe‑state outputs must be asserted before or during reset
- external watchdogs must confirm MCU behavior
- watchdog servicing must be performed only by verified software tasks
This ensures that software failures cannot lead to uncontrolled behavior.
Board‑Level Interaction
Watchdog and safe‑state mechanisms extend beyond the MCU:
- MCU → PMIC
request power‑down or emergency shutdown - PMIC → MCU
assert fault lines when rails are unstable - external watchdog → MCU
trigger reset or safe‑state activation - MCU → actuators
drive outputs to safe values before reset
This coordination ensures system‑wide safety integrity.
Relationship with Security
Although watchdog and safe‑state logic belong to Safety, they intersect with Security:
- fault injection attacks may attempt to trigger watchdog resets
- attackers may try to prevent watchdog servicing
- safe‑state outputs must be protected from spoofing
- secure boot ensures watchdog configuration cannot be altered
Safety and security must be co‑designed to avoid conflicting behaviors.
