Watchdog Timer

A watchdog timer is a supervision timer used to detect that software, a scheduler, a task set or a safety-relevant function has stopped making acceptable progress. If the watchdog is not refreshed correctly, it can reset the processor, assert an interrupt, latch a fault, disable outputs or force a safe state.

The engineering value of a watchdog is not the reset itself. The value is bounded fault detection and controlled recovery. A watchdog that simply restarts a processor while leaving outputs unsafe, losing diagnostic context or repeating the same fault is weak evidence.

Basic Timeout Rule

A simple watchdog timeout must be longer than the longest valid refresh interval and shorter than the unsafe exposure time:

where T_normal,max is the worst acceptable normal refresh interval, T_wd is the watchdog timeout and T_unsafe is the time before stale output, uncontrolled motion, missing therapy, thermal stress or another hazard becomes unacceptable.

This inequality is only a first screen. It does not prove that the right task is being supervised.

Health-Gated Refresh

A robust design refreshes the watchdog only after critical health evidence is current. For example, a firmware supervisor may require:

where each H term is a Boolean health flag based on real task progress or a fresh diagnostic result. If a background task or interrupt refreshes the watchdog regardless of control-loop progress, the watchdog can remain alive while the function that matters is frozen.

Health evidence may include advancing task counters, fresh sensor data, valid output update, no queue overflow, no critical interlock fault and successful communication within a defined age limit.

Windowed Watchdog

A windowed watchdog requires refresh inside a valid time interval:

Refreshing too late indicates a stall. Refreshing too early can indicate a runaway loop, corrupted scheduler state or a task that is bypassing normal supervision. Windowed designs are useful when a simple “kick the watchdog often enough” rule is too easy to satisfy accidentally.

The minimum window must be compatible with the health-check period. If health bits update every 20 ms, a refresh window that opens after 40 ms requires the supervisor to observe at least two valid health cycles before refresh.

Fault-to-Safe Time

For safety-related use, the important timing number is often the time from fault occurrence to safe state:

where T_detect is watchdog detection time, T_reset is reset or recovery time and T_output is time for output hardware or interlocks to reach the safe condition. A release requirement may state:

The watchdog timeout alone is not enough if boot time, actuator discharge, brake engagement, valve closure, drive-disable propagation or supervisory restart time dominate the hazard.

Worked Example

An embedded controller has measured maximum normal refresh interval:

The selected watchdog timeout is:

The stale-output hazard window is:

The basic timeout screen passes:

Reset and recovery require:

Worst-case fault-to-safe time is:

If the requirement is:

then the safe-state margin is:

Now check the window. If the watchdog opens at:

and an interrupt refreshes every:

the refresh is invalid by:

This is a design fault, even though the refresh is frequent. The refresh must prove system health, not only processor activity.

Boundary With Interlocks

A watchdog should not be the only protective layer. Hardware interlocks, output enables, brown-out behavior, actuator fail-safe states, current limits, emergency stops and independent protection logic may be needed outside the firmware objective.

The watchdog can detect loss of progress, but an interlock may be the mechanism that actually removes energy or prevents unsafe motion during reset. Engineering review should state which layer detects the fault, which layer makes the output safe and which evidence proves the sequence.

Validation Evidence

Useful evidence includes timing traces, task heartbeat logs, watchdog configuration, refresh decision table, reset-cause register capture, retained pre-reset context, boot timing, output-state measurements during reset, brown-out tests, interrupt-lockout injection, stuck-task tests, communication-deadlock tests, queue-overload tests and recovery tests from each firmware mode.

Common mistakes include refreshing the watchdog from a timer interrupt, clearing it before checking critical health bits, setting a timeout from convenience rather than hazard timing, assuming reset is safe, losing the original fault cause, ignoring window constraints, skipping brown-out behavior and validating only the successful path. A strong watchdog design states the timeout, window, health evidence, safe-state action, recovery rule and fault-injection evidence.