Automation & equipment
openWCS drives material-handling equipment through a single, vendor-neutral device contract: conveyors, automated storage and goods-to-person stations all speak the same uniform task protocol, with each vendor's quirks confined to a thin adapter. Each family below says plainly whether it is Built today or on the Roadmap.
Built today
These run against the engine today — real routing, storage logic and station execution. Follow a card for the deep dive on how each one works.
A vendor-neutral topology graph the WCS owns: per-scan next-hop pathfinding to sequenced targets, loop-capacity limits, a 2D/3D layout editor that infers the routing graph from the physical placement, and topology discovery learned from live scan traffic.
Block-level put-away, re-slotting and empty-HU management for shuttle / crane ASRS — multi-deep lanes, velocity-to-exit, aisle redundancy and fill balancing across the whole pool.
Station execution: present one stock HU and put-to-light fills many order destinations most-needed-first — the goods-to-person batch. ORDER_LOCATION and PUT_WALL modes share one engine.
A live 3D digital twin renders the saved layout with real-time equipment state, moving totes and storage fill, derived from the device tasks the adapters already report. See the hardware visualisation page for the full picture.
No hardware? No problem
openWCS ships a built-in hardware emulator mode: an admin flips one global switch and every device adapter (conveyors, ASRS, AMR, AutoStore) simulates its machine, returning completed device tasks and synthetic telemetry without ever touching real hardware. When real adapters are configured, the admin flips it off.
A single global switch turns the emulator on across all four adapter families. With it on, no adapter opens a hardware connection: each simulates its commands and reports its mode back to the UI.
Every family simulates its real commands and keeps in-memory device state, so the full flow runs against virtual equipment. Great for evaluation, onboarding new teams, and CI.
Emulator off is the clean seam where real device protocol clients plug in. Flip it off once your physical adapters are wired, and the same flows drive the real machines.
Real-time by design
Conveyor routing is never precomputed and pushed down: the hardware asks the WCS at every scan point, and the WCS answers from an in-memory routing table in low single-digit milliseconds, fast enough for PLC-grade response budgets and built for hundreds of scans per second across the floor. Routing adapts to the physical situation, scan by scan.
Each scan gets a fresh next-hop decision from a per-warehouse in-memory graph snapshot with precomputed routes: no per-scan pathfinding, no per-scan graph loading. A tote that gains a destination mid-journey is rerouted at its very next scan.
Every divert carries a configurable default direction. Unknown totes, scanner no-reads and any late answer follow the default or stop safely at the divert, exactly how a well-engineered installation behaves when a host is slow.
The decision loop measures itself: a live p50/p95/p99 latency report ships in the product, and any single decision over budget is logged with its breakdown. Check the claim on your own hardware.
Under the hood
The flow-orchestrator dispatches device tasks by family; each family routes to its adapter, and the adapter is the only place a vendor's native protocol lives. Adding a machine means writing an adapter — not re-architecting the WCS.
flow-orchestrator ── uniform device task ──┐
│ route by family │
├─ CONVEYOR ─► conveyor adapter ─► scanners · diverts · loops (built)
├─ ASRS ─► asrs adapter ─► shuttles · cranes (built)
├─ GTP ─► station execution ─► put-to-light pick-and-put (built)
├─ AMR ─► amr adapter ─► mobile robot fleet ┄ roadmap ┄
└─ AUTOSTORE ─► autostore adapter ─► cube grid · ports ┄ roadmap ┄
On the roadmap
The uniform device contract is built to carry these families, and the slotting / GTP logic already treats them as storage blocks — but the real device adapters that talk to the physical fleets are scaffolds today. Framed honestly so you know where the line is.
Planned: a real AMR device adapter for goods-to-person and goods-to-rack fleets. The slotting and GTP engines already model AMR blocks; the fleet-facing adapter is a scaffold, not yet implemented.
Planned: a real AutoStore adapter for grid bins and ports. Slotting treats AutoStore as an automated block today; the adapter that drives the grid and its ports is designed for, not yet built.
Open & vendor-neutral
Every adapter and the device contract are open source. Adding a vendor is an adapter, not a rewrite — and the routing, storage and station logic stay yours to read and change.