Heartbeat and Watchdog Logic: Commissioning and Acceptance Checklist

Heartbeat and watchdog logic is a common but frequently misunderstood layer in warehouse automation controls integration. The PLC, the warehouse control system (WCS), and the material handling equipment form a closed loop in which each side must know, at a given instant, whether the other side is still processing the current machine state. A heartbeat signal is one side’s periodic proof of life; watchdog logic is the receiving side’s rule for what to do when that proof of life fails to arrive within a defined interval. Commissioning is not the moment to discover that the timeout is too short or that the logic monitors the wrong task. This article explains the operating context, the interactions between the software components, the evidence that should be collected during commissioning, and the acceptance decisions that follow.

Operating Context and Design Purpose #

In a warehouse control system, the WCS typically issues discrete commands such as “release product to lane three” or “divert carton to spur two.” The PLC executes those commands at the conveyor level and returns statuses such as “occupied,” “clear,” or “fault.” Both directions of this exchange depend on the peer being alive and actively processing data. A frozen WCS process can continue to hold an open TCP connection while never issuing another command; a hung PLC can continue to power its output modules while never executing another rung of logic. Heartbeat signals close that gap by forcing each side to generate a continuously changing token that cannot be mistaken for idle network traffic.

Watchdog logic, on the other hand, defines the consequence. When a heartbeat is not seen within a configured window, the receiving side must take a defined action: freeze commands, stop a particular zone, raise an alarm, or transition to a controlled stop. The purpose is not to prove that the peer is healthy in every respect; it is to put the system into a known state when health cannot be proven. That distinction matters especially during commissioning, because acceptance tests that only verify the happy path tend to miss the cases where the watchdog does nothing at all.

Component Interactions in a Typical Integration Stack #

The interactions are best understood as three layers that exchange data at different rates. The PLC scans its fieldbus and I/O at the fastest rate, typically in the range of tens of milliseconds. The WCS polls the PLC or receives telegrams at a slower rate, often hundreds of milliseconds to a few seconds. The warehouse management system (WMS) sits above the WCS and operates at an even slower business-logic rate. The heartbeat that matters for machine safety and material flow integrity is the one between the PLC and the WCS, because that is the interface where loss of liveness results in moving equipment acting on stale data.

Two directions of heartbeat exist in most designs. The PLC sends a toggling bit or counter to the WCS to prove that its program is still scanning and that the communication driver is still mapping data. The WCS sends its own toggling value to the PLC to prove that the host application is still running, still connected, and still generating command sequences. In bidirectional designs, each side acts as both sender and receiver, and a failure in either direction produces a controlled response. In unidirectional designs, only one side is being watched, which is acceptable only when the unwatched side has some other mechanism to protect against stale commands.

The interaction is further defined by message sequencing. A heartbeat is often carried inside a cyclic telegram that also contains a sequence counter, a timestamp, or a command reference. When a new telegram arrives, the receiving side checks not only that the heartbeat has changed, but also that the sequence counter has advanced by the expected amount. This catches a subtle failure mode in which a driver keeps sending an old, repeated packet because the application layer has stopped refreshing its output buffer.

Heartbeat and Watchdog Architecture Variants #

Single-Sided vs. Bidirectional Watchdogs #

Some systems only supervise the WCS-to-PLC direction, because the PLC already has its own internal watchdogs and hardware fault relays. That is a valid design decision, but it should be a documented one. If the PLC’s internal watchdog is a hardware feature that checks the CPU’s ability to execute the operating system, it will not necessarily detect a software hang inside the user program. Conversely, if the PLC is running a slow-moving averaging function, the CPU might stay healthy while the application task that processes WCS telegrams is starved. During commissioning, the test cases must be written to match the actual supervision being implemented, not the supervision that the team assumes exists.

Time-Based vs. Scan-Count-Based Heartbeats #

Time-based heartbeats compare the elapsed time since the last received signal against a configured threshold. Scan-count-based heartbeats compare the PLC program scan counter or the WCS cycle counter to the previous value and raise an alarm if there has been no change over several consecutive polls. The two behave differently under load. A time-based watchdog may trip falsely during a brief CPU overload, while a scan-count-based watchdog can miss a slow lag that still produces a new counter value every few seconds. The acceptance tests should document which of the two is implemented, because the evidence required and the tolerance for jitter are completely different.

Commissioning Checkpoints #

The following checkpoints represent the minimum verification steps that a controls team should complete before accepting a heartbeat and watchdog implementation. Each checkpoint should be recorded in the site’s commissioning log with a timestamp, a configuration file revision, and the name of the person performing the test.

• Pre-power static checks. Confirm that the heartbeat tag addresses, data types, and initial values match on both the PLC side and the WCS side. Confirm that the configured timeout values are within the range supported by both applications and that the timeout is consistent with the expected communication latency measured on the actual network.
• Symbol and mapping verification. Verify that the heartbeat signal is mapped to a dedicated tag that is not reused for any other purpose. A common commissioning failure occurs when the heartbeat shares a word with a status value and the status value happens to reset to zero, causing the heartbeat to appear frozen.
• Normal operation observation. Observe the heartbeat for at least ten minutes under normal traffic and under idle traffic. Record the average period and the maximum period between successive heartbeats. The maximum period should be significantly shorter than the configured timeout.
• Timeout induction test. Under controlled conditions and with site approval, stop the heartbeat sender, either by pausing the WCS application or by holding the PLC task, and confirm that the receiver detects the loss within the expected time and takes the expected action. Do not simulate a network cable pull as a substitute for a software pause; the two can produce different failure modes.
• Recovery verification. Resume the heartbeat and confirm that the system either automatically restores normal operation or transitions to a clearly defined restart state, depending on the design specification. Record whether operator intervention was required.
• Reverse direction test. If the watchdog is bidirectional, repeat the induction test in the opposite direction. If the watchdog is unidirectional, document that fact explicitly so that future maintenance does not assume protection that was never implemented.
• Reset and re-arbitration test. Force a condition where the heartbeat is lost and then regained while a command is in progress. Confirm that the machine does not resume motion in an uncontrolled manner before command synchronization is re-established.

Diagnostic Table: Observable Symptoms and Likely Causes #

The table below lists common symptoms observed during commissioning of heartbeat and watchdog logic, along with the likely causes and the evidence that should be collected. It is a general guide for diagnostic thinking, not a substitute for the site’s own troubleshooting documentation.

Evidence Collection and Time Alignment #

The most common source of disputed evidence during acceptance is clock skew between the PLC, the WCS, and the diagnostic PC. A heartbeat that appears to arrive exactly at the timeout boundary on the WCS clock may have arrived early or late on the PLC clock. When possible, collect both the PLC’s received heartbeat counter and the WCS’s transmit counter, and compare sequence numbers rather than absolute timestamps. Sequence numbers are immune to clock skew and provide an unambiguous order of events.

For each watchdog trip event, collect the following four pieces of evidence: the configured timeout value, the actual inter-arrival period between the last two heartbeats, the action taken by the receiving side, and the state of the machine at the time of the action. Without all four, it is impossible to determine whether the trip was a true positive, a false positive caused by a slow scan, or a false negative that was caught by another layer. The commissioning report should present these four values in a tabular form for every induced trip and every unintended trip.

It is also useful to record the heartbeat period distribution over a normal shift as a baseline. If the same timeout trips during a later operational change, the baseline makes it possible to see whether the behavior changed on the sender side or the receiver side. Without a baseline, a one-time diagnosis may be mistaken for a permanent root cause.

Common Interpretation Errors #

Several errors appear repeatedly when teams interpret heartbeat data during commissioning. The first is treating the presence of a heartbeat as proof that the peer is fully functional. A heartbeat only proves that a specific task is cycling; it says nothing about whether that task is reading current inputs, writing correct outputs, or executing the right program step. The acceptance test must verify command execution and status accuracy independently of the heartbeat.

The second error is assuming that a faster heartbeat improves safety. A fast heartbeat consumes more bandwidth, more PLC memory, and more WCS processing time. It can also cause a watchdog to trip during a temporary network burst when a slower period would have been perfectly acceptable. The heartbeat period should be chosen based on the acceptable stale-data window for the specific piece of equipment, not on an arbitrary desire for speed.

The third error is confusing