Heartbeat and watchdog logic form a quiet conversation between control layers. In a warehouse control system (WCS) and programmable logic controller (PLC) integration, these signals rarely carry pallet IDs or zone commands. Instead, they carry something simpler and more urgent: confirmation that the other side is still awake, still executing its program, and still able to exchange data at the expected rate. A heartbeat is a periodic data signal sent from one system to another. A watchdog is the timing mechanism that converts the absence of that signal into a known local action. Together, they enable condition monitoring across conveyor zones, storage and retrieval machines, palletizers, and sortation systems. They do not, by themselves, make equipment safe, but they make unresponsiveness visible. For warehouse operators, maintenance engineers, and controls teams, understanding how these signals behave is the difference between a thirty-second diagnosis and a multi-shift outage.
What Heartbeat and Watchdog Signals Do in a Warehouse Control System #
The primary purpose of a heartbeat signal is to prove liveness, not correctness. When a WCS sends a move request to a PLC, the PLC executes the logic as programmed and reports back. The heartbeat is a separate, low-complexity message that answers a narrower question: Is your application still cycling? The WCS uses that answer to decide whether to keep issuing commands or whether to raise an alarm and stop issuing commands. Likewise, the PLC may monitor a heartbeat from the WCS to determine whether the higher-level system is still supervising the operation.
Watchdog logic extends the heartbeat with a time bound. The receiving side opens a time window when a heartbeat is expected. If the window expires without a valid signal, the watchdog fires. The action that follows is typically defined in the application logic: set a fault flag, pause a zone, stop issuing new commands, or display a diagnostic message. The important detail is that the action is local. The PLC can act even if its connection to the WCS is broken, and the WCS can act even if a single PLC has stopped communicating.
In practical warehouse operations, this arrangement provides:
- Early detection of controller freezes, communication drops, or application restarts.
- A consistent record of when a control layer stopped answering.
- A way to ensure that a conveyor zone does not keep receiving commands from a WCS that is no longer aware of current conditions.
- A boundary for defining which alarms are elevated to operators and which are handled by the system automatically.
Where the Signals Live: PLC, WCS, and the Network Between Them #
Heartbeat and watchdog logic are implemented in different places, and each layer has its own failure modes. On the PLC side, the heartbeat is usually generated by a cyclic task that increments a counter or toggles a status tag. A watchdog timer runs in the PLC firmware or in the application task and monitors the arrival of a supervisor heartbeat. On the WCS side, a poller or a message-handling service tracks the last response time from each PLC. The WCS also maintains an alarm state for each controller, which is used to suppress commands when a controller has gone silent.
The network between them is part of the system, not a passive wire. Most modern integrations use Ethernet-based protocols, such as explicit messaging, OPC UA, or vendor-specific TCP traffic, over a managed control network. Heartbeat traffic shares this network with zone assignments, status updates, and command acknowledgements. Network congestion, switch port errors, or a failing cable can delay a heartbeat long enough to trigger a watchdog even when both the PLC and the WCS are healthy. This is one reason why a heartbeat timeout should always be interpreted as a communication event, not automatically as a controller failure.
There is also a temporal dimension. The PLC runs on scan time, typically measured in milliseconds or tens of milliseconds. The WCS runs on application cycles, message queue depths, and database write times. A WCS that is busy writing large status updates to its database may miss its own heartbeat deadline. A PLC that is in the middle of a long motion sequence may exceed its scan time and delay the heartbeat response. These interactions matter because they make heartbeat timing a reflection of overall system health, not just a signal that is either present or absent.
Two Common Architectures: Polled Heartbeat vs. Cyclic Watchdog #
Polled Heartbeat #
In a polled architecture, the WCS is the active partner. It sends a request to the PLC, and the PLC responds with a heartbeat token, a counter value, or a status word. The WCS measures the round-trip time and updates a last-response timestamp. If the next poll goes unanswered or the response arrives too late, the WCS marks that PLC as offline or degraded. Polling is easy to trace and produces a natural event log: each miss can be timestamped and recorded.
Cyclic Watchdog #
In a cyclic watchdog architecture, the PLC is the active monitor. The PLC expects a periodic signal from the WCS, and the PLC resets its own timer each time the signal arrives. If the timer expires, the PLC sets a local fault bit and applies a preconfigured action, such as holding pallets in their current zones or stopping a conveyor segment drive. This direction is particularly important when the PLC is expected to operate autonomously for a period and then hand control back to the WCS. The cyclic watchdog gives the PLC a way to know that supervision has resumed.
Many warehouse systems use both directions simultaneously. The WCS polls the PLC for a liveness status, and the PLC watches for a supervision signal from the WCS. The two directions rarely use the same timeout. A slower, leeway-tolerant timeout may be used for the WCS-to-PLC direction because the WCS has higher-level scheduling jitter. A tighter timeout may be used for the PLC-to-WCS direction because the PLC needs to act quickly if command flow stops. Documenting these differences is essential. A technician who assumes both timeouts are equal will misread the system behavior.
A hybrid pattern uses a monotonic counter, sometimes called a heartbeat counter or an alive counter. Each side increments the counter when it sends a heartbeat. The receiving side compares the new value to the previous value. If the value has changed, the sender is alive. If the value is the same for several consecutive windows, the sender is stuck. This pattern is more robust than a simple toggling bit because the counter prevents a stuck bit from producing a false liveness indication.
What a Watchdog Actually Detects (and What It Cannot) #
A watchdog detects one thing: the absence of expected data within a defined time window. That is a useful diagnostic fact, but it is easy to over-interpret. A heartbeat presence does not mean the PLC logic is correct, the sensors are clean, or the WCS is executing the right sequence. It only means that the exchange loop is completing. In some failure modes, a PLC can continue sending heartbeats while its application logic is corrupted or a critical output module has stopped responding. The heartbeat tells you that the CPU is running, not that the machine is doing the right thing.
Similarly, a watchdog timeout does not tell you why the signal stopped. The cause could be:
- A PLC application crash or an HMI-triggered restart.
- A WCS service failure or an operating system update on the server.
- A network switch reboot or a damaged cable.
- A scheduled maintenance window that was not reflected in the alarm configuration.
- A programming change that accidentally disabled the heartbeat generation logic.
Watchdog logic also cannot detect faults that produce a normal heartbeat but an abnormal physical response. For example, a conveyor zone may report healthy liveness while a drive overload relay has tripped, because the overload signal is read by the PLC but not included in the heartbeat message. The heartbeat remains silent about the problem. This is why condition monitoring must combine heartbeat signals with device-level status, fault words, and operator observations. The heartbeat is one layer of the diagnostic picture, not the whole picture.
Observable Symptoms and Practical Evidence Collection #
When heartbeat and watchdog logic fail, the symptoms appear as alarms, paused zones, or offline statuses. The challenge is deciding which layer to investigate first. The following table describes common symptoms, the likely signal context, and the evidence to collect before changing any configuration tables.
| Observed Symptom | Likely Signal Context | Evidence to Collect |
|---|---|---|
| WCS shows a PLC as offline while the PLC HMI indicates the program is running | Reply timeout or missed poll from the WCS; the heartbeat response may be delayed or blocked | Timestamped heartbeat misses on the WCS, PLC scan time, CPU load, network switch port counters, recent program download times |
| PLC pauses a zone with a watchdog timeout, but no WCS alarm is present | The cyclic supervision frame stopped arriving before the WCS raised its own liveness error | WCS application log, server CPU and memory usage, message queue depth, database transaction delay, WCS restart timestamps |
| Heartbeat counter resets unexpectedly or drops to zero | The generating application restarted or the communication function block was reinitialized | PLC program change history, WCS service restart logs, power event logs, UPS status, maintenance action records |
| Intermittent heartbeat loss every few hours | Network congestion, switch buffer exhaustion, or time synchronization drift between the PLC and WCS | Packet capture on the control network segment, switch port drop counters, heartbeat interval statistics, time offset between devices |
| Heartbeat is present but machine behavior is stale or commands are ignored | Liveness data is decoupled from control data; the heartbeat path works while the command path is blocked | Tag read and write timestamps, WCS command queue age, PLC logic cross-reference, database write latency |
Evidence collection should be systematic. Record timestamps from both sides using a common time base; a one-second clock difference can transform a normal heartbeat into a false timeout. Capture the data in multiple places at once: the WCS log, the PLC diagnostic buffer, and the network switch counters. Once the evidence is collected, compare the event times. The goal is to identify the first missed signal, not just the alarm that resulted from it.
Common Interpretation Errors in Heartbeat Diagnostics #
Several recurring mistakes lead teams to replace working hardware or change configuration values without resolving the fault. The first is assuming that a WCS offline alarm means the PLC is faulty. In practice, the WCS may have restarted its communication service, the switch port may have dropped, or the server clock may have jumped. The PLC and the WCS should be checked independently before either is declared the root cause.
The second error is adjusting the timeout value first. Increasing a watchdog timeout can hide an intermittent network problem for hours or days. The signal continues to fail, but the alarm no longer appears, so the
