In modern automated warehouses, the boundary between the warehouse control system (WCS) and the programmable logic controller (PLC) is often the first place where performance problems surface. Two of the most discussed constructs at this boundary are mission queues and task queues. A mission queue represents a higher-level intent—something the warehouse wants to happen, such as moving a pallet from a receiving dock to a specific storage aisle. A task queue represents a lower-level executable operation—something the control layer must do now, such as extending a stop, reversing a conveyor, or releasing a carton onto a sorter. When these two queue types are selected, sized, or interpreted incorrectly, the symptoms are frequently indistinguishable from hardware faults: deliveries pause, zones appear blocked, loads vanish from tracking screens, and operators report that “the line just stopped for no reason.” This article explains the selection criteria and application boundaries for mission and task queues, describes how they interact with PLC states and WCS orchestration, and gives maintenance and engineering teams a practical diagnostic path that does not require changing production code.
Mission and Task Queues in the Controls Boundary #
To discuss queues meaningfully, it helps to define what a queue holds and who owns it. A mission queue is a sequence of transport intents. Each mission typically includes a load identifier, an origin, a destination, a priority, and a set of intermediate constraints that may include route choices, required verification points, or handoff zones. The WCS usually owns the mission queue because missions are long-lived and depend on data that exists outside the PLC, such as order information, storage locations, and upstream equipment status.
A task queue is a sequence of executable operations that a PLC can act on without referring back to the WCS for every decision. Task queue entries are short-lived and device-specific: raise a lift, close a gate, run a zone, or release one carrier. The PLC owns the task queue, and the WCS typically replenishes it one step at a time via a defined interface such as a command block, a data structure in the PLC tag database, or a message over Ethernet/IP, Profinet, or a similar industrial protocol.
The key distinction is not the number of entries. It is the scope of a decision. A mission asks, “Where should this load go, and by what path?” A task asks, “What physical action should happen next in this specific zone?” When the two are confused, engineers tend to put global logic into the PLC or expect the WCS to handle microsecond-level releases. Both approaches eventually produce the same failure pattern: queues become stale, loads sit in the wrong place, and the system loses synchronized state.
Defining the Mission and the Task in a Real Flow #
Consider a typical goods-to-person fulfillment area. A WCS mission might be: “Take carton C-4821 from the buffer lane at station 12 to putwall position P-7, using the lower conveyor path, with a priority of 3, and require a scan at merge point M-2.” This mission contains constraints that are not physically present in any single PLC program. The lower conveyor path may traverse four PLC zones, two merges, and one lift. Each PLC only sees its own zones and its own local task queue.
When the WCS dispatches the mission, it breaks the path into a sequence of tasks. Zone 1 receives a task to run, zone 2 receives a task to run after zone 1 confirms occupancy, merge M-2 receives a task to hold or release depending on the priority of an incoming intersect carton, the lift receives a task to move to level 1, and the final putwall zone receives a task to stop and wait for operator confirmation. These tasks are not identical to the mission; they are projections of the mission onto a specific control domain at a specific time.
This layered interpretation has a direct consequence: when the mission queue and the task queue disagree, there is no single source of truth. The WCS believes the carton is at the putwall. The PLC believes the carton left its final zone but has not seen a confirm message. The operator sees an empty position. The diagnostic burden is not to find a broken sensor; it is to reconcile two different representations of the same physical movement.
Selection Criteria for Mission-Based Queues #
Mission queues are the correct choice when the movement decision requires information that does not exist in the PLC. The following criteria point to a mission-oriented design:
- Route selection depends on congestion at a system-wide level. If upstream jams in one aisle should change the path of loads already in the conveyor network, the WCS must hold the route decision until just before the divergence point.
- Load identity must be preserved across multiple equipment domains. A pallet moving from receiving to reserve storage may pass through two different PLC boundaries, a sortation system, and a transfer vehicle. The PLC has no need to know the order number or the SKU, but it does need a stable load token that the WCS can correlate to the mission.
- Cancellation and re-routing occur after a load is already moving. A mission queue supports the concept of “cancel mission,” which means the WCS will evaluate whether the load can stop safely, return to a spur, or continue to a new destination. A task queue only supports “cancel task,” which is nearly useless once the conveyor has already moved the load past a stop.
- Priority changes are frequent and user-driven. Warehouse operators may reprioritize a hot order while the load is in transit. The WCS needs the mission context to decide whether the load should overtake another load at a merge, and the PLC task queue can only implement that decision if the WCS sends a new release command.
- Reporting and audit requirements demand a history of load movement. Mission queues naturally accumulate a history: origin, destination, timestamps, path choice, and completion status. Task queues are intentionally ephemeral and often only expose the current state, not the full path.
Mission queues are also appropriate when the WCS needs to guarantee that a load was delivered to the correct logical location, not merely to the correct physical stop. A mission can carry verification instructions that the task queue does not understand, such as “read the barcode at the fork position and confirm that it matches the mission before the handshake is acknowledged.”
Selection Criteria for Task-Based Queues #
Task queues are the correct choice when the decision is deterministic within a single PLC domain and when response time is measured in milliseconds. The following criteria favor a task-based design:
- The equipment is a fixed, serial conveyor path with no re-routing. If the path geometry is fixed and the only decision is run or stop, the PLC does not need the WCS to tell it how to move a carton through three consecutive zones.
- Speed is critical and network latency is not acceptable. In high-rate sortation or carton accumulation, a PLC task queue enables zones to release based on photo-eye state and neighboring zone state without waiting for a WCS round trip.
- Recovery from a jam is local. If a carton stops at a photo-eye and does not reach the next eye within a timeout, the PLC can issue a pulse, retry once, and then report a fault. The WCS does not need to be involved in the retry, because the physical situation is entirely within the PLC’s own zone.
- Communication loss with the WCS must not stop physical movement. A well-designed task queue allows the PLC to continue processing loads that are already inside its domain, using the last known queue entries. It should not accept new missions from the WCS, but it can machine what is already there.
- The interface specification is short, fixed, and easy to validate. Task queues are easier to unit-test because each entry is a simple command. Mission queues require more complex test scenarios involving route choice, conflicts, and external system states.
Task queues are also preferable when the PLC is expected to act as the final arbiter of safety-related interlocking. Even if the WCS has a mission that says “release carton at merge,” the PLC must verify that the merge conveyor is clear, the downstream zone is ready, and no maintenance lockout is active before executing that task. The task queue should therefore represent commands that are allowed, not commands that are guaranteed to happen.
Application Boundaries: When to Avoid Each Pattern #
Neither queue type is inherently superior. Knowing when to avoid them is as important as knowing when to use them.
A mission-based queue becomes dangerous when the PLC cannot faithfully execute the mission. For example, if the WCS sends a mission that says “the load is a high-priority pharmaceutical carton, so release it at every merge before lower-priority cartons,” the PLC must be able to observe the priority flag at every merge. If the task queue entry only contains a load ID and a destination, the mission intent is lost at the first PLC boundary. The WCS will assume that priority was honored; the PLC never saw it. The result is incorrect sequencing, but no fault code is generated.
A mission queue is also a poor fit when the mission requires deterministic timing. The WCS cannot guarantee that a PLC will complete a move within 3 seconds if the mission queue has 50 pending entries and the WCS is also handling 200 other missions. The WCS should manage intentions, not timing budgets. If a conveyor segment requires a precise release interval, that interval belongs in a PLC task timer.
A task-based queue becomes dangerous when the task queue is used as a substitute for a mission. Some integration teams attempt to encode entire routes as a sequence of tasks: task 1 is “run zone 1,” task 2 is “run zone 2,” task 3 is “drive lift to level 2,” and so on. This approach fails when a downstream zone is jammed, because the PLC cannot re-route the load to an alternative path without receiving new tasks from the WCS. The load sits at the boundary, the task queue drains, and the WCS is left with a mission that is still pending but has no executable next step.
Task queues are also a poor fit when load identity matters across the entire system. If a PLC task queue entry contains only a zone ID and a run command, the result is that no one can answer the question, “Which load is in zone 4?” Identity is essential for returns, recalls, and quality holds. The task queue should never be the only place where load identity is stored.
Hybrid and Layered Queue Architectures #
Most reliable warehouse integrations use both patterns in layers. The WCS maintains a mission queue for each load, or for each batch of loads, and the PLC maintains a short, bounded task queue for each physical domain. The interface between them is a command structure that carries three pieces of information: a unique load token, a verifiable destination within the PLC domain, and a one-way direction or action code.
The WCS feeds the PLC task queue only when the mission reaches a decision point. A decision point is a boundary where the path could change, where a conflict could occur, or where a physical operation must be synchronized with another load. Between decision points, the PLC executes the task queue without WCS involvement. This reduces communication load and ensures the PLC remains responsive during brief network disturbances.
For example, consider an automated storage and retrieval system (AS/RS) boundary. The WCS mission might be “retrieve pallet 12 from depth position 3 in rack row 5 and deliver it to outbound conveyor A.” The PLC task queue for the crane might contain: “move to row 5 depth 3, extract pallet 12, move to output station A, place pallet, confirm.” The WCS does not need to know the crane’s acceleration profile, braking distance, or fork position. It only needs the final confirm signal. The mission is complete only when the PLC sends a completion confirmation that includes the load token and the output station identifier.
The boundary between the two queues must be explicit in the interface description. The WCS should state what it will send, when it will send it, and what it expects in return. The PLC should state what it will accept, how many entries it can buffer, and which error codes it will return. Without this clarity, the integration drifts into one extreme or the other: either the WCS sends too much detail and the PLC becomes a passive relay, or the PLC receives too little and invents mission logic that should reside upstream.
Observable Symptoms and First-Line Diagnostics #
When the queue architecture is misaligned, the symptoms are often intermittent and appear as “ghost” no-fault delays. The table below lists common observable symptoms and the queue-related evidence to collect before replacing any hardware.
| Observable Symptom | Likely Queue Problem | Evidence to Collect | Initial Check |
|---|---|---|---|
| Load appears in two zones in the WCS screen but only one physical zone is occupied | Mission completion was confirmed early, or the PLC task completion was mapped to the wrong mission token | Load event timestamps from the WCS; PLC zone occupancy history; task confirm message content | Compare the load token in the PLC confirm with the token the WCS expects |
| Conveyor output is lower than target, but no fault or jam appears | PLC task queue is empty for seconds at a time, waiting for the WCS to replenish it | Timestamped fill level of the PLC task queue; WCS network round-trip time; PLC last-command timestamp | Log task-queue depth every 500 ms for 10 minutes and look for repeated periods at zero |
| Load arrives at a diverter and waits, then takes the wrong path | A stale mission decision is being sent after the task queue has already moved the load | Time at which the mission route was finalized; time at which the diverter command was sent | Confirm that the WCS only sends the route at the diverter decision point, not earlier |
| Manual cancel in the WCS reports success, but the load continues moving | The cancel only removed the mission queue entry; the PLC task queue still contains the run command | PLC task queue contents before and after cancel; cancel message acknowledgment code | Check whether the interface supports a “cancel and stop” command at the task level |
| All zones upstream of a merge are full, but merge is idle | Merge PLC is holding its task queue clear because the mission priority logic is not supplied in the task entry | Priority value in the task queue entry; WCS merge logic; PLC merge state | Verify that the priority field is transmitted in every task entry, not only in the mission |
The common thread is that the symptom appears at the boundary, not inside any single device. Operators often report the issue as “the line stops for 15 seconds, then runs again.” A continuous run-log showing task-queue depth and mission-queue depth is the fastest way to confirm that the root cause is a queue synchronization problem rather than a mechanical failure.
Evidence Collection for Root-Cause Analysis #
When a queue-related issue is suspected, the goal is to reconstruct a timeline across both the WCS and the PLC. The following evidence should be captured in parallel, not one after the other:
- WCS transaction log entries for the affected load: mission created, route selected, task sent, task confirmed, mission closed.
- PLC tag history for the task queue: queue depth, oldest entry age, oldest entry token, last confirm sent, last fault code.
- Correlation identifiers. Each task entry should carry the mission ID or a unique transport token. If the token cannot be traced across the WCS database and the PLC tag table, the evidence is already compromised.
- Network capture, if available, at the application layer showing the actual message sequence. A network capture is often the only way to determine whether a message was never sent, was sent but lost, or was sent and processed in the wrong order.
- A short video of the physical equipment around the time of the event. In practices where no recording exists, the alternative is operator statements—but operator memory is unreliable for ten-second events.
Once the timeline is built, compare the number of task confirmations the PLC sent with the number of mission completions the WCS recorded. If the PLC sent more confirms than the WCS recorded, the WCS is dropping or aliasing confirmations. If the WCS recorded more completions than the PLC sent, the WCS is completing missions without waiting for the
