WMS-to-WCS Interfaces: Design Assumptions and Verification Evidence

The Boundary Is a Contract, Not a Connection #

The WMS-to-WCS interface occupies a strange place in a warehouse automation project. It is rarely drawn in enough detail, almost never load-tested at full transaction rate, and frequently blamed for symptoms that originate somewhere else. In operation, this interface is not a cable, a message queue, or a database table. It is a shared set of design assumptions about who is responsible for what, in what order, and on what time scale. When those assumptions are not verified with evidence, the interface begins to look like the cause of every unexplained stall.

This article treats that boundary as a system to be measured. It is written for warehouse operators, maintenance engineers, and controls teams who must decide whether a fault is a WMS logic error, a WCS orchestration error, a PLC state problem, or a physical equipment failure. The emphasis is on verification evidence: the time-stamped messages, PLC state histories, sensor events, and operator reports that together prove which assumption failed. No product specifications, no standards citations, and no warranty arguments are needed to apply the reasoning here.

Who Owns the State at Each Moment? #

A common root cause of interface confusion is that the WMS, WCS, and PLC each maintain a different model of the same physical event. The WMS believes a carton has been assigned to a transfer. The WCS believes the transfer command has been accepted and decomposed into a sequence of equipment steps. The PLC believes it has executed a specific motion sequence and reached a defined state. These three beliefs are only synchronized by the messages crossing the application boundaries, and those messages are sparse. A barcode read, a job complete status, a destination busy flag — these are the evidence threads that hold the models together.

State ownership matters because it defines which system is allowed to declare an outcome. The PLC should be the authority for motion state: whether a carriage is at position X, whether a lift is at the top, whether a conveyor drive is running. The WCS is the authority for assignment state: which load is associated with which task token, which destination was granted, which retry count has been reached. The WMS is the authority for inventory state: whether stock exists, is reserved, or is due to arrive. When a WMS record for a pallet says delivered but the WCS task token shows pending, the disagreement is not a data entry problem. It is a state ownership leak, and it must be traced before any parameter is changed.

Message Flow Across the Three Authorities #

A typical healthy flow looks like this: the WMS releases an order, the WCS receives it, the WCS decomposes it into equipment commands, the PLC executes a state machine and emits a completion event, the WCS maps that completion back to the task token, and the WMS is informed that inventory has moved. Each hop can fail silently. Timeouts are usually defined, but timeouts only prove that a response did not arrive within a given interval. They do not prove why the response did not arrive. An effective verification practice is to record each hop as a separate event with a host name, a timestamp, a message ID, and the state of the sending system at the moment of transmission. Without those four attributes, a log becomes a list of assertions rather than evidence.

Design Assumptions That Leak Into the Field #

Most interface defects are not coding errors in the traditional sense. They are assumptions that were reasonable in a design review and false in the field. Common examples include the following.

• Presence is always unambiguous. The design assumes a photoeye that sees a load is exactly equivalent to the load being within the physical bounds of the transfer station. In practice, a pallet can be skewed, a carton can overhang, or a second load can be backed up into the light curtain zone. The PLC state machine was written for clean transitions, but the physical world is rarely clean.
• One command maps to one destination. The WCS may issue a single move command while the PLC actually performs several sub-moves, such as lift, traverse, descend, and deposit. The WMS expects a single completion, and the WCS may not propagate intermediate PLC states. A status word of “complete” at the PLC level can mean the motion finished, not that the load is physically settled at rest at the final location.
• Retries are harmless. A retry of a failed transfer might move a partially extracted pallet back into a rack immediately after a sensor cleared. The retry makes sense to the WCS because the PLC home state was reached, but the WMS inventory was never updated, and the downstream station is already occupied. Retries must be modeled to include acceptance conditions, not just completion conditions.
• Timeout values cover worst-case mechanical time. Timers written during commissioning often reflect a nominal cycle speed, not the degraded speed of a cold morning, a weak battery, or a drive that has been recently serviced. The interface will generate a fault, but the fault may disappear after the equipment warms up, which leads to a “no fault found” pattern.
• Operator intervention always returns the system to a known state. When an operator clears a jam and presses a local reset, the PLC may reset to a state that the WCS logic did not anticipate. The next WMS transaction then references a task token that was already discarded. This is an assumption about operational behavior, and it fails every time a shift change happens during the intervention.

Symptom Patterns and First Interpretations #

Operators recognize interface faults by pattern before they read any log. The first interpretation is usually the most dangerous because it tends to blame the most recent manual action. Typical patterns include the following.

• Task remains “in progress” while the PLC shows idle or faulted. The first impulse is to reset the WCS task, but the actual condition may be that the PLC never reached the expected termination state because a sensor input was filtered out during a momentary pass.
• Inventory discrepancy at a goods-to-person station. The WMS believes a carton was presented and removed, but the station’s presence detector never cleared. The first interpretation is often that the picker bypassed the interface. An evidence-based review will instead reveal an input filter delay or a dirty reflector.
• Repeated “destination busy” messages at a gravity or powered conveyor merge. The station is visually empty, but the downstream release bit was never cleared because the PLC requires an exit confirmation that no sensor provided. Operators may call this a ghost destination. It is a false occupancy state in the WCS, created by an assumption that all downstream sensors are operating.
• Random transfer faults that self-clear. A fault appears during a pallet exchange, and the next cycle runs cleanly. This is frequently misdiagnosed as a flaky cable or a radio drop when the actual cause is a timeout value that is slightly shorter than the worst-case mechanical cycle after a pallet is skewed.

The common thread is that each symptom can be made to disappear by a manual reset, which destroys the evidence needed to find the root cause. The first interpretation should therefore never be “reset it and watch.” It should be “capture the state before resetting it.”

Evidence Collection Before Any Parameter Change #

Parameters such as PLC timers, WCS retry counts, and WMS acknowledgment windows are easy to change and difficult to change back. Before a single value is modified, the following evidence should be collected at the moment of the symptom.

• Message-level captures from the WMS and WCS side. This includes the exact task ID, the source message type, the destination message type, and the contents of the response that did or did not arrive.
• PLC state history and sequence position. Most PLCs provide a trace buffer or an optional data log. The sequence position, the step timer value, and the states of all relevant inputs and outputs at the moment of the last transition are essential to separate a missed state from a delayed state.
• Sensor and actuator event times. If a photoeye is part of the completion logic, record the number of times it changed state in the last hour, the duration of the last on-state, and whether the change was filtered by the input card or the PLC scan.
• Operator timeline. A written note from the operator is evidence, but a time-stamped record of manual mode entries, local resets, or ES-top resets is more reliable. The difference between them is often the missing variable in the diagnosis.
• Time synchronization check. If the WMS and WCS timestamps differ by more than a few seconds, the ordering of messages cannot be trusted. This should be verified at the beginning of the investigation, not after three days of log analysis.

Collecting this evidence requires a prepared process. Do not wait for the fault to become severe. Set a diagnostic capture trigger in the WCS and PLC before the problem becomes frequent, and define a standard folder structure for the evidence so that the investigation is reproducible.

WMS-to-WCS Interface Diagnostic Table #

The table below is a decision aid for the most common interface failure classes. It presents a symptom, the assumption most likely to have been violated, the first evidence to inspect, and the interpretation error that commonly masks the true cause. The table is not a substitute for a full root cause analysis, but it will narrow the investigation quickly.