Heartbeat and watchdog logic forms the connective tissue between programmable logic controllers (PLCs) and warehouse control systems (WCS). In an automated warehouse, the PLC operates equipment in real time — driving conveyors, directing shuttles, and confirming photoelectric presence — while the WCS orchestrates broader workflows, managing order releases, routing decisions, and material flow across zones. A heartbeat is a repeated signal that one system is alive and able to communicate. A watchdog is a monitoring mechanism that acts when the expected beat does not arrive. Together they provide a simple but essential contract: both sides must prove liveness within an agreed time window, and both sides must respond predictably when that proof is missing. This article explains how heartbeat and watchdog logic work in PLC and WCS integration, what symptoms indicate trouble, how to collect useful evidence, and where the boundaries of this logic end. It does not replace site-specific documentation or engineering judgment.
Definitions and Operating Context #
A heartbeat in a warehouse automation context is normally a data exchange element that repeats on a fixed cadence. It may be a counter in a PLC that increments each scan, a timestamp written by a WCS service, or a dedicated message within a larger cyclic telegram. The receiving side compares the time between beats with an expected interval. If the gap exceeds a threshold, a watchdog timer expires. The watchdog then drives a state transition — usually from a normal operating state to a warning or fault state.
Two monitoring directions are common. The WCS monitors the PLC heartbeat to confirm that the controller is executing its program and scanning in a healthy way. Simultaneously, the PLC monitors a WCS heartbeat to confirm that the WCS application, network session, and service threads are alive. Monitoring in only one direction creates blind spots. A PLC can be alive while the WCS is hung, and a WCS can be healthy while the PLC is stopped in an unexpected mode. Bidirectional heartbeat exchange makes partial failures visible to both parties.
The boundary of this mechanism is important to state plainly: a heartbeat proves that a message was produced recently. It does not prove that the message content is valid, that the equipment is mechanically sound, or that the process state matches the commanded state. Those concerns require separate cross-checks such as command acknowledgements, position feedback, and safety interlocks.
Typical Topology in Warehouse Systems #
Most modern warehouse installations use a central WCS server connected over industrial Ethernet to multiple PLCs. Each PLC may control a section of conveyor, a palletizer, a depalletizer, or an automated storage and retrieval machine. The physical network may be structured as a ring, star, or redundant pair of switches, but logically the WCS holds a single communication channel to each PLC.
Within each PLC program, a small routine is dedicated to heartbeat and watchdog monitoring. The routine maintains a timer, inspects an incoming WCS heartbeat tag, and writes an outgoing PLC heartbeat tag. On the WCS side, a similar monitoring service runs as a background thread or an extension of the equipment communication layer. Message flow also includes order commands, status events, and diagnostic telegrams, but the heartbeat is intentionally simple so that it can be isolated from application-level traffic.
Inter-PLC heartbeats are often present in addition to PLC-to-WCS heartbeats. For example, a conveyor handoff section between two PLC zones may require each controller to monitor the other’s liveness before releasing a pallet. These peer watchdogs prevent a downstream stop from being masked by an upstream controller that has lost situational awareness.
Heartbeat Mechanisms and Expected Behavior #
The basic building block is a cyclic counter or timestamp. On the PLC side, the heartbeat tag is typically an unsigned integer that increments every program scan or every fixed time interval such as 100 milliseconds. The WCS reads this tag at a polling interval and records the last received value and its receive time. On the WCS side, a service writes a timestamp or a sequence number to a tag that the PLC polls. Each side compares the current time with the last received beat time.
An important refinement is the use of a sequence counter, separate from a timestamp. A sequence counter allows the receiver to detect duplicate messages caused by network retries, and also detects out-of-order arrival. A timestamp allows the receiver to calculate latency. In higher-level systems, both are carried in the same data structure. The sequence counter is the authoritative proof of progression; the timestamp is useful for diagnostics.
The expected interval is not always equal to the scan time. Many WCS platforms poll PLC registers at 250 ms, 500 ms, or 1 second even if the PLC scans every 20 ms. The watchdog timeout must be larger than the worst-case expected interval, including network jitter, PLC task scheduling, and WCS service scheduling. A typical configuration allows three to five missed beats before declaring a fault. Shorter timeouts reduce reaction time but increase nuisance trips; longer timeouts mask intermittent problems.
Watchdog Logic and State Transitions #
Watchdog logic is best modeled as a small state machine with clearly defined transitions. A normal state means beats are arriving consistently. A warning state may be entered when one or two beats are missed, allowing transient network delays to recover without escalating to a full fault. A fault state is entered when the number of consecutive missed beats exceeds the configured threshold. Fault state usually triggers alarm presentation, movement restrictions, and abort of current WCS commands.
Recovery from a fault is a deliberate action, not an automatic consequence of receiving the next heartbeat. Typical design requires an operator acknowledgement on the HMI or a reset command from the WCS before the system returns to normal operation. This prevents a subtle condition where communication is restored but the equipment state has changed while the system was in fault. A controlled restart sequence should verify that all zones are in known positions, no material is stranded incorrectly, and no operator intervention is pending.
Watchdog logic also interacts with PLC program states. In many warehouse systems, the PLC has operational states such as startup, running, stopped, and faulted. The watchdog monitors the WCS heartbeat only in specific states, usually running mode. During startup, a separate handshake sequence may be used to establish that the WCS is ready before the PLC begins automatic movement. During a planned stop, the WCS heartbeat may be disabled intentionally, and the watchdog must not treat that as a fault. Very often this is handled by a state bit that tells the watchdog whether the WCS is expected to be communicating.
Observable Symptoms and Evidence Collection #
When problems occur, the symptoms at the HMI, the PLC fault screen, and the WCS alarm log often look similar even when the root causes are very different. Observable symptoms include repeated service restarts, zones shown as offline, conveyor sections that refuse to release pallets, and watchdog fault codes that clear after a reboot and then return. The table below shows common symptom categories, likely initial causes, and evidence that should be collected before making changes.
| Symptom | Likely Initial Cause | Evidence to Collect | Initial Check |
|---|---|---|---|
| PLC enters watchdog fault shortly after WCS restart | WCS sends commands before its heartbeat is running | WCS startup log, PLC fault timestamp, heartbeat tag values | Verify WCS service startup order and handshake logic |
| Intermittent missed beats across several zones | Network congestion, switch resource exhaustion, or high WCS CPU load | Packet capture statistics, arrival time deltas, CPU and memory counters on WCS server | Check switch ports for errors, inspect network utilization trends |
| Single zone reports lost heartbeat but network link is up | PLC task blocked, fieldbus scanner stall, or application hang in WCS thread | PLC scan time trend, WCS thread state, telemetry from the specific zone | Verify that PLC program scan is completing; check for I/O bus errors |
| Heartbeat present but no command execution | Communication is healthy; logic or state machine is stalled | WCS command queue depth, PLC station state, last command timestamp | Confirm the immediate control state in the PLC program, not just comms |
| Watchdog fault clears after time sync adjustment | Clock drift between WCS server and PLC | Timestamp values from both sides, time sync configuration | Check whether time sources are configured and reachable |
Evidence collection for heartbeat issues requires millisecond-resolution logs on both the WCS and the PLC. The WCS should log each received beat with a sequence number, source IP, and receive timestamp. The PLC diagnostic history should capture each watchdog reset event with the last received heartbeat value. Correlating these logs is much easier when both sides use a common time reference. If clocks are not synchronized, a timestamp comparison may be misleading and can point to the wrong component.
Common Interpretation Errors #
One of the most frequent misreadings is treating a heartbeat loss as a pure network failure. A heartbeat can stop arriving while the network remains fully operational. The WCS service may be blocked on a database query, a PLC communication card may have lost its cyclic data mapping, or a process thread may be deadlocked. Conversely, a network failure can leave a stale heartbeat value visible in a register. A receiver that reads a tag without checking its fresh timestamp will incorrectly believe the peer is alive. Every heartbeat consumer should verify elapsed time, not just presence of a non-zero value.
Another common error is confusing heartbeat liveness with command execution. A PLC can continue beating while the WCS command queue grows because the PLC is stuck in a misaligned state or waiting on an interlock. The heartbeat proves the program is running, not that the equipment is moving correctly. Separate transaction timestamps and equipment state feedback are required to make that determination.
Timeouts are often adjusted emotionally after an incident. A short timeout applied system-wide to reduce reaction time may create nuisance faults at any zone with even minor network jitter. A long timeout applied to stop nuisance alarms can hide a failing switch or overloaded WCS server. The prudent approach is to collect arrival-time deltas over a few days in normal operation, then set the timeout above the observed maximum by a reasonable margin while still meeting the operational response requirement.
Another subtle error involves restart storms. If a WCS service crashes and restarts repeatedly, each restart may reset the heartbeat tag and cause the PLC to observe a sequence counter that starts over from zero. A well-designed sequence counter check will detect this as an anomaly rather than accepting the reset as normal. In a broader sense, the heartbeat is not an appropriate trigger for automatic system-wide restart. The watchdog should place equipment in a safe state and notify personnel, not assume that rebooting will resolve the condition.
Maintenance Implications and Preventative Checks #
Heartbeat and watchdog logic become part of planned maintenance and troubleshooting routines. Preventative work should include trending the arrival intervals for every monitored peer. A small journal of values showing increasing jitter is often an early indicator of a degrading network, an overloaded controller, or a failing switch port. Historical data should be reviewed before and after any software or firmware change to detect regressions that present as elevated latency.
Regular maintenance events often involve restarting a WCS service, flashing a PLC program, or replacing network switches. These activities disturb heartbeat timing and can cause a fault if the peer watchdog does not account for the planned outage. Site maintenance procedures should specify the order of shutdown and restart, including when to disable the relevant watchdogs if the OEM provides a sanctioned mechanism. Any change to watchdog timing values, heartbeat intervals, or fault recovery behavior must be documented, reviewed by the controls team, and approved through change management. The individuals performing such changes must have access to the OEM documentation and the competence to assess the impact on equipment movement and personnel safety.
Housekeeping also matters. When the time source used by the PLC and WCS drifts or fails, heartbeat timestamps become unreliable and time-based watchdog decisions can fire early or late. Periodic verification of time synchronization is therefore part of heartbeat health. Similarly, unused communication connections, duplicate IP addresses, and misconfigured firewall rules are common sources of intermittent lost beats that appear only under load.
Testing the watchdog mechanism should be part of a deliberate validation plan. A planned test can simulate loss of communication to confirm that the PLC enters the expected fault state and that the WCS clears all active operations for that zone. This test also verifies that the alarm presentation is visible to operators and that the recovery procedure works as documented. Any safety-related consequence of a communication loss is normally handled by the safety controller, not by the application-level heartbeat; this distinction should be part of the test expectations.
System Boundaries and Decision Responsibilities #
The heartbeat and watchdog mechanism has a narrow but essential function: detecting that a counterpart is no longer providing a periodic liveness signal. It does not detect mechanical wear, product jams, misaligned sensors, or unsafe human actions. It does not guarantee data correctness, ordering integrity, or semantic validity. A PLC can send a perfect heartbeat while a downstream conveyor is blocked and the WCS has no knowledge of the blockage until a separate sensor fails to change state. The limits of the mechanism should be understood by everyone who reads alarm screens, so that watchdogs are not treated as an overall equipment health indicator.
Decision responsibilities are clearly distributed. Operators respond to watchdog alarms by following site procedures, verifying equipment state, and acknowledging fault conditions only when it is safe to do so. Maintenance personnel diagnose the root cause using the evidence described earlier, including network tools and log correlation. Controls engineers configure the heartbeat interval, watchdog timeout, and state recovery logic within the limits defined by the OEM. Site supervision and engineering management own the change approval and training requirements. The watchdog cannot make these decisions by itself; it only provides the signal that a decision is needed.
This article offers no instruction for bypassing or disabling safety devices, and none should be attempted. Any work on systems with stored energy or moving parts requires adherence to site lockout procedures, OEM documentation, and applicable regulations. A heartbeat and watchdog mechanism is an application-level diagnostic tool, not a safety function. If a situation arises where the watchdog prevents recovery or appears to block operation, the correct response is to stop, consult the system documentation, and contact competent engineering support, rather than circumventing the monitoring logic.
Key Takeaways #
- A heartbeat is a periodic liveness signal; a watchdog is a timer-based response to a missing or delayed signal. Together they confirm that a peer is communicating, but they do not confirm that the peer is executing commands correctly.
- Bidirectional heartbeat exchange between PLC and WCS is necessary to detect partial failures. Single-direction monitoring leaves one side blind to the other’s hang or restart.
- Use sequence counters and timestamps together. Sequence counters detect duplicate or out-of-order messages; timestamps reveal latency and enable log correlation.
- Watch
Related Pearl Gateway Guides #
