What Is a Watchdog Timer?
Detecting a System That Went Quiet

Back to Blog

How a Watchdog Timer Works

The mechanism is deliberately simple: a timer counts down toward zero, and normal operation continually resets it before it gets there. As long as the resets keep coming, the timer never expires and nothing happens. If the resets stop - because the processor froze, the program hung, or the link went dead - the timer runs out and triggers a predefined action: reboot the processor, trip an output to a safe state, or raise an alarm.

A common form is a communications watchdog (or heartbeat). Two systems agree that one will regularly toggle or increment a value the other watches. If that heartbeat stops updating for too long, the receiving side knows the link or the far end has failed and can fail safe - close a valve, shut in a well, or annunciate a comms-fail alarm - rather than blindly holding the last known command forever.

Deadman vs Watchdog, and Where They Are Used

The terms overlap. A watchdog timer usually refers to automatic supervision of a machine or communications link. A deadman (or dead-man's switch) classically refers to a control that requires continuous human presence - release it, or fail to acknowledge it, and the system stops - the idea being that an incapacitated operator should not leave equipment running unattended. Both share the core principle: the safe default is triggered by the absence of an expected signal.

In practice these timers are everywhere in industrial systems. PLC processors run an internal hardware watchdog that reboots the CPU if the scan hangs. SCADA and telemetry links use communications watchdogs so a remote site fails to a safe state if it loses contact with the host. Remote-control functions often layer a deadman-style requirement so a command must be actively confirmed and does not persist indefinitely. The result is a system that treats silence as a fault, which is exactly what you want when a controller or link fails.

Choosing the Timeout Interval

The timeout is the one number that makes or breaks a watchdog, and it cannot be copied from another site. It has to be longer than the longest gap between resets the healthy system will ever produce, including retries, and shorter than the time the process can safely run unsupervised. Those two bounds come from different places: the first from the communications design - poll rate, link latency, retry count - and the second from the process hazard analysis. When they do not overlap, the fix is to speed up the heartbeat or add an intermediate layer of local protection, not to stretch the timer until the nuisance trips stop.

Telemetry style matters here. On a slowly polled radio network, a healthy outstation may legitimately go a long time between messages, so a watchdog set for a fast wired network will chatter constantly. On links using report by exception, silence is the normal condition, which means a watchdog cannot infer health from data traffic at all - it needs an explicit periodic heartbeat or integrity poll layered on top. Set the timeout from the worst legitimate quiet period, add margin for retries and congestion, and record the reasoning so the next engineer does not treat the number as arbitrary.

Building a Heartbeat That Proves the Right Thing

A heartbeat only proves the health of whatever generates it. If a communications module answers polls on its own, a poll response proves the module and the link are alive while the application program behind them may be stopped. The stronger pattern is a register the application logic itself updates each cycle: a PLC program adds one to a counter, the remote partner reads it, and only a changing value counts as alive. A frozen counter alongside healthy comms tells you precisely that the program, not the link, is the problem - a distinction that saves hours in the field.

Counters beat toggling bits for another reason: a bit stuck in one state looks identical to a bit that toggled an even number of times between reads. An incrementing value that must change between samples is unambiguous, provided the watcher handles rollover when the counter wraps. In a two-way scheme, each end increments its own counter and watches the other, so failure is detected symmetrically - the host knows the RTU went quiet, the RTU knows the host did, and each side takes its own predefined action.

Commissioning Tests and Common Pitfalls

A watchdog that has never been tripped on purpose should be treated as untested. Prove it during commissioning and again after any change to the communications path:

1. Disconnect the link (or stop the heartbeat source) and time how long the watchdog takes to act.
2. Verify the safe action actually occurs at the field device, not just as a status bit in software.
3. Verify the failure annunciates as an alarm an operator will see, with a clear message.
4. Restore the link and confirm the system recovers to a known state without unexpected restarts of equipment.
5. Record the test result and the configured timeout in the site records.

The classic pitfalls are quiet ones. A watchdog that only raises an alarm, with no one assigned to respond, protects nothing. Two systems that each assume the other is doing the watching leave a gap neither covers. A safe action that was defined but never wired - the trip output landing on a spare terminal - passes every desk review and fails on the day it matters. And any change to poll rates or network equipment can silently invalidate the timeout, which is why watchdog settings belong in management-of-change, with any process-shutdown behavior verified by qualified personnel to site procedures.

Frequently Asked Questions