Quick question: what does your WCS do when a parcel jams at the merge at 2 a.m., the scanner starts missing reads, and someone hits the E-stop — all in the same hour? If your honest answer is "we'll find out on go-live day," keep reading. I've stood in that building on that day, watching dozens of people stare at a conveyor that had simply... stopped. The WCS said one thing, the WMS said another, and the project manager's face told the whole story.
Almost every one of those disasters was avoidable. The method has an unglamorous name — virtual commissioning — and it means exactly what it sounds like: before the steel goes up, you make the real WCS believe the equipment already exists, and you run it hard. You run orders, you break things, you fix the logic. Breaking things in a virtual environment is free. Breaking them on site costs money every single minute.
What you're actually testing
In one sentence: software models your entire conveyor-and-sorter system, and the real WCS plugs in and runs it. The simulation builds your line as designed — how long, how many divert chutes, where the scanners sit, where the reject lane is — and the WCS issues commands exactly as it would on site. The model answers back according to physics: parcel weight, belt speed, what happens when flow backs up.
One distinction people constantly blur: simulation is virtual-on-virtual, useful for validating process logic. Emulation is the real WCS driving virtual equipment, and that's what validates the control logic. Before go-live, you want emulation — and the WCS under test must be the exact build going live, not a line of code different. A green run on a demo build followed by a swap to the production build is a wasted run.
I insist the emulation environment gets built during factory acceptance testing, not after equipment ships. Once steel starts going up on site, schedule pressure compresses commissioning to a third of what was planned, and every unresolved issue rides along to go-live day. In the factory, when the logic's wrong, an engineer fixes PLC code or WCS logic on home turf. On site, you're doing it surrounded by cranes, scaffolding, and a safety officer — the psychological cost of changing one line of code is completely different.
Fault injection: test it at its worst, on purpose
Ten thousand clean orders teach you less than a hundred ugly ones. The greatest value of virtual commissioning is consequence-free sabotage. Would you deliberately jam a live sorter? In the virtual world, jam it all day and reset with one click.
My mandatory fault list looks like this. Jams: block the divert chute, the incline, and the merge — one at a time — and watch how fast the WCS detects it, whether the alarm is accurate, and whether the recovery sequence actually works. Scan failures: consecutive no-reads, damaged barcodes, two lookalike parcels back to back — does the reject logic kick the problem parcel out cleanly, or does it recirculate forever? An endlessly recirculating bad parcel is the dumbest failure mode there is; one bad item can drag down the whole line's throughput. E-stop: hit it at random moments — is the shutdown sequence correct, is order state preserved on recovery, is any parcel "forgotten" on a belt segment? Network loss: cut the WCS–WMS link for a few minutes — are messages lost or queued, and do the two systems reconcile afterward?
After each fault category, demand three things from the vendor: the system logs from that moment, the WCS alarm records, and how long recovery took. That's your medical chart for go-live troubleshooting. A project without these charts re-diagnoses from scratch every time something breaks — half an hour of downtime per guess.
The WCS–WMS interface is where projects die
Half of automation failures are equipment. The other half are the interface. The WCS moves machines, the WMS owns orders and inventory, and they reconcile through messaging. When the interface lies, the floor lies with it: the WMS thinks it sent the order, the WCS says it never arrived; sortation finishes, inventory never decrements; one network blip and both sides keep their own books.
Test the interface for the worst case, in three parts. First, message reconciliation: after a batch run, match order status, piece counts, and sort results line by line between the two systems. Not a single line may differ — and note, line-by-line, not totals. Matching totals with scrambled line items is a worse, sneakier problem. Second, heartbeat and reconnect: simulate network jitter and watch for lost messages on reconnect — and whether retries cause double-sorts. A double-sort is the most expensive interface bug there is: one order sorted twice, the customer gets two parcels, and returns plus customer-service cost arrive immediately. Third, edge-case orders: oversized, overweight, multi-piece, cancelled mid-flight — the "weird orders" the WMS will absolutely send. Normal orders run anywhere. Weird orders are the real test.
Acceptance criteria belong in the contract
Virtual commissioning isn't "it runs, ship it." The acceptance criteria go into the contract at signing. Mine has three lines, and I don't sign without all three.
First, continuous unattended operation. Run the emulation at design throughput with zero human intervention — I ask for eight hours minimum. This is the easiest line to game: vendors love "continuous operation" with an operator hovering, ready to rescue. That's not unattended. My rule: during the test, operators may watch but never touch. One touch restarts the clock. Harsh? Sure. Go-live day offers no restarts, and peak-season orders won't wait for you.
Second, sort accuracy. Wrong chute, missed divert, unrejected exception — all count as errors, and the allowed rate goes in the contract as a number, sized to your business tolerance. "As accurate as possible" is not a standard. A standard without a number isn't a standard.
Third, fault recovery time. Maximum allowed time from jam alarm to normal operation — exceed it and you fail. This line is for the ops team: when the 2 a.m. alarm goes off after go-live, the on-call person needs to know how long this should take, and when to escalate. The recovery times measured in virtual commissioning are what that line is based on.
Virtual commissioning typically consumes five to ten percent of total project time. It looks like cost; it's actually the cheapest risk hedge you'll ever buy. One day of on-site commissioning — labor, rigging, stopped lines — buys you hundreds of thousands of virtual orders. Remember this: every mistake you don't make in the virtual environment gets repaid with interest on go-live day.
One last question for you: was virtual commissioning your vendor's idea, or did you have to demand it? If it was theirs — congratulations, you picked the right supplier. If it was yours — go ask for it now. There's still time, as long as the steel isn't up yet.
