Commissioning a warehouse control system (WCS) is the process of proving that the software layer, the programmable logic controllers (PLCs), and the physical material handling equipment operate as a single, coherent system. Acceptance is the formal confirmation that the behavior meets the agreed operational requirements. This article provides a practical commission and acceptance checklist for controls, PLC, and WCS integration teams. It describes the operating context, component interactions, observable symptoms, evidence collection, common interpretation errors, maintenance implications, and decision boundaries. It is not a substitute for site procedures, lockout requirements, OEM documentation, or competent engineering judgment. Those authoritative sources take priority. Use the checklist below as a structured conversation starter for your own commissioning protocols.
Purpose and Scope of Commissioning #
Commissioning begins after individual machines have been mechanically installed and electrically safe. The goal is to verify that the collection of subsystems—conveyors, lifts, sorters, shuttle carriers, AS/RS cranes, palletizers, and workstations—behaves correctly when coordinated by the WCS. The WCS is the orchestration engine. The PLCs are the real-time execution layer. The physical equipment is the load-bearing and motion layer. A successfully commissioned system is one where all three layers agree on the state of every load, every location, and every task.
Acceptance is a distinct activity. It is the formal demonstration that the commissioned system meets the user requirements. It typically includes throughput tests, failure injection, and a defined period of stable operation. Acceptance is not the same as tuning. Tuning may continue after acceptance. The boundary is contractual and procedural. The commissioning team should deliver a documented baseline, not a promise that the system will be perfect under every future condition.
This article frames the checklist around five domains: PLC state governance, WCS orchestration, interface message flow, diagnostics and evidence, and change control. Working through these domains systematically reduces the risk of accepting a system that works only in a narrow set of conditions.
Pre-Commissioning Readiness #
Before energizing the system for coordinated testing, the commissioning team should confirm baseline conditions. The most common failure in commissioning is not a bad PLC program or a broken WCS message—it is a missing prerequisite that makes every diagnostic ambiguous.
Key readiness items include the following.
- Current, approved versions of PLC programs, WCS configuration files, and database schemas are loaded and documented. Unapproved changes are the leading cause of phantom behavior.
- Network maps are up to date. VLANs, IP addresses, and firewall rules are recorded. The WCS and PLCs must have deterministic reachability. Intermittent network drops will present as false sensor failures.
- I/O checklists are signed off at the physical level. Every photocell, limit switch, photoeye, encoder, and motor fault contact has been exercised and mapped to the correct PLC tag.
- Power distribution is validated. UPS and power conditioning behavior is understood. The behavior of the controls during a power dip is a commissioning item, not an aside.
- Safety systems are verified by qualified personnel. This is not a commissioning activity. It is a prerequisite. All guard interlocks, light curtains, e-stops, and safe torque off circuits must have prior approval before any commissioning engineer energizes motion.
If any prerequisite is incomplete, the commissioning team should stop and escalate. Pushing forward creates a dataset that is full of noise. The cost of collecting clean evidence later is almost always higher than the cost of waiting.
PLC State and Mode Verification #
PLCs in a warehouse control system do not run one continuous program. They run state machines. The WCS sends commands. The PLC accepts them, executes them, and reports results. The commissioning team must verify the PLC state machine under all realistic transitions, not only the happy path.
Start with the machine modes. Most PLC programs have at least manual, auto, and maintenance modes. The behavior of the WCS differs by mode. A critical acceptance condition is that the WCS cannot issue automatic transportation tasks while the PLC is in manual mode. Conversely, a PLC in auto mode should ignore local manual command stations unless specifically designed to coexist. The commissioning checklist should include deliberate attempts to put the PLC and WCS out of sync and confirm that the system refuses to operate.
PLC state also includes the internal state of the equipment. For example, a conveyor zone can be in a state of “occupied,” “cleared,” “jam,” or “blocked.” The WCS often tracks a mirrored state in its own database. The commissioning team should compare the PLC state and the WCS state continuously during testing. A discrepancy at any point indicates a synchronization bug. The evidence collection method here is straightforward: log the WCS view and the PLC view on the same time base and look for divergence.
Startup and recovery behavior is another PLC state concern. A conveyor system does not simply resume after an e-stop. The PLC must execute a restart sequence. The WCS must not send new tasks until the PLC announces ready. Verify that the PLC does not falsely report ready when a load is still partially in a zone. Also verify that the WCS does not send a task to a PLC that is still initializing. Timeouts and acknowledgments must be tested in both directions.
The state model should include an explicit “shutdown” or “suspended” state. During acceptance, the test team should order a controlled shutdown and observe whether the WCS tracks the final positions of all loads correctly. Uncontrolled shutdown, such as a lost network connection, should also be tested. The PLC must fail safe to a known state, and the WCS must mark that equipment as uncertain rather than assume it is empty.
WCS Orchestration and Message Flow #
The WCS is the brain. It breaks down warehouse orders into individual material handling tasks. It assigns those tasks to equipment, monitors execution, and handles exceptions. Orchestration testing focuses on whether the WCS correctly sequences tasks and whether it recovers when the PLC rejects or fails a task.
Message flow testing starts with a single transaction. Pick a simple movement, for instance, moving a tote from a palletizing station to a buffer lane. Verify the message sequence at the wire level. A typical sequence includes the following.
- WCS sends a task request to the PLC with a unique transaction ID.
- PLC acknowledges receipt.
- PLC begins execution and sends a “started” event.
- PLC reports zone-to-zone state changes as the load travels.
- PLC sends a “completed” event with the final destination status.
- WCS verifies the completed event against its own expectation.
Each message must have a timestamp and a source identifier. The commissioning team should test what happens when the sequence is interrupted. For example, if the PLC sends a “completed” event for a load but the WCS expected a “failed” event, the WCS should flag a reconciliation error, not silently update the inventory. These are the diagnostics that will be trusted later.
Timeout handling is a core WCS orchestration concern. If the WCS sends a task and receives no acknowledgment, what does it do? Many systems retry. Some escalate to a human. Others mark the equipment as unavailable. The correct behavior depends on the design. The acceptance criterion is that the WCS behavior is deterministic and documented. There should be no silent retry loop that hammers the PLC and hides the problem.
Task prioritization is another orchestration layer. A warehouse with multiple priorities—urgent replenishment, normal outbound, and returns processing—will have the WCS decide the order. Commissioning should include a test scenario where a lower-priority task is in progress and a higher-priority task arrives. The expected behavior might be “complete current task, then switch” or “preempt.” The team must verify that the design matches the operational requirement and that the PLC is not left in a state where a suspended task loses track of a load.
Interface Testing and Transaction Verification #
Modern warehouses connect the WCS to a warehouse management system (WMS) or an enterprise resource planning (ERP) system. The interface between the WMS and WCS is the boundary where data agreements often break. A WCS commissioning checklist must include interface tests at multiple levels.
Start with the message contract. Confirm the mapping between WMS order numbers, SKU identifiers, and location identifiers. A single field mapping error will propagate into thousands of failed transactions. Verify data types and lengths. A location code that is 12 characters in the WMS but 8 characters in the WCS will create rejected messages at the highest load point.
Idempotency is essential. If the WMS sends the same order twice due to a network retry, the WCS must not create a duplicate task. The commissioning team should deliberately replay the same transaction and check for duplicate creation. Similarly, the WCS must be able to handle a WMS that sends an update to an order already in progress. The interface logic should be tested with both “update allowed” and “update rejected” scenarios, as per the agreed integration design.
Message ordering is a subtle issue. The WMS may send a cancel message for a task that the WCS has not yet received. The two messages may arrive out of order. The WCS should know how to process a cancel for an unknown task. It might acknowledge the cancel and then, when the original task arrives, check against the cancellation list. This requires stateful processing, not a pure message queue.
Interface testing should also confirm the behavior of the WCS when the WMS is down. Some warehouses operate in a degraded mode with manual order entry. The commissioning team must verify that this degraded mode is intentionally designed and that the WCS does not rely on an “always available” WMS. The testing evidence is a log showing the WCS behavior over a period of WMS outage.
Subsystem Interaction and Zone Control Checks #
Equipment-level interaction is where the physical world meets the control logic. The commissioning checklist should include specific verification of zone control on conveyors, the handoff between adjacent subsystems, and the accuracy of load tracking.
Zone control is a key PLC function. A conveyor is divided into zones. Each zone has sensors and a motor or a brake. The PLC must prevent two loads from entering the same zone. The commissioning team should observe the behavior when a photoeye is dirty or misaligned. A common commissioning error is to test only with clean, well-aligned sensors. A robust system will behave safely when a sensor fails—it will stop the zone rather than assume the zone is empty.
Subsystem handoffs are a common source of load losses. When a conveyor hands off a load to a lift or a shuttle, the two PLCs must coordinate. The handoff should be verified with a slow-moving load, a fast-moving load, and a load that arrives late. The logs should show which PLC clears the load from the source zone and which PLC creates the load at the destination zone. A gap in this handoff logic will cause a phantom load—a load that exists in the WCS but not physically, or physically but not in the WCS.
Load tracking precision is directly observable. Run a test where a known set of totes is introduced and track them to their destination. Use physical labels or barcodes and confirm the WCS database matches the physical arrangement at every stage. This is simple evidence, but it is the most convincing kind. Discrepancies should be recorded with the timestamp and the zone where the divergence first appeared.
Diagnostic Observation and Evidence Collection #
When commissioning fails, the evidence collected in the first hour determines whether the fix takes one day or one week. The team should collect logs, alarms, and physical observations in a coordinated manner. The table below gives a practical diagnostic structure for common commissioning scenarios.
| Observed Symptom | PLC/Interface Evidence to Capture | Common Misreading | Sensible Next Step |
|---|---|---|---|
| Load stops at a zone with no alarm | PLC state of the downstream zone, photoeye status, WCS task status, last command sent | “The PLC is broken” or “the sensor is bad” — but the cause may be a WCS task that was never released | Check whether the WCS has assigned the downstream zone to the task and whether the PLC has permission to release |
| Physical load exists but WCS shows no load | Handoff messages between zones, PLC last-cleared event, WCS load creation event, timestamps | “The scanner missed a read” — but the issue may be a message lost during handoff | Review the handoff sequence for the specific zone pair; check for missing acknowledgment logic |
| WCS shows a load that is not physically present | PLC sensor map, operator overrides, manual purge history, WCS update transactions | “Someone removed the load” — but the PLC may have failed to detect the load leaving the zone | Check whether the exit sensor and the zone occupancy sensor disagree; audit the PLC state transition |
| Repeated task timeouts on the same equipment | PLC cycle time, network latency logs, WCS retry count, task execution duration | “The PLC is too slow” — but the issue may be a WCS retry interval shorter than PLC cycle time | Compare the timeout value against the maximum PLC cycle and the physical equipment speed |
| Order completes in WMS but inventory is inaccurate | WCS completion message content, WMS acknowledgment, PLC destination confirmation | “WMS is wrong” — but the WCS may have sent a completion before the PLC confirmed putaway | Verify that the WCS completion event is gated on the PLC “placed” event, not on the task assignment |
The evidence collection plan must include a common time source. PLC timestamps and WCS timestamps are often from different clocks. During commissioning, synchronize all devices to the same time server. Without a single time base, you cannot correlate a WCS message with a PLC state change. Time synchronization is not a nice-to-have; it is the core of diagnostic integrity.
Collect alarm logs and event logs separately. A WCS alarm is a system-level notification. A PLC event is a state change. The two must be correlated, not merged. The commissioning team should maintain an issue log that records each discrepancy, the suspected cause, the evidence, and the resolution. This log becomes the basis for the acceptance report.
Common Interpretation Errors During Commissioning #
Experienced commissioning engineers see the same mistakes repeated. Being aware of them helps the team avoid spending days on the wrong problem.
One common error is treating the WCS as the single source of truth. The WCS holds a logical model. The PLC holds an execution model. The physical equipment holds the actual truth. When the three disagree, the commissioning engineer should start with the physical truth—what is actually on the conveyor—and work backward to the logical models. Assuming the WCS is correct simply because its database is clean is a confirmation trap.
Another error is re-running the same failing test without changing the evidence collection. If a load stops at the same zone ten times, it is tempting to watch it happen again. Instead, stop and inspect the state of the downstream zone. A single inspection of the PLC state is worth ten observed repetitions. Repeating a test that generates no new data is waste, not diligence.
A third error is mistaking a consequence for a cause. A jam at a merge point may appear to be a mechanical problem, but the root cause may be a WCS that released two loads at the same time to the same merge. The physical jam is real, but the control cause is the orchestration logic. The diagnostic table above is designed to remind the team to check the message flow before blaming the hardware.
Finally, the team should avoid the “single error” assumption. Warehouse systems fail in cascades. A failed sensor in one zone may cause the WCS to hold a task, which creates a gap downstream, which causes a sorter to wait, which triggers a timeout and a false alarm. When this cascade is observed, the commissioning team must find the original cause, not the most visible alarm. Sorting alarms by timestamp is necessary, but so is understanding the propagation path.
Governance, Documentation, and Change Control #
Commissioning does not end when the equipment runs. It ends when the documentation reflects the as-built behavior. The acceptance process requires a governance structure that controls changes during the testing period and after go-live.
During commissioning, the PLC and WCS configurations should be under version control. A freeform change without a ticket is the single greatest threat to a stable system. The governance rule is simple: any change to PLC code, WCS configuration, or interface mapping must be recorded with a reason, an author, a timestamp, and an expected effect. After a change is made, a regression test must be run on the affected path.
Maintenance implications must be considered. The commissioning team is not the maintenance team, but it must produce documentation that the maintenance team can act on. This includes an explanation of the operating state model, the meaning of each alarm, the recovery procedure for a jam, and the interface points that require special care. The documentation should also state which systems are interconnected: if a maintenance engineer shuts down one PLC, what does the WCS do?
Decision boundaries must be explicit. The commissioning lead may not have the authority to approve a deviation from the functional specification. The acceptance criteria should define who decides whether a nonconforming behavior is acceptable. The approval matrix should be agreed before acceptance testing begins. This avoids a situation where the controls engineer, under pressure to finish, accepts a workaround as a standard behavior.
Governance also covers the end of the commissioning period. The system should run in a stable manner under normal production conditions for a defined duration. During this period, no major changes are allowed. If a major change is required, the acceptance clock restarts. The commissioning team should document the reason and the new expected completion date.
Key Takeaways #
- Commissioning is the process of proving coordination; acceptance is the formal confirmation that the system behaves according to agreed requirements. Keep the two distinct.
- Verify PLC state machines, including startup, shutdown, and exception recovery, before testing WCS orchestration. A stable PLC foundation makes every later diagnostic more reliable.
- Test message flows at the wire level, not just at the function level. Confirm transaction IDs, timeouts, retries, and the behavior when messages arrive out of order.
- Use a single time base for all logs. Correlated timestamps are the only reliable way to link a WCS decision to a PLC action and a physical result.
- When a discrepancy appears, start with the physical truth, not the database. Compare PLC state and WCS state for the affected zone before assigning blame.
- Collect evidence before concluding root cause. Use a structured diagnostic approach that considers the task release, sensor state, and handoff logic.
- Govern change during commissioning. Unversioned changes are the leading cause of long commissioning cycles and unexplained regressions.
- Site safety procedures, lockout requirements, and OEM documentation always take priority. No commissioning checklist overrides qualified engineering judgment or approved plant policy.
