A remote site controlled from a distant host has a dangerous failure mode: the link can die silently, leaving the site running on its last received command with nobody watching or able to intervene. A deadman timer guards against exactly this by requiring the host to keep proving it is still there, and driving the site to a safe state if it stops. This guide explains what a deadman timer is, how the absence of a host update triggers a safe-state action, and why it protects a remote asset when the link goes quiet.
Deadman timer in one line: A deadman timer is a timer at a remote device that expects to be regularly refreshed by the controlling host and, if that refresh does not arrive within the set time, drives the device or process to a predefined safe state. Named for the deadman's switch that acts when the operator lets go, it protects a remote asset from running unsupervised on stale commands when the link to the host goes silent.
When a remote device takes direction from a controlling host over a link, it normally acts on the commands and setpoints the host sends. The hidden risk is what happens if that link fails without the device noticing. Communication can stop for many reasons - a modem dies, a carrier drops, a cable is cut, the host itself falls over - and unless the device is built to react, it will simply keep doing whatever it was last told, indefinitely. It sits there executing a command that may have been appropriate when it arrived but has since become wrong or unsafe, because conditions have changed and no one can update it.
This is worse than an obvious failure because it is silent. The device appears to be working - it is running, executing its last instruction - but it has effectively been abandoned, cut off from the supervision it depends on, and there is no operator able to see the situation or intervene. A process left running on stale commands with the link dead can drift into a hazardous condition with nothing to stop it, and the very thing that should have caught the problem, the connection to the host, is the thing that is broken.
The safe way to handle this is to treat the loss of the host's presence as a condition to act on in its own right, not something to wait out passively. Rather than assuming the last command remains valid until a new one arrives, the device should assume that if it has not heard from the host for too long, it can no longer be sure its current action is safe, and it should move to a state that is safe regardless of what the process is doing. A deadman timer is the mechanism that enforces exactly that assumption.
A deadman timer works by requiring continual reassurance. The controlling host must regularly send the remote device something that resets the timer - an update, a periodic refresh, a keep-alive - and as long as those arrive within the timer's window, the device carries on normally, taking the steady stream of refreshes as evidence that the host is present and in control. The timer is constantly counting down toward expiry and constantly being reset before it gets there, so in normal operation it never actually fires.
The timer fires only when the refreshes stop. If the set time elapses without the expected update from the host, the device concludes that supervision has been lost and takes its safe-state action - it does not wait to be told, because the whole point is that nobody can tell it anything. What that safe state is depends entirely on the asset and the process: it might close a valve, stop a pump, open or trip an output, hold at a fixed safe setting, or shut the equipment down in an orderly way. The defining idea is that the action is chosen in advance to be safe under loss of supervision, and it happens automatically on timeout.
The naming captures the logic precisely: a deadman's switch is one that must be actively held to keep a machine running and that acts the moment the operator lets go, so the safe outcome is the default and continued operation requires ongoing positive input. A deadman timer applies the same fail-safe philosophy to a communication link - the link must keep being actively proven alive to keep the device running as commanded, and the moment that proof stops, the device falls to safety. Silence is treated as a command to be safe, which is the opposite of assuming silence means everything is fine.
A deadman timer is one of a family of related safeguards, and it is worth being clear about what distinguishes it. A watchdog timer generally guards a device against its own internal hang - it resets the device if the device's own logic stops running. A communications watchdog and a heartbeat detect that a link is down and typically raise an alarm about it. The deadman timer's distinctive job is the action: it does not merely notice that the host has gone quiet, it drives the process to a defined safe state because of that silence. Its focus is the safe-state response to the absence of a host update, not the detection alone.
Because of that, the deadman timer is inherently a local safety function, living in the remote device rather than in the host, and it must be, since it exists precisely for the situation where the host cannot be reached. It should keep working even when everything upstream has failed, which means it cannot depend on the very link it is protecting against. Setting its timeout is a considered choice: long enough that a brief, recoverable communication dropout does not needlessly trip the site to its safe state, but short enough that a genuinely dead link does not leave the asset running unsupervised for longer than is safe.
For a cloud SCADA platform such as Merobix, the deadman timer is the last line of defence that makes remote supervision safe, and it lives at the site precisely because it must survive the loss of the connection to the cloud. The platform provides the monitoring and the supervisory commands over the link, but the guarantee that a remote asset will fail to a safe condition if that link dies rests with the local device and its deadman timer, not with the cloud. That division is deliberate and correct: the cloud supervises when the link is healthy, and the deadman timer takes over the instant it is not, ensuring a remote site can never be left running blind on stale commands when contact is lost.
A watchdog timer generally guards a device against its own internal failure, resetting the device if its own logic stops running normally. A deadman timer instead watches for the absence of updates from an external controlling host and drives the device or process to a predefined safe state when those updates stop. The watchdog protects a device from hanging itself; the deadman timer protects a process from running unsupervised when the host or link goes silent.
It depends entirely on the asset and the process, and the state is chosen in advance to be safe under loss of supervision. It might close a valve, stop a pump, trip or open an output, hold at a fixed safe setting, or shut equipment down in an orderly way. The common thread is that whatever the action, it is defined ahead of time so the device can fall to it automatically when the host stops refreshing it, without needing any further instruction.
Because it exists precisely for the situation where the controlling host cannot be reached, so it cannot depend on the link it is protecting against. If it lived in the host or relied on the connection, a dead link would disable the very safeguard meant to handle a dead link. Keeping it local means it continues to function and can drive the asset to a safe state even when everything upstream, including the connection to the cloud, has failed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.