The platform

How it is built, and how it connects to the floor

The engineering decisions an automation engineer asks about on the second call, answered here instead.

Four properties

Each of these is checkable, which is why it is written down

“We take safety seriously” is not a claim anybody can test. “The allocation layer cannot import the model client, and a build that lets it fails” is.

One adapter per vendor, read-only by default

Every system the line talks to is reached through an adapter written against that vendor’s own interface. An adapter starts read-only, and the ability to send tasks is enabled per vendor, per site, by a named person — never inferred.

Fleet-manager and robot-vendor APIs, VDA 5050 for mobile robot fleets, OPC UA, MQTT and PLC tags
Tasks are sent only through interfaces a vendor provides for receiving tasks; nothing is written to a PLC program
Each adapter declares what it can do — report status, accept tasks, report energy — and the planner respects it
The vendor’s original report is kept beside the normalised one, so their engineers can still read their own data
A new vendor is a new adapter, not a change to the planner

The planner and any model are separate

Not by convention and not by prompt instruction. The allocation and scheduling layer cannot import the model client, and the build fails if it can — the import graph is the boundary, made mechanical rather than reviewed for.

Allocation, reservation, scheduling and energy arithmetic are deterministic functions of the recorded state
The same state and the same plan produce the same assignments, so a shift can be replayed
A model may suggest or explain; its output cannot become a dispatched task
Planning rules and thresholds are versioned data, so a change is one diff with an author

Operated like something a floor depends on

Planning, simulation and dispatch run on durable queues rather than inside a request, and a coordinator that restarts resumes from the recorded state rather than from a guess.

A coordinator restart never re-sends a task that was already accepted; dispatch is idempotent per task
If the coordination layer becomes unavailable, vendor systems keep executing what they already hold under their own logic
Every stage of every plan is recorded with its timing, so a slow decision is attributable
A task identifier alone reconstructs its full history, from the plan to the vendor’s acknowledgement

The floor is not on the internet

A plant network carries equipment that was never designed to face the internet. The line is built to be deployed beside it, not through it, and to hold layouts, volumes and equipment lists as the commercially sensitive data they are.

Site connectors initiate outbound connections; nothing on the plant network needs to accept inbound traffic
Deployable on premises for sites whose policy keeps operational data inside the plant
The organisation is applied where the query is built; a cross-organisation read answers 404
Per-organisation encryption keys on stored data, and no network address or controller credential in log storage
Vendor and integrator access scoped to their own equipment and audited

For engineering teams

The API is the product; the console is a client of it

Everything the console does is an ordinary API call, and the integrations a plant actually needs are the ones that run unattended.

Every action in the console is an API call you can make. Create an order, propose a plan, simulate it, release it, read the fleet state, read why a task went to a robot — all of it is addressable without a browser.
State arrives the way plant state actually arrives: unattended, from fleet managers, PLCs, historians and meters, de-duplicated on receipt and stored with when it happened. Results leave as structured data and signed callbacks, so an ERP or MES can verify that a plan or a report came from us and arrived intact.

The stack

Boring where it should be

Nothing here is novel, and that is the intention. The interesting decisions in this product are about what it refuses to do, not about what it is written in.

Planner	Python, layered so route handlers hold no queries and the allocation module cannot import the model client
Data	Postgres for the operating record, with time-series storage for machine signals and meter readings
Connectors	Per-vendor adapters running at the site, speaking each vendor’s interface and the open protocols — VDA 5050, OPC UA, MQTT
Queue	A durable job queue — planning, simulation and dispatch never run inside the request that asked for them
Console	React and TypeScript, with a live floor view fed from the same recorded state the planner uses

Planning, simulation and dispatch run on queues rather than inside the request that asked for them. A coordinator that restarts resumes from recorded state, and dispatch is idempotent per task — which matters on a floor, where a task sent twice is a robot sent twice.

Ask the awkward architecture questions

What happens to the floor when the coordinator is unreachable, how a task is prevented from being sent twice, which interfaces it writes to and which it only reads, what a vendor engineer can see. Those are the right questions and we would rather answer them early.

Talk to us The standard

Get in touch

Talk to the people building it

No chatbot and no ticket queue. Tell us what your floor actually looks like — the robots and who supplies them, the systems they already report to, and what you would like coordinated first — and someone who works on the software will reply.

info@legosphere.com