Queue Fundamentals: Mission versus Task #
In every automated warehouse, the distinction between a mission and a task determines how failures are understood and resolved. A mission is a logical, business-level request: move pallet A from buffer lane 12 to outbound door 3. A task is the equipment-level execution that implements a step of that request: run conveyor 12 forward for four seconds, stop when photoeye 12B is blocked. Mission queues live in the WCS or MES layer. Task queues live in the PLC, or in dedicated device controllers. The same word is used in both layers, which is why queue troubleshooting often starts in the wrong place.
Missions can span many tasks, and a single task can be shared by multiple missions. For example, a transfer car serving several conveyors may execute tasks associated with different pallets and different missions. Understanding this mapping is not an academic exercise; it is the basis for deciding whether a stuck queue is caused by the WCS, the PLC, a field device, or a mismatch that only exists at the interface.
Operating Context and System Boundaries #
A typical modern warehouse deploys PLCs to control conveyors, cranes, shuttles, palletizers, and robotic arms. A WCS provides orchestration above these controllers, while an MES or ERP sits above the WCS. Communication commonly uses OPC UA, EtherNet/IP, Modbus TCP, or vendor-specific protocols. Each link introduces a potential queue boundary.
The responsibility split is straightforward in theory: the WCS decides what should be done, and the PLC decides how to do it. In practice, the split is never clean. The PLC often accepts missions, reports task eligibility, tracks destinations, and handles exceptions. The WCS sometimes evaluates device states that the PLC also monitors. When both systems maintain complementary copies of queue state, the health of the system depends on the discipline of the handshake.
Queue health is especially sensitive to three things: timeouts, sequence numbers, and status mapping. If the WCS sends a task ID and the PLC expects a mission ID, no state will advance. If the WCS waits for an acknowledgment that the PLC only sends once, a single missed packet leaves the queue frozen. If the PLC maps a field fault to the wrong status word, the WCS may believe the device is busy when it is actually faulted. These are not design flaws; they are consequences of having two intelligent systems with different internal models of the same physical world.
The Queue Lifecycle and State Transitions #
Most mission and task queues follow a common lifecycle. The states may be named differently at each layer, but the underlying logic is consistent.
- Queued – the request is stored and waiting for system capacity.
- Dispatched – a controller has accepted responsibility for execution.
- Acknowledged – the receiving controller confirms the request and takes ownership.
- In Progress – the equipment is physically executing the move.
- Completed – the move is finished and the final state is confirmed.
- Failed – an exception occurred and the request cannot be completed.
- Aborted – an operator or external system terminated the request.
The critical observation is that the mission queue and the task queue are mirroring the same logical state from two different perspectives. The WCS considers a mission complete only when the task queue reports a completion. The PLC considers a task complete only when its internal state machine has reached the final state. Drift occurs when the two mirrors disagree: the PLC completes a task but the WCS does not receive the message, or the WCS aborts a mission but the PLC continues to execute the task.
Every queue interface implements some kind of handshake. Explicit handshakes use dedicated command and acknowledgment messages. Implicit handshakes use status bits, controller tags, or register maps. Heartbeat and watchdog timers also operate inside queues. They ensure that both sides know the other side is alive. Early warning signs often appear at the heartbeat level before they affect visible throughput.
Inspection Points and Early Warning Signs #
Inspecting queue health means examining three areas: the PLC state machine, the WCS message flow, and the agreement between logical state and physical field state. Each area produces characteristic early warning signs.
Inspection Point: PLC State Machine #
At the PLC level, inspection starts with the current state and commanded state of every task. In a well-formed PLC, each task has an enum or integer state variable, a command variable, and a status word. Compare the state variable against the command variable. A healthy task advances through states in a defined order. A task that re-enters an error state repeatedly, or that stays in an intermediate state for longer than the cycle time of all dependent operations, is an early warning.
Sequence counters deserve special attention. Many PLC task interfaces use a monotonically increasing counter that the WCS sends with every command. If the PLC expects an increment and receives the same value twice, it may ignore the second command. If the PLC increments its own counter and the WCS does not track it, the WCS can misinterpret an old response as new. An early warning sign is a counter that increases while the task state does not change.
Inspection Point: WCS Message Flow #
On the WCS side, inspect the outbound command queue and the inbound status queue. The length of the unacknowledged message queue is the most direct indicator. A short transient backlog is normal. A queue that grows at shift start and never decreases indicates that the PLC is not consuming messages or the acknowledgment path is broken.
Watch for duplicate messages. Some real-time systems intentionally retransmit commands when an acknowledgment is missed. One duplicate message per retry is expected. A pattern of repeated duplicates over seconds or minutes suggests that the WCS retry timer is too short, or that the PLC is already processing the command and cannot respond while executing. Sequence gaps on the status side are perhaps the strongest early warning: a missing status sequence number means the WCS has lost track of the PLC state and every future interpretation is uncertain.
Inspection Point: Field Device Reconciliation #
The most deceptive queue failures leave both the WCS and the PLC in a logically consistent state while the physical device disagrees. Reconcile the logical condition against field sensors, drive status, and load presence. For example, the PLC may report a conveyor cell as clear because the sensor is temporarily blocked by dust, or as occupied because the sensor was never reset after a manual intervention.
Early warning signs in this area include a device that reports ready but the field sensor indicates a load present, or a device that reports busy while the physical cell is empty. Another common sign is when the WCS shows a task in progress for a device whose main drive is not drawing current. A quick review of drive speed feedback, photoeye states, and diverter positions often explains why the task queue is not advancing.
Observable Symptoms of Queue Degradation #
Queue problems rarely announce themselves as a complete failure. Most begin as subtle performance degradation. Operators and technicians should recognize the following symptoms:
- Mission queue length grows while the task queue is idle.
- A task is acknowledged but never transitions to in progress.
- A task is completed but the mission remains active.
- Repeated brief failures occur without a permanent fault code.
- The PLC cyclically resends the same status message; the WCS cyclically resends the same command.
- Equipment idles while the WCS screen shows activity and the PLC screen shows no commands.
- Queue depth increases during shift change and never returns to baseline.
Each symptom points to a different layer. The diagnostic table below links symptoms to the evidence that should be collected.
Evidence Collection and Diagnostics #
Effective diagnosis requires evidence from both the WCS and the PLC at the same moment. Collecting only one side almost always leads to misguided conclusions. Use the table as a starting point for structured data collection.
| Symptom | Queue Area | Evidence to Record | Next Diagnostic Step | Example Normal Value |
|---|---|---|---|---|
| Mission backlog grows; tasks idle | Mission dispatch logic | Message log timestamps, current mission count, task completion rate | Determine whether new missions are being dispatched at all | Backlog under 20 at steady state |
| Task acknowledged but never starts | Task state machine | PLC task state register, acknowledge bit, start command edge | Verify start command is held or repeated as expected | Ack within 100–500 ms; start follows ack |
| Duplicate commands from WCS | Message retry layer | Sequence numbers, resend counters, retry timestamps | Check retry logic and duplicate suppression in both systems | No duplicate within 5 seconds |
| Phantom task completion | Status mapping | Completion code, destination sensor state, PLC status word | Verify sensor alignment and PLC edge detection | Completion code consistent with actual load position |
| WCS/PLC status drift | Handshake shadows | Mirror register values on both sides simultaneously | Compare WCS shadow table with PLC state table | All mirrored values match |
| Repeated short faults | Field device interaction | Fault code history, drive current, sensor transitions | Check for marginal sensor or intermittent drive fault | No repeated fault without state change |
When collecting evidence, synchronize clocks between systems before relying on timestamps. Record at least five minutes of data around the anomaly. Capture a full snapshot of queue state, not just the single stuck record. If the failure is intermittent, leave a continuous logger running on both the WCS and the PLC rather than depending on manual snapshots.
Common Interpretation Errors #
Several interpretation errors recur across warehouse automation sites. The first is mistaking a mission-level backlog for a PLC fault. A growing mission queue does not mean the PLC has failed; it often means the PLC is waiting for a field acknowledgement or a downstream slot. Always check the task queue before touching the mission queue.
The second error is treating every duplicate message as a retry failure. Some interfaces are designed with a degree of redundancy. An occasional duplicate from a health check or a cyclic broadcast is expected. Duplicates become meaningful only when they appear alongside other symptoms, such as missed acknowledgments or incomplete tasks.
The third error is assuming the PLC state is authoritative over the field. The PLC reports what it believes is true, not necessarily what is true. A PLC can report a task complete even when the load has not reached the sensor, if the sensor is bypassed or the logic is edge-triggered on a signal that never changed. The field must always be reconciled with the logical state.
A fourth error is diagnosing a task queue while ignoring mission dependencies. A task may wait forever because the mission it belongs to has been cancelled, but the cancellation was not propagated. The task looks stuck when it is actually orphaned. Finally, resetting queues without first capturing sequence counters destroys the evidence needed to identify the root cause. Always record counters and logs before performing any queue reset.
Maintenance Implications #
Routine maintenance of queue health is principally a monitoring activity, not a repair activity. Define a baseline for queue depth, acknowledgment time, and retry rate at each interface. At shift change, check that the queue depth returns to baseline after the initial burst of activity. A deviation that persists for more than one shift is a warning sign, not a random event.
Support the ability to drain queues gracefully. Where the system design allows it, use a controlled drain mode that stops new missions but lets existing tasks finish. This is preferable to aborting all tasks during an investigation, because an abort leaves the field device in an unknown physical state. A queue clear is a control action with physical consequences. Never clear a stuck queue until the corresponding device has been physically inspected and confirmed safe.
Log retention matters. Keep WCS and PLC logs for at least the period of time needed to detect long-interval intermittent failures, typically several weeks. Ensure that timestamps are recorded in a consistent time zone and that clock drift is corrected. A queue analysis with mismatched clocks is unreliable and often misleading.
Restart philosophy also belongs in maintenance practice. Differentiate between cold and warm restarts. A warm restart that preserves task state can recover from a transient communication gap. A cold restart that clears all queues should be reserved for cases where the physical state has been verified. Plan restart procedures with the equipment in a known safe state.
Decision Boundaries and Escalation #
Not every queue issue can or should be resolved by the site team. The following boundaries are advisory; always defer to your site procedures, lockout requirements, applicable safety regulations, and OEM documentation. Competent engineering judgment always takes priority over any general guidance.
When a queue is stuck but the field device is idle and safe, the site controls team can typically inspect, reconcile, and restart the affected task. When the field device shows an active fault, stop
