Routing decision services determine where a unit load, carton, or tote should go next and when the physical movement authority should be issued. In a modern warehouse, these decisions are shared between the warehouse control system (WCS) and the programmable logic controllers (PLCs) that guard and actuate the conveyor, sorter, and shuttle hardware. The boundary between the two is rarely fixed by a single rule, and it shifts with the topology of the material handling system, the speed of the hardware, the availability of upstream data, and the consequences of a wrong decision. This article discusses the selection criteria that controls engineers and maintenance teams should apply when deciding whether a routing decision belongs in the WCS or in the PLC, and it defines the application boundaries that keep the split safe, observable, and maintainable.
Defining Routing Decision Services in the Controls Hierarchy #
A routing decision service is any coordinated function that maps a physical object to a destination and then converts that destination into a sequence of hardware actions. The service includes destination selection, route validation, zone release, divert activation, and confirmation handling. The WCS normally handles the business-facing portion of the decision, such as order allocation or storage location selection. The PLC normally handles the equipment-facing portion, such as whether a specific divert is clear and whether a zone can be released without collision. The lines between these portions are not arbitrary, but they are also not universal.
Where Routing Decisions Live #
The WCS is typically the system of record for the identity of the load, its intended destination, and the business rules that influence the choice. The PLC is typically the system of record for the current state of the hardware: which zone is occupied, which photocell is blocked, which motor is running, and which divert is in position. A routing decision that requires a complete and current view of the hardware is best made at the PLC level. A routing decision that requires knowledge of orders, inventory, or dock door availability is best made at the WCS level. The difficult cases arise when the same physical decision appears to require both views at the same time.
The Decision Boundary Between PLC and WCS #
The decision boundary is the set of rules that define who has the authority to issue a movement command for a specific load at a specific time. A well-designed boundary is explicit and auditable. It should be possible to look at a message trace and determine whether a load moved because the WCS issued a destination change, because the PLC executed a stored routing table, or because the PLC defaulted to a safe position after the WCS timed out. If the boundary is not explicit, operators are forced to interpret ambiguous behavior under pressure, which is exactly when misdiagnosis occurs.
Selection Criteria for Routing Decision Placement #
When deciding whether a routing decision belongs in the WCS or in the PLC, the controls team should evaluate at least four criteria: determinism, data completeness, failure domain, and maintenance cadence.
Determinism and Time Criticality #
Determinism is the ability to guarantee that the same input produces the same output within a bounded time. PLCs are engineered for deterministic behavior on a scan cycle basis. WCS platforms are engineered for data throughput and business logic flexibility, but they are not deterministic in the same sense as a PLC. If a divert actuator must be fired within a time window that is shorter than the WCS round-trip time, the decision to fire the divert must be made in the PLC. This does not mean the PLC should decide the destination. It means the PLC should be allowed to act on a pre-approved destination when the physical trigger condition occurs. The WCS approves the destination; the PLC owns the trigger.
Data Completeness and Context #
Some routing decisions require data that the PLC cannot access without a significant integration effort. For example, a tote destined for a pick station may need to be diverted based on the order closure status that lives in an upstream host system. The PLC would need to replicate that data, keep it synchronized, and handle the conflicts. In most cases, the WCS is the better owner for decisions that use business context. Conversely, a decision to re-circulate a load because the next zone is occupied is a decision that the PLC can make with data it already possesses. The PLC should not have to ask the WCS for permission to avoid a collision.
Failure Domain and Degradation Strategy #
Every routing decision has a failure mode. If the WCS fails, loads at high-speed merges may need to be stopped or routed to a default spur. If the PLC fails, the WCS cannot force a mechanical action to occur. The system designer should place the decision where the failure can be contained with the least disruption to the overall operation. For example, a sorter induction decision may default to a recirculation loop if the WCS is unreachable. That default should be implemented in the PLC as a safe termination condition, not in the WCS as a deferred call that may never arrive. The failure domain of a PLC-based default is limited to the conveyor segment; the failure domain of a WCS-based decision is the entire system that depends on the WCS being alive.
Component Interactions and Message Flow #
Once the decision boundary is selected, the interaction pattern between the WCS and the PLC must be defined. Common interaction patterns are the assignment message, the request/confirm handshake, and the unsolicited status report.
PLC-to-WCS Handshake Patterns #
The assignment message is the most common pattern for routing decisions that live in the WCS. The WCS sends a message that identifies the load and its assigned destination. The PLC acknowledges the message and begins to execute the routing behavior. The request/confirm handshake is used when the PLC requires a destination decision after the load has been physically identified. The PLC sends a request, the WCS responds with a destination, and the PLC confirms execution. The unsolicited status report is a continuous stream of zone states, load positions, and divert commands that the PLC sends to the WCS for tracking and audit purposes.
The boundary condition appears when a handshake times out. The PLC must have a defined behavior for a missing response. That behavior must be deterministic and must be communicated to the WCS in a way that does not leave the system in an ambiguous state. The PLC behavior is not a bypass of the WCS; it is a defined fallback that preserves hardware safety while the WCS recovers.
Carrier, Destination and Route State Machines #
Each physical load in the system should have a state machine that tracks its current location, its assigned destination, and the validation status of the path to that destination. The PLC typically owns the location state machine because it has the sensor inputs. The WCS typically owns the destination state machine because it has the business data. The route state machine is the layer where the decision boundary is most visible. The route is the sequence of conveyors, diverts, merges, and lifts between the load’s current location and its destination. Validating that route requires both hardware status and destination data. A robust system will allow the PLC to validate the next single move while the WCS validates the entire route.
Observable Symptoms of Misapplied Routing Decisions #
When routing decisions are placed at the wrong level, the symptoms are often misread as hardware failures or network issues. The following patterns are common.
Symptoms that Point to WCS Overload #
If routing decisions are placed in the WCS when they require high-frequency sensor inputs, the system will show latency under load. Photocells will be reported as “blocked too long,” diverts will miss windows, and loads will be recirculated for no apparent reason. The WCS may show a backlog of assignment messages, and the PLC will report late receipts. The typical interpretation error is to blame the network or the PLC scan time. In fact, the decision is too slow because it requires a round-trip to the WCS for every single zone release. The fix is not to make the WCS faster; the fix is to move the zone-level release decision to the PLC.
Symptoms that Point to PLC Overreach #
If the PLC is programmed to make decisions that require business data it does not have, the symptom is usually a load routed to a default destination that is no longer correct. For example, a PLC may be programmed to divert every tote to a certain lane because that lane is free, while the WCS knows that the lane is reserved for high-priority orders. The symptom is a WCS that consistently corrects PLC decisions, or a set of loads that arrive at the wrong station. The interpretation error is to blame the WCS for “overriding” the PLC. In fact, the PLC was given a decision outside its data domain. The fix is to redefine the PLC decision to only use the data it can verify, and to route loads to a neutral buffer when business context is needed.
Evidence Collection and Diagnostics #
When a routing issue occurs, the evidence collection process should follow a structured path. The table below summarizes common symptoms, likely decision locations, evidence to capture, and the first diagnostic filter.
| Symptom | Likely Decision Location | Evidence to Capture | First Diagnostic Filter |
|---|---|---|---|
| Divert fires one cycle late under high throughput | WCS assignment latency | Timestamp of WCS assignment send vs. PLC assignment receive; PLC scan period | Check if the WCS message queue depth grows when throughput increases. |
| Load recirculates at a merge despite empty downstream zone | PLC zone release logic | Zone state log, merge request status, release command timestamp | Check if the PLC release permission uses a stale WCS destination flag. |
| Load sent to default spur but WCS had a valid destination | PLC fallback timer | Request time, response time, fallback activation timestamp in PLC | Check if the fallback timer is shorter than the measured WCS round-trip. |
| WCS shows load at wrong station but PLC shows correct position | WCS tracking update race condition | Last known position message, load ID, station read event | Check if the WCS updates tracking on the assignment message or on the confirmation. |
| Two loads released into the same zone at the same scan | PLC routing table overlap | Zone release timestamps, PLC task order, interlock check order | Check if the PLC evaluates a divert and a straight-through release in the same scan. |
Message Timestamp Reconciliation #
The single most useful diagnostic step is timestamp reconciliation. The WCS and PLC clocks are rarely synchronized to the same source. A timestamp from the WCS and a timestamp from the PLC cannot be compared directly unless the clock offset and drift are known. The controls team should establish a routine procedure for recording the time offset between the WCS and PLC, either by a time-sync protocol or by a manual mark-and-compare event. Without this reconciliation, a message that appears to have taken 400 milliseconds may actually have taken 40 milliseconds, and the diagnosis will be completely wrong.
State Change Logs vs. Decision Logs #
A state change log records what happened: zone occupied, zone cleared, divert fired, load arrived. A decision log records why it happened: destination assigned, route validated, fallback triggered. Both are necessary. A system that only logs state changes will show the effect but not the cause. A system that only logs decisions will show intent but not the physical result. The controls team should verify that both logs exist and that they can be correlated by a common identifier, such as a load ID or a zone ID and a timestamp window.
Common Interpretation Errors #
The most dangerous interpretation error is treating every unexpected routing event as a hardware failure. A load that goes to the wrong spur may have a faulty divert, or it may have received a valid destination that was overwritten by a late WCS message. The evidence must be examined before the mechanical maintenance team is dispatched. Conversely, treating every event as a software error can cause repeated repairs of logic that is actually correct, while a worn sensor goes unnoticed.
Another common error is assuming that the WCS is always the authority. In some operations, the WCS is configured to accept PLC-reported positions without question. When a PLC tracking error occurs due to a missed sensor pulse, the WCS will confidently display the wrong location, and the routing decision will be based on that wrong location. The operator sees a perfectly consistent WCS screen and concludes the hardware is fine. The correct interpretation is that the WCS cannot self-heal a missing sensor event; the PLC must detect the discrepancy and report a tracking fault.
A third error is to assume that faster decision engines always improve routing. A faster WCS that sends a destination for every tote at a merge may overload the PLC message buffer, which leads to dropped messages and timeouts. The decision is not only about speed; it is about message frequency, buffering capacity, and the failure behavior of the interface. A slower decision that arrives once for a batch of loads is often more robust than a faster decision that arrives for every individual load.
Maintenance Implications and Controls Governance #
Routing decision services are not static. Business rules change, conveyor zones are added or removed, and PLC firmware is upgraded. The maintenance team must understand the decision boundary to perform effective preventive and corrective work.
Change Control for Decision Tables #
PLCs often hold routing decision tables for divert assignments and fallback destinations. These tables are part of the safety and material flow logic. Any change to these tables should go through the same change control process as a safety-related program change, even if the table itself is not a safety function. The reason is that a small change to a divert table can cause a load to be routed to a location that is occupied, which can create a collision and damage goods or equipment. The controls team should document the table version, the date of change, the reason for the change, and the results of the functional test.
Commissioning and Regression Testing #
When the decision boundary is first defined, or when it is subsequently changed, commissioning must include a test of both the normal path and the degraded path. The normal path test verifies that a load with a valid WCS destination reaches the correct station. The degraded path test verifies that a load with an unreachable WCS is held, recirculated, or routed to a safe buffer according to the defined fallback. Both tests should be repeated at low, medium, and high throughput. A fallback that works at 50 loads per minute may fail at 150 loads per minute if the PLC buffer fills up while the WCS is offline. Documenting these tests is part of controls governance and should be maintained for the life of the system.
Decision Boundaries in Normal and Abnormal Operation #
During normal operation, the decision boundary should be quiet. The WCS and PLC communicate smoothly, and neither system is forced to overstep its data domain. During abnormal operation, the boundary is where the stress appears. The controls team should know in advance the answers to the following questions. If the WCS goes offline, how many loads can the PLC buffer at each merge before a backup occurs? If a PLC goes offline, how does the WCS react to loads that are stranded in the PLC zone? If the network is down but the PLC is running, does the PLC finish a partial route? Is that acceptable?
The boundary should also be defined for partial degradation. A WCS that is slow but not offline is more difficult to handle than a WCS that is completely down. The PLC must be able to distinguish a late response from a missing response. A late response can be accepted if the load has not yet reached the decision point. A missing response must trigger the fallback behavior. The decision to wait, versus the decision to fall back, is a critical control that should be configured and tested with the operations team, not left to the PLC programmer’s discretion.
Site procedures, lockout requirements, OEM documentation, and competent engineering judgment take priority over any generalized guidance. The decision boundary described here is a framework for discussion, not a replacement for the specific validations required at any particular site. No routing decision service should be reconfigured without following the site’s authorized change management and safety procedures.
Key Takeaways #
- Routing decision services are split between the WCS and PLC; the split must be explicit, deterministic, and documented, so that operators and technicians can identify which system owns each decision.
- PLCs should own time-critical decisions and decisions that rely on local hardware state, while the WCS should own decisions that rely on business context, order data, and inventory state.
- The failure domain of every routing decision must be defined before commissioning: what happens to a load if the WCS is down, slow, or returning contradictory data.
- Timestamp reconciliation between the WCS and PLC is an essential diagnostic tool; without it, latency and ordering issues cannot be correctly diagnosed.
- Evidence collection should include both state change logs and decision logs, correlated by load ID and a bounded time window, to distinguish hardware failures from routing logic errors.
- Common interpretation errors include blaming hardware for message latency, trusting the WCS without validating PLC sensor data, and assuming that faster decision engines are always more reliable.
- Maintenance of routing decision services must follow change control for PLC decision tables, with regression testing at multiple throughput levels including degraded modes.
- Site procedures, lockout requirements, OEM documentation, and competent engineering judgment always take priority over general guidance; no safety device should ever be bypassed.
