Warehouse Automation Reference Architecture: ERP, WMS, WES, WCS, PLC and Device Boundaries

Key takeaways #

• Boundary clarity prevents cascading failures: The most reliable warehouse automation designs assign each layer (ERP, WMS, WES, WCS, PLC, device) a single, unambiguous responsibility for command issuance, state ownership, and exception handling. Ambiguity at these boundaries is the leading cause of recirculation loops and sequence recovery failures.
• Command/acknowledgement is a contract, not a message: Every command from WCS to PLC must have a defined acknowledgement path, a timeout window, and a retry policy. Without these three elements, a transient network glitch becomes a system-wide stop. The MQTT 5.0 specification [S2] and OPC UA [S1] provide the transport semantics, but the application-level contract is yours to define.
• State ownership must be singular and explicit: For any given asset (a conveyor zone, a sorter induction point, a crane aisle), exactly one layer must be the authoritative state owner. When WES and WCS both believe they control a sorter’s induction sequence, you get duplicate releases or missed slots.
• Timeouts are engineering parameters, not constants: A timeout value that works for a mini-load crane’s slow, deliberate motion is wrong for a high-speed sliding shoe sorter. Each timeout must be derived from the physical capabilities of the device, the network latency budget, and the safety requirements of the zone.
• Exceptions must have a defined escalation path: The question is not if a PLC will detect a jam or a missed acknowledgement, but when and what happens next. Every exception type needs a defined owner, a recovery procedure, and a fallback state. Sequence recovery logic is a system boundary, not a PLC subroutine.
• Traceability is a cross-layer requirement: The W3C Trace Context [S5] provides a standard for propagating context across services, which is essential when a single carton’s journey spans WES decisions, WCS routing, and PLC motion. Without trace IDs, diagnosing a recirculation issue requires correlating logs from three different systems manually.
• Security is a boundary property: NIST SP 800-82 Rev. 3 [S3] frames OT security as a defense-in-depth problem. In warehouse automation, this means the WES-to-WCS interface is a security boundary, not just a data interface. Authentication and authorization are required at every layer transition.

Architecture scope and objectives #

This reference architecture defines the functional boundaries between the five primary software/hardware layers in a modern automated warehouse: ERP, WMS, WES, WCS, and PLC-controlled devices. The objective is to provide a decision framework for engineers who must specify, integrate, or troubleshoot these systems. The scope includes command flows, state management, acknowledgement semantics, exception handling, and the data models that cross each boundary.

The architecture is deliberately agnostic to specific vendors. It does not prescribe a particular MES (Manufacturing Execution System) or a specific PLC brand. Instead, it defines the contracts that must exist between layers, regardless of implementation. This approach follows the systems engineering principle that interfaces are where complexity concentrates, and therefore where design effort should focus [S4].

For the purposes of this document, the following definitions apply:

• ERP: The enterprise resource planning system. Owns financial transactions, order entry, and high-level inventory targets.
• WMS: The warehouse management system. Owns inventory location, stock keeping units (SKUs), and order allocation to inventory.
• WES: The warehouse execution system. Owns order pooling, wave/order release logic, and the sequencing of work to the automation.
• WCS: The warehouse control system. Owns equipment orchestration, route assignment, and the translation of logical tasks into device commands.
• PLC: The programmable logic controller. Owns safety-rated logic, motion control, and the device-level state machine.
• Device: The physical hardware—conveyor zones, sorters, cranes, transfer cars—that executes the motion.

This document does not cover the internal algorithms of any single layer. It covers the interfaces between layers, because that is where the majority of integration failures occur in practice.

Layer responsibility matrix #

Table 1 defines the ownership boundaries for the five primary functions that must be assigned to exactly one layer. The “Owner” column is the authoritative layer for that function. The “Shared” column indicates where coordination is required but ownership remains singular.

The critical column is “State ownership.” For a conveyor zone, the PLC is the state owner because it has the fastest access to the photo-eyes and the motor contactors. For a sorter’s induction sequence, the WCS is the state owner because it coordinates multiple PLCs. For a wave release, the WES is the state owner because it balances order priorities against equipment capacity. Assigning state ownership to the wrong layer is the root cause of many “ghost” faults where no layer believes it is responsible for recovery.

Command and acknowledgement model #

The command/acknowledgement (CMD/ACK) model is the backbone of the WCS-to-PLC interface. It defines how a logical task from the WES becomes a physical action by a device. The model has four phases: Command, Acceptance, Execution, and Completion.

Phase 1: Command. The WCS sends a command to the PLC. The command must include a unique command ID, a target device or zone ID, a command type (e.g., MOVE, STOP, SORT, LIFT), and any parameters (e.g., destination, speed, acceleration). The command ID is the correlation key for all subsequent messages.

Phase 2: Acceptance. The PLC must respond with an acceptance message within a defined timeout window. Acceptance means the PLC has received the command, validated it against the current state, and queued it for execution. Acceptance does not mean the action has started.

Phase 3: Execution. The PLC executes the command and reports status changes. Status messages are asynchronous and may include intermediate states (e.g., ACCELERATING, AT_SPEED, DECELERATING). The WCS must track these states to update its own view of the system.

Phase 4: Completion. The PLC sends a completion message when the command has finished. Completion must include the command ID, a result code (SUCCESS, FAILED, ABORTED), and any final state information.

Table 2 defines the timeout and retry parameters for each phase. All values in Table 2 are illustrative assumptions and must be derived from the specific network latency, PLC scan time, and device response time for each installation.

The retry logic must be asymmetric. Acceptance retries are safe because the command has not been executed. Execution retries are dangerous because the command may have partially executed. For example, a MOVE command to a conveyor zone may have moved the carton halfway before the PLC lost communication. Re-issuing the MOVE command could cause a collision. Therefore, the illustrative assumption is that execution retries are limited to one, and only for commands that are idempotent (e.g., STOP). For non-idempotent commands, the WCS must escalate to an exception handler rather than retry.

State ownership and transition rules #

State ownership is the answer to the question: “If I want to know the current status of this asset, which system do I ask?” The answer must be unambiguous. Table 3 defines the state ownership for common warehouse automation assets.

State transition rules must be defined for every state pair. For example, a conveyor zone may transition from OCCUPIED to BLOCKED when a photo-eye remains covered for longer than a defined jam timeout. The jam timeout is an illustrative assumption (e.g., 2000 ms) and must be tuned to the specific conveyor speed and carton length. A zone that is BLOCKED may only transition to FAULT (if the jam persists) or to OCCUPIED (if the photo-eye clears). It may not transition directly to EMPTY without a confirmation cycle.

The WCS must maintain a shadow state for every asset it coordinates. The shadow state is the WCS’s belief about the asset’s state, based on the last received PLC status message. The shadow state may differ from the PLC’s actual state during communication outages. The WCS must detect shadow-state divergence and trigger a resynchronization procedure. The resynchronization procedure is a WCS responsibility, not a PLC responsibility, because the WCS has the broader view of the system.

ERP to WMS boundary: order intent and inventory targets #

The ERP-to-WMS boundary is the slowest and most business-oriented interface in the architecture. It carries order intent (what the customer wants) and inventory targets (what the business expects to have on hand). This interface is typically asynchronous and batch-oriented, with message intervals measured in seconds to minutes, not milliseconds.

The ERP sends the WMS a set of order lines. Each order line includes a SKU, a quantity, and a required ship date. The WMS is responsible for allocating inventory to those order lines and creating pick tasks. The WMS must acknowledge receipt of the order lines and report allocation results back to the ERP.

The key boundary rule is that the ERP does not command the automation. The ERP does not say “move carton A to lane B.” It says “fulfill order 12345.” The WMS translates that into inventory allocations, and the WES translates those allocations into release waves. If the ERP attempts to command the automation directly, it bypasses the WMS’s inventory visibility and creates a risk of overselling or misallocating stock.

The ERP-to-WMS interface must include a reconciliation mechanism. Because this interface is batch-oriented, the WMS and ERP can diverge. A common divergence is the “soft allocation” problem: the WMS allocates inventory to an order, but the ERP has already sold that inventory to a different order. The reconciliation mechanism must detect these divergences and escalate them to a human planner. The escalation threshold (e.g., divergence greater than 5% of order value) is an illustrative assumption and must be set based on business tolerance for overselling.

WMS to WES boundary: task allocation and release authorization #

The WMS-to-WES boundary is where inventory becomes work. The WMS creates pick tasks and transfer tasks, and the WES decides when and how to execute them. The WMS owns the what (which SKU, which quantity, which source location), and the WES owns the when (which wave, which sequence, which equipment).

The WMS sends the WES a task list. Each task has a unique task ID, a task type (PICK, PUT, TRANSFER, REPLENISH), a source location, a destination location, and a priority. The WES must acknowledge the task list and report its release plan back to the WMS. The release plan is the WES’s commitment to execute the tasks in a specific order within a specific time window.

The critical boundary rule is that the WMS does not specify the release sequence. The WMS may specify a priority (e.g., URGENT, NORMAL, LOW), but the WES decides the actual sequence based on equipment availability, order pooling, and wave constraints. If the WMS attempts to dictate the sequence, it defeats the WES’s optimization purpose and can cause equipment starvation or overloading.

The WMS-to-WES interface must include a task cancellation mechanism. The WMS may need to cancel a task because of a stock-out, a customer change, or an inventory adjustment. The cancellation must be propagated to the WES, which must then decide whether to abort the task (if it has not started) or let it complete and reverse the result (if it has started). The abort decision is a WES responsibility, because the WES has the equipment context.

WES to WCS boundary: sequencing and route intent #

The WES-to-WCS boundary is the most intellectually demanding interface in the architecture. The WES decides what work to release and in what order. The WCS decides how to route that work through the physical equipment. The boundary is a logical-to-physical translation.

The WES sends the WCS a release message. The release message contains a set of cartons or totes, each with a source location, a destination location, and a required arrival time. The WES does not specify the physical path. The WCS determines the path based on equipment availability, congestion, and maintenance status.

The key boundary rule is that the WES owns the sequence and the WCS owns the route. For example, the WES may release three cartons to the same sorter induction point in a specific order (A, B, C). The WCS decides that carton A takes path 1, carton B takes path 2 (because path 1 is congested), and carton C takes path 1 (because path 2 is now blocked). The WCS must preserve the WES’s sequence at the induction point, even if the paths differ.

This boundary is where recirculation logic lives. If the WCS cannot deliver a carton to its destination because of a downstream blockage, it must decide whether to hold the carton in place, route it to a recirculation loop, or send it to a purge lane. The recirculation decision is a WES-level decision because it affects order completion timing and downstream order pooling. The WCS may suggest recirculation, but the WES must authorize it. This is a Pearl Gateway editorial recommendation based on the principle that systemic decisions belong to the system-level layer. See the recirculation control failure modes article for a detailed analysis of what happens when this boundary is violated.

WCS to PLC boundary: command granularity and safety #

The WCS-to-PLC boundary is the real-time heart of the architecture. It carries device commands, status updates, and fault notifications. This interface must be deterministic, with bounded latency and no unbounded retries.

The WCS sends the PLC a command. The command granularity is a critical design decision. The WCS may send a coarse command (“move carton from zone 10 to zone 20”) or a fine command (“start motor, then stop motor when photo-eye 3 is blocked”). Coarse commands are easier for the WCS to manage but require the PLC to have significant local intelligence. Fine commands give the WCS more control but increase communication overhead and latency.

The Pearl Gateway editorial recommendation is to use coarse commands with PLC-local state machines. The PLC should own the device-level state machine (e.g., ACCELERATING, AT_SPEED, DECELERATING) and report state transitions to the WCS. The WCS should not micromanage motion. This approach reduces communication load and makes the system more resilient to communication glitches, because the PLC can complete a coarse command even if a status message is lost.

Safety is a PLC-only responsibility. The WCS must never issue a command that bypasses a safety interlock. For example, the WCS may command a conveyor zone to run, but the PLC must verify that the zone’s safety gate is closed and the emergency stop is not pressed before energizing the motor. The WCS does not have the safety context and must not be able to override safety decisions. This aligns with the NIST SP 800-82 Rev. 3 guidance that safety and security are separate but coordinated concerns in OT environments [S3].

PLC to device boundary: motion, sensing, and actuation #

The PLC-to-device boundary is the physical layer. The PLC reads sensors (photo-eyes, encoders, limit switches) and drives actuators (motors, solenoids, pneumatic cylinders). This boundary is defined by the electrical and mechanical characteristics of the devices, not by software protocols.

The PLC must implement a device-level state machine for each controlled element. For a conveyor zone, the state machine includes EMPTY, OCCUPIED, BLOCKED, and FAULT states. The transition from OCCUPIED to BLOCKED occurs when a photo-eye remains covered for longer than the jam timeout. The jam timeout is an illustrative assumption (e.g., 2000 ms) and must be tuned to the conveyor speed and carton length. A faster conveyor or a longer carton requires a longer jam timeout.

The PLC must also implement a heartbeat mechanism to detect communication loss with the WCS. If the PLC does not receive a heartbeat from the WCS within a defined interval (e.g., 1000 ms, illustrative assumption), the PLC must decide whether to continue executing the current command or to stop. The safe default is to stop, because the PLC does not know whether the WCS is still coordinating the broader system. However, for some devices (e.g., a mini-load crane in the middle of a move), an immediate stop may be unsafe. The PLC must have a defined “safe stop” procedure for each device type.

The PLC-to-device boundary is where the physical failure modes manifest. For example, a curved conveyor section may have a specific failure mode where the carton jams at the transition between the straight and curved sections. The PLC’s photo-eye placement must be designed to detect this jam. The curved conveyor failure modes article provides diagnostic evidence for these physical failure signatures.

Exception handling and escalation paths #

Exceptions are the normal state of a warehouse automation system. Jams, missed acknowledgements, sensor failures, and communication glitches are expected events, not anomalies. The architecture must define a clear escalation path for each exception type.

The escalation path has three levels:

• Level 1: Device-level recovery. The PLC detects the exception and attempts to recover without involving the WCS. For example, a conveyor zone may retry a motor start three times (illustrative assumption) before declaring a fault. If the retry succeeds, the PLC logs the event and continues.
• Level 2: WCS-level recovery. The PLC escalates to the WCS when device-level recovery fails. The WCS may reroute the carton, change the command, or request a different device. For example, if a sorter divert fails, the WCS may route the carton to a recirculation loop instead of the intended lane.
• Level 3: WES-level recovery. The WCS escalates to the WES when the exception affects the order sequence or requires a systemic decision. For example, if a mini-load crane is down for maintenance, the WES must decide whether to delay the wave, reassign the work to another crane, or split the order.

Every exception type must have a defined owner. The owner is the layer that decides the recovery action. The owner is not necessarily the layer that detects the exception. For example, the PLC detects a jam, but the WCS owns the recovery decision (reroute vs. stop). The WES owns the systemic decision (delay wave vs. reassign work).

Table 4 defines the escalation path for common exception types. All thresholds are illustrative assumptions.

The escalation path must be deterministic. The WES cannot decide to “wait and see” if the WCS has already declared a fault. The WES must have a defined action for every exception type. If no action is defined, the default is to pause the affected wave and notify a human operator. This is a Pearl Gateway editorial recommendation based on the principle that undefined exceptions must default to a safe state.

Sequence recovery and recirculation boundaries #

Sequence recovery is the process of restoring order to a material flow after an exception has disrupted it. Recirculation is the physical mechanism that enables sequence recovery by providing a buffer loop for cartons that cannot proceed to their destination.

The sequence recovery logic is a WES responsibility, not a WCS or PLC responsibility. The WES owns the order sequence and must decide how to restore it after a disruption. The WCS executes the recovery plan by routing cartons through the recirculation loop or holding them in accumulation zones.

The boundary rule is that the WES must have a complete view of the order sequence, including cartons that are in the automation, cartons that are waiting in the WMS, and cartons that have not yet been released. The WCS has a partial view (only cartons in the automation), and the PLC has a device-level view (only cartons in its zone). Only the WES can make a correct sequence recovery decision.

The sequence recovery logic article provides a detailed analysis of the system boundaries for this function. The key principle is that sequence recovery must be planned before the exception occurs. The WES must have a pre-defined recovery procedure for each exception type, including the order in which cartons should be re-released from the recirculation loop.

Recirculation control is a related but distinct function. Recirculation is the physical act of routing a carton through a loop to delay its arrival. The decision to recirculate is a WES decision (because it affects order sequence), but the execution is a WCS function (because it requires route assignment). The recirculation control failure modes article documents the common failure signatures when this boundary is violated, such as cartons looping indefinitely because neither WES nor WCS owns the “when to exit the loop” decision.

Message broker and transport semantics #

The transport layer for the WES-to-WCS and WCS-to-PLC interfaces must be selected based on latency, reliability, and security requirements. Two standards are relevant: MQTT 5.0 [S2] and OPC UA [S1].

MQTT 5.0 is a publish/subscribe protocol that is well-suited for the WES-to-WCS interface, where multiple consumers need to receive the same message (e.g., a release message that both the WCS and a monitoring dashboard need). MQTT 5.0 provides quality of service (QoS) levels, message expiry, and topic aliases [S2]. The QoS levels are:

• QoS 0: At most once delivery. Suitable for status messages where loss is tolerable.
• QoS 1: At least once delivery. Suitable for commands where duplicates are acceptable (idempotent commands).
• QoS 2: Exactly once delivery. Suitable for commands where duplicates are not acceptable (non-idempotent commands).

OPC UA is a client/server and publish/subscribe protocol that is well-suited for the WCS-to-PLC interface, where deterministic data access and information modeling are required. OPC UA provides a rich information model, including data access, alarms, and programs [S1]. The OPC UA information model can represent the device state machine, the command queue, and the alarm list in a standardized way.

The Pearl Gateway editorial recommendation is to use MQTT 5.0 for the WES-to-WCS interface and OPC UA for the WCS-to-PLC interface. This is a pragmatic choice: MQTT is simpler and more flexible for the higher-level coordination, while OPC UA provides the deterministic data access and information modeling needed for device control. However, either protocol can be used for either interface, provided the application-level contracts (CMD/ACK, state ownership, exception escalation) are implemented correctly.

The message broker interfaces article provides inspection points for detecting early warning signs of broker degradation, such as increasing message latency or dropped messages.

Traceability and correlation across layers #

Diagnosing a failure in a warehouse automation system requires correlating events across all layers. A single carton’s journey may involve a WES release decision, a WCS route assignment, and a PLC motion command. If each layer logs events with a different correlation ID, diagnosing a problem requires manual log correlation.

The W3C Trace Context specification [S5] defines a standard for propagating trace context across services. The specification defines two HTTP headers: traceparent and tracestate. The traceparent header carries the trace ID, the parent span ID, and a trace flags field. The tracestate header carries vendor-specific trace data.

While the W3C Trace Context specification is defined for HTTP, the same principle applies to warehouse automation. Each carton should have a trace ID that is propagated from the WES release message to the WCS route assignment to the PLC command. The trace ID enables a query across all layers: “Show me every event for carton TRACE-12345.”

The Pearl Gateway editorial recommendation is to implement a trace ID for every carton or tote. The trace ID should be generated by the WES at release time and propagated through the WCS to the PLC. The PLC should include the trace ID in its status messages and fault logs. This enables a single-query diagnosis of any carton’s journey, from release to completion or exception.

The trace ID is distinct from the command ID. The command ID is unique per command, while the trace ID is unique per carton. A single carton may have multiple commands (MOVE, SORT, LIFT), each with a different command ID but the same trace ID. The trace ID is the correlation key for the carton’s entire journey.

Security boundaries in the automation stack #

Security is a boundary property, not a feature. Each interface between layers is a potential attack surface, and the security controls must be appropriate for the risk. NIST SP 800-82 Rev. 3 provides guidance on securing OT environments, emphasizing defense-in-depth and the unique characteristics of OT systems [S3].

The security boundaries in the warehouse automation stack are:

• ERP-to-WMS: This is an IT-to-OT boundary. The ERP is typically in the enterprise IT network, while the WMS may be in a DMZ or OT network. The interface must be protected by a firewall and application-level authentication.
• WMS-to-WES: This is an OT-to-OT boundary, but it may cross network segments. The interface must use encrypted transport (TLS) and mutual authentication.
• WES-to-WCS: This is the most critical security boundary. The WES makes systemic decisions, and a compromised WES could cause widespread disruption. The interface must use encrypted transport, mutual authentication, and role-based authorization.
• WCS-to-PLC: This is the real-time control boundary. The interface must use encrypted transport where latency permits, and it must enforce strict authorization. The PLC must reject commands from unauthorized sources.
• PLC-to-device: This is the physical boundary. Security is primarily physical (access control to panels and cabinets), but the PLC must also validate sensor inputs for plausibility.

The security controls must not interfere with safety. A security control that adds 100 ms of latency to a safety-critical command is unacceptable. The security architecture must be designed in coordination with the safety architecture, not as an afterthought. This aligns with the NIST SP 800-82 Rev. 3 guidance that OT security must consider safety implications [S3].

Worked example #

This worked example demonstrates the CMD/ACK model and exception escalation for a sliding shoe sorter induction. The example uses illustrative assumptions for all timing values and thresholds.

Scenario: A carton (trace ID: TRACE-1001) is released by the WES to the WCS for induction onto a sliding shoe sorter. The carton must be diverted to lane 7.

Inputs:

• Command type: SORT
• Source: Induction zone 3
• Destination: Lane 7
• Command ID: CMD-5001 (generated by WCS)
• Trace ID: TRACE-1001 (generated by WES)
• Command acceptance timeout (T_ack): 500 ms (illustrative assumption)
• Command execution timeout (T_exec): 5000 ms (illustrative assumption)
• Acceptance retry count (N_ack): 3 (illustrative assumption)
• Execution retry count (N_exec): 1 (illustrative assumption)
• Divert actuation timeout: 500 ms (illustrative assumption)

Intermediate calculations:

1. Command send: WCS sends SORT command (CMD-5001) to PLC at time t=0 ms.
2. Acceptance: PLC receives command, validates that induction zone 3 is ready and lane 7 is available. PLC sends acceptance at t=120 ms. This is within T_ack (500 ms), so no retry is needed.
3. Execution: PLC begins induction sequence. Carton moves from zone 3 to the sorter. At t=800 ms, the carton reaches the divert point for lane 7. The PLC actuates the divert shoe.
4. Divert confirmation: The PLC checks the divert confirmation sensor. The sensor does not confirm within the 500 ms divert actuation timeout. The PLC declares a divert failure at t=1300 ms.
5. Level 1 recovery: The PLC retries the divert actuation once (N_exec = 1). The second actuation also fails. The PLC declares a fault and escalates to the WCS at t=1900 ms.
6. Level 2 recovery: The WCS receives the fault notification. The WCS checks the recirculation loop occupancy (currently 60%, below the 80% threshold). The WCS decides to route TRACE-1001 to the recirculation loop. The WCS sends a new command (CMD-5002) to the PLC: ROUTE_TO_RECIRC. The PLC accepts and executes.
7. Level 3 escalation: The WCS notifies the WES that TRACE-1001 has been recirculated due to a divert failure on lane 7. The WES updates the order sequence and decides to re-attempt the divert after the next carton has been processed. The WES also flags lane 7 for maintenance inspection.

Result: The carton is safely recirculated, the lane 7 divert fault is escalated for maintenance, and the WES has updated the order sequence. The total time from command send to fault escalation is approximately 1900 ms, well within the 5000 ms execution timeout.

Sensitivity analysis: The most sensitive parameter is the divert actuation timeout (500 ms). If this timeout is too short, the PLC will declare false faults when the divert is merely slow. If it is too long, the PLC will not detect a genuine failure quickly, and the carton may collide with the next carton. The sensitivity is approximately linear: a 10% reduction in the timeout (to 450 ms) would increase false fault rate by an estimated 15% (illustrative assumption). A 10% increase (to 550 ms) would increase the collision risk window by 50 ms.

Limitations: This example assumes a single carton and a single fault. In a real system, multiple cartons are in the induction sequence simultaneously, and the WCS must manage the interactions. The example also assumes that the recirculation loop has capacity (60% occupancy). If the loop were at 85% occupancy, the WCS would need to escalate to the WES for a purge decision before routing TRACE-1001 to the loop. The example does not address the root cause of the divert failure, which would require the diagnostic procedures described in the sliding shoe sorter inspection article.

Maintenance and diagnostic boundaries #

Maintenance and diagnostics are cross-cutting functions that interact with all layers. The maintenance function must be able to observe the state of the automation without interfering with its operation. The diagnostic function must be able to isolate faults to a specific layer or device