A device that has gone silent can look identical to one that simply has nothing to report. A heartbeat is the periodic sign of life that tells the two apart.
Heartbeat Signal in one line: A heartbeat is a periodic signal that one system sends to another to prove it is alive and the link between them is working. It might be an incrementing counter, a toggling bit, or a small keepalive message sent every few seconds. The receiver watches the heartbeat; if it stops arriving or stops changing within an expected window, the receiver concludes the sender or the connection has failed and raises an alarm.
The core problem a heartbeat solves is the silent failure. If an RTU freezes, or a network link goes dead, the last data it sent may still be sitting valid in the SCADA. Operators could stare at a screen showing a normal pressure that is actually hours old and no longer real. Without an independent liveness check, stale data is indistinguishable from live data.
A heartbeat makes liveness explicit. Because the sender changes the heartbeat value on every cycle, the receiver can confirm not just that a value arrived, but that fresh data is genuinely flowing. A frozen device might keep echoing a static value, but its heartbeat counter stops incrementing - immediately exposing the fault.
The simplest form is a counter register that the sender increments each scan. The receiver reads it and checks that it changed since last time; if it holds steady for longer than a timeout, the receiver flags a communication fault. A toggling bit works the same way for a single boolean. At the protocol layer, TCP keepalives and OPC UA session keepalives perform the same function to keep an idle connection detected as live.
Two parameters define a heartbeat: the interval at which it is sent and the timeout after which silence is treated as failure. The timeout is set to a few missed intervals so a single lost message does not trigger a false alarm, while still detecting a real outage quickly. Heartbeats are often paired with a watchdog on the receiving side that takes action - alarming or failing over - when the heartbeat times out.
Across a field of remote wells and tanks connected by cellular or radio, comms outages are routine. A heartbeat from each RTU lets the SCADA distinguish sites that are reporting normally from sites that have gone dark, so operators trust the live picture. A missing heartbeat is what drives a comm-fail alarm and, often, a callout.
Heartbeats also protect against acting on stale data - a real safety concern. An automated response that trusts a pressure reading must know the reading is current; a dead heartbeat should invalidate that data so logic does not make decisions on a value that is no longer being updated. For this reason heartbeats frequently feed data-quality flags as well as alarms.
On redundant links, a lost heartbeat on the primary path is the trigger to fail over to a backup - cellular to satellite, for instance. The heartbeat is the fast, continuous evidence that lets the system switch before an operator would even notice the primary had dropped.
Receiving a value only tells you a message arrived; the value could be stale if the device froze but the last packet is cached. A heartbeat changes every cycle, so a receiver can confirm the data is genuinely fresh and the sender is actively running, not just that some old value is present.
The heartbeat is the periodic signal of life; the watchdog is the timer on the receiving side that waits for it. If the watchdog does not see the heartbeat within its timeout, it takes action - raising an alarm, invalidating data, or failing over.
It depends on how quickly you must detect a failure and how much bandwidth you can spare. Fast-updating local links may heartbeat every second; bandwidth-limited cellular sites may use tens of seconds. The timeout is usually set to two or three missed intervals to avoid false alarms from a single lost message.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.