Interlock management is the discipline of deciding which signals may stop or inhibit a machine movement, where that logic executes, and how its behaviour is observed and maintained over time. In an automated warehouse, an interlock is not simply a boolean condition in a program; it is a contractual boundary between mechanical zones, field devices, the programmable logic controller (PLC), and the warehouse control system (WCS). When that contract is poorly defined, the consequences appear as unexplained stops, damaged product, delayed order flow, or, in the worst case, an unsafe automatic restart. This article provides a practical frame for selecting where interlocks belong, understanding their boundaries, collecting evidence when they misbehave, and avoiding the common interpretation errors that undermine controls governance.
Interlock Management in the Controls Hierarchy #
Warehouse automation typically involves three control layers. The field layer includes sensors, photo-eyes, limit switches, encoders, and actuators. The automation layer is the PLC, which executes deterministic logic at fixed scan times and directly commands motor starters, variable frequency drives (VFDs) and transfer units. The orchestration layer is the WCS, which manages order flow, assigns destinations, issues release permits, and tracks material movement through zones.
Interlock management sits between these layers. A true interlock is a condition that prevents an action from occurring or forces a stop action when a boundary condition is violated. The critical question is not only what the interlock does, but where its authoritative logic lives. In a well-designed system, time-critical and hazardous conditions live in hardware or safety-rated PLC logic, while order-aware release decisions live in the WCS as coordinating logic. Confusing these two roles is the root of most interlock-related incidents.
The selection of an interlock must therefore begin with a simple question: what is the consequence of a late response? If a stopped conveyor can collide with a running conveyor due to a delayed stop, the interlock must respond within a fixed mechanical time budget. If the only consequence is a marginal inefficiency in order release, a slower WCS-mediated decision may be acceptable. The choice is an engineering decision, not a programming preference.
Distinguishing Protection Interlocks from Operational Interlocks #
Interlocks separate naturally into two classes: protection interlocks and operational interlocks. Protection interlocks guard against personal injury or catastrophic equipment damage. Examples include guard door monitoring, emergency stop circuits, light curtains, and torque limits on a drive. These interlocks are safety-related and must be implemented using safety-rated hardware and logic with a known performance level, as defined by the machine builder and the site risk assessment.
Operational interlocks prevent product damage or maintain flow integrity. Examples include a downstream buffer-full zone that stops an upstream conveyor, a pallet-position check at a transfer point, or an infeed-occupied signal that blocks a high-speed induction merge. These interlocks are not safety functions, but they are necessary for reliable automation. They can be implemented in standard PLC logic and coordinated with the WCS.
The boundary between these classes is occasionally misunderstood. A light curtain is a protection interlock and must never be controlled by the WCS. A zone-occupied sensor, however, can inform both PLC-based interlocks and WCS release decisions. When selecting an interlock, the system designer must first classify it, then determine the degree of independence required between the sensing path, the logic path, and the actuator path.
Selection Criteria for Interlock Logic Location #
Selecting where an interlock executes is a matter of required behaviour and available evidence. The following criteria guide that decision in a warehouse context.
Response Time Budget #
Every stop action has a time budget: sensor detection, input filtering, logic scan, output energisation, drive deceleration, and physical stopping distance. The PLC can reliably execute this sequence within tens of milliseconds. The WCS, with its network communication, application scheduling, and database interaction, typically works in hundreds of milliseconds or seconds. If the physical stop distance demands a short budget, the interlock belongs in the PLC. If the consequence is only a delayed release, the WCS can participate in deciding the release but should not be the final stop authority.
Data Dependency #
Some interlocks depend on order data. For example, a merge point may need to know whether two conflicting loads are assigned to the same destination before allowing both to enter. That decision is order-aware and naturally belongs to the WCS. However, the WCS decision should not be the only barrier to collision. A physical zone-occupied interlock should still exist in the PLC to prevent mechanical collision if the WCS logic fails or if the order data is stale.
Fail-Safe Default State #
The default state of an interlock must be predictable. A PLC-based interlock fails to a stopped or inhibited state when power is lost or when a sensor is unhealthy. A WCS-level interlock fails in a less predictable manner; the WCS may not be running, may be unreachable, or may hold old data. The selected location must ensure that the absence of a release command results in a safe or operationally acceptable state. In practice, this means the PLC treats a missing WCS heartbeat as a stop condition, and the WCS cannot override a PLC-initiated stop.
Diagnostics and Visibility #
Interlocks that are buried only in PLC registers are hard to troubleshoot from the control room. However, exposing every PLC interlock to the WCS as a data point does not mean the WCS can resolve it. The better pattern is to have the PLC publish a compact and meaningful interlock status, while the WCS publishes release permits and receives acknowledgements. This gives operators a clear picture without making the WCS the execution engine.
Application Boundaries: Where Interlocks Should Not Live #
Defining application boundaries prevents interlock logic from leaking into layers where it cannot be validated. The following boundaries should be respected during design and maintained during modification.
- Safety-related protection interlocks must not reside in the WCS, in a general-purpose HMI script, or in order execution software. They belong to safety-rated hardware and logic with controlled access.
- Operational interlocks that prevent physical collision should not depend on the WCS being online. The PLC must be able to stop a conveyor or reject a transfer without any communication from the orchestration layer.
- Interlock decisions that require product identity should be implemented as a two-step process: the WCS issues a conditional permit, and the PLC validates the physical condition before executing the move. The WCS permit is a recommendation, not a command to bypass a hardware check.
- Zone boundaries must be physically defined and documented. An interlock zone is not the same as a WCS logical zone; the former is a length of conveyor that one load occupies, while the latter is a software construct for tracking inventory. Overlapping or misaligned boundaries cause phantom occupancy and hidden stop conditions.
- Maintenance modes are a boundary of their own. In manual or maintenance mode, operational interlocks may be partially suppressed only if the PLC maintains protection interlocks and if the suppression is time-limited, logged, and authorised by site procedures. The article does not recommend a specific method; the site, the OEM, and competent engineering judgment must define the acceptable practice.
Component Interactions and Message Flow #
A typical interlock chain begins at a field sensor and ends at an actuator. The PLC input card receives the sensor state, applies filtering and debounce, and exposes the signal to the logic program. The interlock logic combines that signal with related conditions, such as a downstream zone-occupied state or a transfer table home position. The logic then sets a run permissive to a motor starter or drive. The WCS does not sit inside this chain; it observes the PLC-reported zone status and sends release and inhibit commands over a network connection.
In a healthy interaction, the WCS receives a zone status update from the PLC, reconciles it with order tracking, and responds with a release message for the next permitted move. The PLC validates that release against its own interlock conditions and generates the actual output. This design gives a clear separation: the WCS makes order-aware decisions, and the PLC makes physical decisions. The message flow should be designed so that missing messages produce a conservative result. If the PLC does not receive a periodic heartbeat from the WCS, it should treat the connection as unhealthy and stop any operation that requires WCS permission.
Timestamps are a vital part of the message flow. The PLC’s sequence-of-events log records changes to interlock tags with a high-resolution timestamp. The WCS application log records when it sent a release or inhibit command. The two logs should be compared using a common time source, such as a network time protocol server, so that the order of events is unambiguous. Without aligned timestamps, the diagnosis of an interlock incident is speculative.
Observable Symptoms of Interlock Misapplication #
Interlock problems rarely announce themselves as logic errors. They appear as operational symptoms that technicians must trace back to the controls layer.
- Frequent stops at a specific transfer point that clear on the first reset. This often indicates a marginal sensor position or a mismatch between the PLC zone boundary and the WCS tracking boundary.
- Stops that occur after the WCS has already issued a stop command. When a conveyor overshoots beyond a stopping point because the WCS command arrived late, the interlock logic is probably in the wrong layer.
- Motors that restart automatically without operator action after a WCS reboot. This occurs when the PLC treats a WCS reconnect as a fresh release, instead of requiring a deliberate restart.
- Zone states that disagree: the PLC sees a clear zone, the WCS still shows occupied, or the reverse. This is a tracking mismatch, not a sensor failure.
- Interlocks that trip only under high throughput. This suggests a response time budget violation or a communication-timing issue under load.
- An interlock reset that silently re-trips. This usually means the interlock condition had not actually cleared; the HMI reset cleared the latch bit, while the causing condition remained active.
Each symptom points to a particular design flaw: wrong logic location, missing validation, insufficient handshake, or poor sensor integration. The next step is structured evidence collection.
Evidence Collection and Diagnostic Table #
Effective interlock diagnosis relies on correlated evidence from different sources. A structured approach is to capture the PLC sequence of events, the WCS application log, the HMI event log, and the operator’s account of the event. The evidence should cover at least thirty seconds before the first anomalous action and remain active for at least two minutes after the event has settled. The following table summarises common symptoms, the evidence to capture, and how to interpret that evidence without jumping to conclusions.
| Observed Symptom | Evidence to Capture | Interpretation Note |
|---|---|---|
| Late stop or overshoot beyond a transfer point | PLC scan time trace, timestamp of the interlock condition, WCS release command timestamp, VFD deceleration profile | Compare the elapsed time from condition to stop against the designed response budget. If the WCS command arrived after the expected stop, the interlock is likely too dependent on the WCS. |
| Ghost or phantom zone occupancy | Raw photo-eye status, PLC input filter settings, WCS zone state, HMI zone visualisation | Distinguish a momentary sensor dropout from a stale WCS state. A raw sensor pulse with a fast input filter may cause a PLC-only interlock trip, while a continuous sensor signal with a stale WCS state indicates a tracking bug. |
| Automatic restart after a WCS connection loss | PLC heartbeat logic, WCS reconnect timestamp, motor start command in the PLC trace | A healthy design requires an explicit restart after communication loss. If the motor restarted without a deliberate command, the PLC treats connection restoration as permission; this is a boundary violation. |
| Interlock bypass active in manual mode | HMI mode switch position, bypass permit audit trail, PLC mode register | Verify whether the bypass is restricted to authorised maintenance and whether a time limit is applied. The fact that a bypass exists is not itself an error; the absence of control and logging is the error. |
| PLC and WCS zone states disagree | SOE log, PLC tag snapshot, WCS tracking event log | Determine which side changed state last and which side initiated the change. The side that changed last without a corresponding field event is the likely source of the mismatch. |
The table is not a complete diagnostic procedure; it is a starting point for evidence gathering. The goal is to determine whether the interlock performed as designed but was incorrectly selected, or whether the implementation deviated from the design. Do not modify logic until the evidence points clearly to a specific mechanism.
Common Interpretation Errors #
Several recurring interpretation errors lead maintenance teams and controls engineers in the wrong direction.
The first is assuming that a WCS release message means the physical path is clear. The WCS can only report the zone status that the PLC sent to it. If the PLC status was stale or the sensor was blocked by a non-product object, the WCS will happily issue a release that is not physically justified. The release is a permit, not a physical verification.
The second error is interpreting every interlock trip as an equipment failure. A trip may be the system working exactly as designed, for instance, when a downstream conveyor pauses because a carton is skew and covers two zones. Calling this a fault and forcing a reset can create a secondary hazard. Technicians should read the interlock text and the sequence context before declaring a hardware fault.
The third error is confusing an interlock with a jam-recovery hold. Many automated warehouses have a jam-recovery sequence that reverses a conveyor to free a trapped product. The HMI may show a stop condition, but the stop is a deliberate control state, not an interlock trip. Logging it as an interlock event corrupts the downtime analysis and masks the real throughput problem.
The fourth error is relying on tag names that have lost their meaning. When a zone is physically redesigned but the old PLC tag name remains, the interlock may still work on the wrong physical sensor. A periodic review of interlock tag descriptions and their association with field devices is essential to prevent this blind spot.
Finally, there is a dangerous assumption that a higher-level system can override a PLC interlock without engineering review. In an automated warehouse, the WCS may be able to inhibit or permit movement, but it should not be able to bypass a protection interlock or a safety function. Interlock governance must clearly define that any override is a formal change, not a runtime configuration option.
Maintenance Implications and Governance #
Interlocks are active components. They require the same maintenance attention as drives and sensors. A sensor that is aimed incorrectly, a mirror that is covered with dust, or a limit switch that is adjusted to the edge of its actuation range can turn a correctly designed interlock into a source of unplanned downtime. The maintenance plan should include cleaning and verifying the physical edge of every interlock sensor, as well as checking the actuator’s response to a forced condition under controlled and authorised procedures.
Software changes to interlock logic must be governed more strictly than ordinary application changes. Every interlock has a response time, a fail-safe state, and a reset path. Changing any of these three properties can
