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.
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.
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.
Planned: live status across the whole estate — running, faulted, idle. The 2D/3D topology editor already lets you lay out and configure every equipment family today; what's roadmap is overlaying real-time device state on it. See the hardware visualisation page for the full picture.
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.