In automated warehouse control systems, the distinction between a heartbeat and a watchdog is often blurred in operator discussions, yet the two serve fundamentally different purposes. A heartbeat is an alive signal, a periodic confirmation that a software task or controller is still executing its main cycle. A watchdog is a supervisory mechanism, a timer or external circuit that detects a missing heartbeat and triggers a pre-defined response. Mixing the two, or applying the wrong one to a particular interface, leads to nuisance trips, silent failures, or unintended equipment motion. This article explains how to select heartbeat and watchdog logic for PLC-to-WCS integration, where their boundaries lie, and how to interpret their behavior in a live warehouse environment.
Definitions and Control Intent #
Before placing either logic element in a system, it is useful to define what each mechanism can and cannot prove.
- Heartbeat: A cyclic data value, typically a monotonically increasing counter or toggling bit, written by one device and read by another. Its only proof is liveness: the source is still executing and the communication path is carrying data.
- Watchdog: A timer that expects the heartbeat within a defined window. If the timer expires, it triggers an action such as a fault, a safe stop, or a fallback state. The watchdog is the enforcement mechanism; the heartbeat is the evidence.
A common error is to call the heartbeat itself a watchdog. The heartbeat is passive data. The watchdog is an active decision maker. In a PLC-to-WCS integration, both sides may run heartbeats, and each side may host its own watchdog for the other side. Understanding which side owns which watchdog is essential for troubleshooting.
Selection begins with intent: do you need to prove that the WCS process is alive, that the PLC program is scanning, that a specific conveyor segment is communicating, or that a safety-related function has not been bypassed? The answers lead to different logic structures. A general-purpose liveness check is not a safety-rated function, and it must never be treated as one without explicit site-specific engineering validation.
Operating Context in Warehouse Control #
Typical automated warehouses contain a hierarchical architecture: a WCS on a server, one or more PLCs controlling material handling equipment, remote I/O and drives on field networks, and HMI or SCADA systems for operator visibility. Heartbeats can exist at every boundary:
- WCS to PLC: the WCS sends command messages and expects periodic PLC status back.
- PLC to WCS: the PLC reports machine states and expects the WCS to respond within a window.
- PLC to remote I/O or drives: field devices are supervised by hardware or software watchdogs inside the PLC or drive.
- HMI to PLC: the HMI monitors PLC liveness but normally does not enforce machine stops.
The selection criteria differ at each layer because the failure modes differ. A server process can hang while the operating system remains responsive. A PLC can enter a fault state while the communication card continues to send data. A drive can lose motion control while its status word remains valid. A single heartbeat at the top layer will not detect a failure at the lower layer. For this reason, layered heartbeat and watchdog strategies are more robust than a single application-level ping.
Components interact through message cycles. The WCS sends a command to the PLC, the PLC executes it and returns a status update, and the WCS confirms receipt. The heartbeat runs alongside these messages rather than replacing them. It is possible to have a healthy heartbeat while job data is stale, because command-driven messages may stop for reasons unrelated to liveness. Conversely, command data may continue to flow even when a software thread is degraded, if the heartbeat is generated in a different thread or function block from the one handling commands. This is a critical diagnostic point for warehouse maintenance teams.
Heartbeat Selection Criteria #
Selecting a heartbeat mechanism requires specifying four parameters: content, rate, timeout, and response. Each parameter has engineering trade-offs.
Content and Granularity #
A simple toggling bit is sufficient to prove that a program is cycling. A counter that increments by one per scan provides more information: a jump of several counts reveals a stalled-cycle or a communication interruption. A timestamp, if clocks are synchronized, allows the receiver to calculate data age directly. For PLC-to-WCS interfaces, a counter with a synchronized or relative timestamp is generally preferred because it enables both liveness and freshness monitoring.
Granularity matters. A single heartbeat for an entire PLC program proves that the CPU is running, but not that the material flow logic is running. If a conveyor PLC has separate routines for inbound, outbound, and WCS communication, a single heartbeat will not reveal a stuck subroutine unless the watchdog monitors the execution order. Some PLC platforms allow a sequence-based heartbeat, where each block writes a token to the next block. This is a powerful diagnostic but increases program complexity. For most warehouse applications, a heartbeat generated at the end of the main scan, and another generated inside the WCS command handler, gives a balanced view of controller health and interface health separately.
Rate and Timeout #
The heartbeat interval must be short enough to be useful but long enough to tolerate legitimate jitter. Jitter sources include network congestion, Windows service scheduling on WCS servers, PLC scan time variation, and remote I/O bus retries. A typical PLC-to-WCS heartbeat might run at 500 ms to 1 second, with a timeout of 3 to 5 seconds. A faster heartbeat, such as 100 ms with a 500 ms timeout, is appropriate when the controlled equipment requires fast reaction to WCS loss, such as a merge or a high-speed sorter. A slower heartbeat, such as 2 to 5 seconds with a 15-second timeout, may be acceptable for non-safety monitoring of a warehouse management system integration where the WCS is not controlling motion directly.
The timeout is the decision boundary. It must be shorter than the period in which an undetected failure could cause an unacceptable consequence. For most motion-control interfaces, that means tens of seconds at most. For reporting-only interfaces, minutes may be acceptable. Selecting a universal timeout for all interfaces is rarely correct.
Response Selection #
When the watchdog expires, the response should be classified into one of three categories: observe, degrade, or stop.
- Observe: the system logs the event and continues. Used for non-critical telemetry or diagnostics.
- Degrade: the system completes the current safe action, rejects new commands, and enters a reduced-speed or manual-only mode. Used when a full stop could cause product damage or jam.
- Stop: the system halts affected motion or rejects divert decisions. Used when WCS guidance is required for safe routing, such as a print-and-apply station or a sorter induction.
The response must be implemented in the PLC, not in the WCS, for any stop action. A server-side response cannot stop a PLC if the server has crashed or the network is down. This is a fundamental boundary: the fallback behavior must reside on the side that remains alive, or in a fail-safe hardware chain.
Watchdog Application Boundaries #
Watchdog logic is not appropriate in every communication path. Oversupervision can cause more downtime than the failures it detects. The following boundaries help in selecting where and how to apply a watchdog.
Interface Criticality #
Define the consequence of a stale interface. For a conveyor that can safely stop in place, the consequence is low: a timeout causes a local stop, operators restart after WCS recovery. For a merge where the WCS is assigning carrier IDs, a stale interface can cause two loads to enter the same lane slot. The consequence is a collision, so the watchdog must stop the merge release zone quickly. For a shipping sorter, a stale WCS decision can misroute a parcel, causing a missort but not necessarily a safety event. The timeout and response should match the consequence, not the protocol standard.
Do Not Double-Supervise Redundant Paths #
If the WCS already monitors the PLC through a passive liveness check using standard message traffic, adding a second independent heartbeat can create a race condition. The PLC may be healthy but delayed by a network burst, while the WCS watchdog expires and sends a stop. A single, well-designed heartbeat is clearer than two competing ones. Double supervision is useful only when the two checks monitor different failure domains, such as one for the application logic and one for the communication stack.
Avoid Watchdogs on Pure Data Feeds #
If a WCS sends only reference data, such as routing tables that change every few minutes, a watchdog requiring a 1-second message is meaningless and creates unnecessary load. In such cases, monitor the last data age and log it, but do not automatically stop equipment because the reference data is stale. The equipment can continue operating with the last valid reference set until a command explicitly requires new data. This distinction is often missed by teams that apply a single heartbeat pattern to every tag group.
Safety Boundary #
No software heartbeat or PLC-side watchdog is a substitute for a rated safety system. Light curtains, safety relays, safe torque off circuits, and other protective devices have their own certification and integrity levels. Heartbeat logic can complement safety by detecting a non-safety control failure, but it cannot be used to mitigate a hazard without full site-level engineering review. This article does not provide any instruction for bypassing or modifying safety devices. Site procedures, lockout requirements, OEM documentation, and competent engineering judgment always take priority over any generic guidance.
Component Interactions and Message Flow #
A typical PLC-to-WCS heartbeat sequence works as follows:
- The PLC increments a counter every scan and writes it to a shared data tag or telemetry message.
- The WCS reads the counter. If the value changes on each read, the WCS marks the PLC as alive.
- The WCS independently increments its own counter and writes it to the PLC.
- The PLC scans the WCS counter in its communication routine. If the WCS counter is unchanged for a configured time, the PLC raises a “WCS heartbeat lost” fault and executes the configured degrade or stop response.
In practice, the counters are embedded in a structured datagram with a sequence number, a timestamp, and a command or status field. This allows the receiving side to distinguish between a missed message and a repeated old message. A repeated old message with the same sequence number indicates a network buffer issue or a source-side stall. A missing message with an increasing gap in sequence numbers indicates data loss.
The message flow should include an explicit acknowledgment for command-critical exchanges. Suppose the WCS sends a “release next carton” command to the PLC. A standalone heartbeat proves the PLC is alive, but it does not prove that the command was received or executed. For command-response flows, the PLC should execute the command, update its state, and return a status message containing the command sequence number. The WCS then confirms that its command sequence appeared in the PLC status. If the WCS does not see its command acknowledged, it should either retry or flag the command as failed. This is a command watchdog, distinct from the liveness watchdog. Both are needed on high-integrity material flow interfaces.
Gateways and protocol converters add another layer. If the WCS communicates to the PLC via an OPC-UA server, an MQTT broker, or a custom TCP gateway, the heartbeat may be generated by the gateway rather than by the PLC. This masks a PLC failure behind a healthy gateway heartbeat. To avoid this, the heartbeat that the WCS evaluates should originate from the PLC program itself, and the gateway should pass it through untouched. Similarly, the PLC-side watchdog for the WCS should monitor a value that the WCS application writes, not a value that the network stack automatically responds to. A TCP ping is not a WCS liveness check. A TCP ping only proves that the operating system is alive. This single misinterpretation is the source of many warehouse downtime events where the HMI shows the WCS online while the PLC has not received a valid command for minutes.
Observable Symptoms and Evidence Collection #
When a heartbeat or watchdog event occurs, the first task is to collect evidence from both sides of the interface. The following table lists common symptoms, possible causes, and the evidence to gather.
| Observed Symptom | Possible Cause | Evidence to Collect |
|---|---|---|
| WCS reports PLC heartbeat lost, but PLC HMI shows running. | Gateway counters or tags are not updated by PLC; network path failure; WCS read timeout too short. | WCS log timestamps, PLC scan time, gateway tag live status, network packet capture at both IP endpoints. |
| PLC reports WCS heartbeat lost, and WCS process is healthy. | WCS heartbeat thread stalled or blocked; clock skew between server and PLC; message queue full. | WCS process thread dump, server CPU and memory stats, PLC timestamp of last valid WCS counter, message queue depth. |
| Heartbeat counter jumps by several counts between two reads. | Network delay or buffering of telemetry; PLC scan cycle extended by a heavy routine; WCS polling loop delay. | Set of consecutive counter values with arrival times, PLC scan time log, WCS polling interval configuration. |
| Commands receive no acknowledgment, but heartbeat is healthy. | WCS command handler is receiving data but not updating its output state; PLC command routine is locked in a different state. | Command sequence numbers sent vs acknowledged, PLC state machine state at time of event, WCS application logs. |
| Watchdog trips only during high throughput. | Timeout configured too tight; network congestion under load; WCS CPU saturation during order bursts. | Throughput rate at trip time, retry counts, cycle time of the WCS command loop, network utilization. |
Evidence collection should be a routine procedure, not an ad hoc activity. Configure continuous logging of heartbeat counters, timestamps, and watchdog state changes in the WCS and in the PLC diagnostic log. A 24-hour rolling buffer is often sufficient. When an event occurs, extract the overlapping time window from both logs. The single most valuable piece of evidence is a simultaneous view of the WCS-side read timestamp and the PLC-side write timestamp for the same counter value. This immediately separates a source-side stall from a network or receiver-side problem.
Common Interpretation Errors #
Several recurring errors appear in warehouse control troubleshooting.
- A rising heartbeat counter proves healthy command processing. It does not. The heartbeat may be generated by a separate high-priority task while the command-processing task is blocked. Always monitor the command response sequence independently.
- A watchdog timeout on the PLC means the WCS is offline. It may mean that the WCS heartbeat write is blocked by a full outbound queue, even though the WCS is online and processing other function. Check the WCS application status before declaring a server outage.
- Extending the timeout makes the system more reliable. It does in the narrow sense of reducing false trips, but it widens the window in which a real failure can go unnoticed. The correct solution is to identify and eliminate the jitter source, not to lengthen the timeout until the fault disappears.
- Both sides should use the same timeout. There is no requirement for symmetry. The PLC may need a 5-second timeout to react to a lost WCS during a merge, while the WCS may tolerate a 30-second timeout for a non-critical status feed. Symmetry is convenient but not technically necessary.
- A watchdog event that never occurs means the watchdog is working. In static conditions, a watchdog can be misconfigured in a way that disables itself, such as being reset by a heartbeat that is actually a copy of the previous value. Periodically test watchdog paths by deliberately deactivating the source heartbeat in a supervised maintenance window.
These interpretation errors lead to maintenance teams replacing network cables, restarting servers, or adjusting timeouts when the root cause is a counter reset by an unrelated alarm, or a heartbeat that is being generated by a middleware layer instead of the actual application. Always read the tag definitions from the actual program file, not from memory or historical drawings.
Maintenance Implications and Lifecycle Considerations #
Heartbeat and watchdog logic ages poorly if not documented and tested. Software updates on the WCS can change thread priorities and introduce jitter. PLC firmware updates can alter scan timing. Network switches can have QoS policies that prioritize alarm messages and delay telemetry. Each of these changes can invalidate a previously stable timeout setting.
Maintenance planning should include the following:
- A quarterly review of heartbeat counter deltas over normal operation, to detect increasing jitter before it reaches the timeout threshold.
- A documented list of all watchdog locations with their intended response action. This list should be kept next to the system architecture diagram, not only in the code.
- A standard procedure for changing a timeout, requiring approval and a reason statement. Timeout changes should be treated like safety-related changes even when the logic is not safety-rated, because an overly long timeout can allow a misroute or collision.
- Full-file backup of PLC code and WCS configuration before any change to heartbeat logic. A rollback is not possible if the previous version was not captured with the same tag definitions.
- Operator training that distinguishes between a “WCS communication fault” and a “WCS application fault.” The HMI message text often collapses both into one alarm. Clarify the wording or add a second status field so operators know whether to call IT or the controls technician first.
When a new version of the WCS is deployed, the session timeouts and message update rates often change. The controls team should negotiate the interface timing with the WCS vendor or development team before commissioning, rather than after the first watchdog trip. A pre-commissioning test that simulates a lost heartbeat on both sides is mandatory. During this test, confirm that the PLC enters the expected state and that the WCS reacts in the expected way. The test should also confirm that when the heartbeat returns, the system does not automatically resume motion in an unsafe sequence. Manual reset is often the correct choice for a stop condition caused by a lost WCS, unless the surrounding equipment design explicitly allows automatic restart.
Decision Boundaries and Governance #
Deciding where to place heartbeat and watchdog logic is an engineering governance matter. The controls engineer defines the PLC-side watchdog and the response. The WCS software engineer defines the server-side monitoring and the communication behavior. A clear responsibility matrix prevents gaps.
A useful decision process for any new interface is as follows:
- Determine the worst credible failure within the interface: what is the consequence if one side silently stops?
- Define the maximum acceptable period of silence before that consequence becomes likely.
- Define the response that avoids the consequence within that period.
- Decide which side can execute that response while remaining alive. That side owns the watchdog.
- Choose the heartbeat content and rate that the watchdogs require, and document the jitter budget.
- Design a test case that deliberately removes the heartbeat on each side, and record the observed behavior.
Governance also requires that generic guidance like this article is always subordinate to local standards and site-specific risk assessments. No written article can replace a knowledgeable engineer walking the actual aisle, reading the actual relay logic, and consulting the OEM’s latest documentation. The correct answer for a specific warehouse depends on its equipment layout, its WCS capabilities, its network topology, and the competence of its local maintenance team.
Application boundaries also include the human interface. If an operator can clear a heartbeat fault by pressing reset on the HMI, then the watchdog is weaker than it appears. The reset logic should verify that the heartbeat is actually valid again, or that a manual restart sequence has been completed. A watchdog that accepts a single click as proof of recovery can mask an intermittent failure that will recur on the next cycle.
For high-speed sortation and automated storage and retrieval systems, consider a hardwired continuity signal in addition to the software heartbeat. A relay output from the WCS server or a PLC output that is cycled by a dedicated logic block gives a final hardware-tier indication of liveness. This signal can be wired into the E-stop chain or into a safety-rated input card, but only if the site’s safety validation permits it. The use of a hardwired watchdog is generally reserved for the most critical interfaces, such as conditionally safe zone control or long-load transport, where a software timeout might be too slow or too easily masked.
Documentation should name every heartbeat tag, its data type, its source program block, its destination, its expected cycle time, and its timeout value. It should also note the acceptable jitter range observed during commissioning. This documentation is the difference between a 2-minute diagnosis and a 2-hour dance between two teams each convinced that the other side is down.
Key Takeaways #
- Heartbeat data only proves liveness; watchdog logic enforces a response. Select them separately for each interface.
- Choose
Related Pearl Gateway Guides #
