This page describes what the Sun Tech WCS engine does, without code: how it represents the plant, how it chooses routes, how it talks to the WMS and what it exposes to other systems. The technical detail is in the repository's documentation.

The plant as data

The plant is made of devices (the points) and junctions (the directed arrows that connect them), stored in the WCS database. At start-up they become a graph on which the engine computes routes. One more machine is one more point in the drawing, not more code.

There are seven device types: automation, loading, buffer, storage, circular distributor, group of automation devices, loading and buffer together. How to model a plant is explained in Modelling a plant.

Routes

The path with the fewest hops wins; with the same number of hops, the least crowded one. Junction priority decides the order in which the engine explores the ways.
It uses no estimated times, by choice: the route is recomputed at every hop from the real state of the devices.
You can impose mandatory gateways, groups of devices to be crossed only once and different levels of the same plant.
Offline devices are avoided. If there is no alternative, the engine tries again taking them into account: a degraded plant keeps working instead of stopping.

Missions and device states

A mission is a load unit, a destination and a type: storing, extraction, change of location, rejection, defragmentation and the others the engine provides. The steps of a mission are created one hop at a time.

Every device has a state: ready, moving, loading, unloading, busy, recovering, offline, locked, warning, error. "Error" is a logical state, meaning the last command did not succeed: it is not a field alarm.

Talking to the WMS

The WCS is the one that asks for work. While the engine runs, once a second it asks the WMS what there is to do: extractions to carry out, shipping notes. The WMS does not push orders.

Physical facts, such as a unit arriving in its cell, go back to the WMS from durable queues: they are delivered at least once, with a receipt, and survive a restart and a WMS that is down. If the WMS does not answer the engine keeps running: the missions that depend on it wait, and the facts leave when it comes back.

Warehouse logic

The WCS handles the extraction queue, cell reservations, multi-depth cells, defragmentation, device groups and rejection points. It is the part between "take a pallet from A to B" and a plant that works all day.

API, events and contracts

An HTTP API with 66 operations, protected by a key, to command the engine, the devices and the load units and to read their state.
A real-time event channel (SignalR): device state changes, missions, extraction queue, commands.
A typed .NET client, with automatic reconnection to the events.
The contracts in OpenAPI 3.1 format, generated from the code and checked at every change.

Operations

The WCS runs as a Windows service and keeps its data in SQLite, with no database server to install. It has a tool for backup, verification and restore even with the engine running, a monthly history of operations and movements, and three monitoring scripts. The detail is on the safety and operations page.

What is not there yet

The Viewer library, which keeps a read-only copy of the state, is experimental. The logic of a new device type today requires changing the engine: making it pluggable is a direction the project has declared, not yet specified. The full list is in the known limitations.

Want to see it at work? The sample plant runs on one Windows machine in about fifteen minutes, with no machines and no WMS of your own. Get started

What Sun Tech WCS does