System integrators & fleet operators
You commissioned the cells, validated the safety logic and signed for it. This is a coordination layer that works above all of that through the interfaces vendors provide — so a customer gets one plan across every vendor on the floor, and what you validated stays validated.
Five problems
Each of these is something that goes wrong after the cells are commissioned and the safety case is signed, and each is answered by a rule rather than by a feature.
Mixed fleets get coordinated with bespoke glue code written per site and maintained by whoever wrote it. Here each vendor is an adapter written once against its own interface, and site-specific behaviour — zones, resources, rules — is configuration on the record rather than code in a branch.
Anything that can move a robot belongs inside the validated system. This layer sends tasks, missions and destinations through the interfaces vendors provide for that purpose, and has no code path that commands motion or touches a safety function — so adding it does not change what you validated.
A new rule, zone or charging policy is run in simulation against the customer’s own layout and recorded demand first, and it cannot be released until it has been. The release records which simulation it was approved against and who released it.
Every task sent to a robot carries the plan it came from, the state it was allocated against, the reason it went to that robot and the person who released the plan — and every refusal from a vendor system is recorded with the reason it gave. The record answers the question before the meeting starts.
Battery as a percentage, a voltage or a time remaining; a fault as a code or a sentence. Adapters map each onto one vocabulary and keep the original report beside it, so the customer gets one fleet view and a vendor engineer can still read their own data.
A site, end to end
Each vendor’s fleet manager, controller interface or protocol — fleet-manager APIs, VDA 5050, OPC UA, MQTT, PLC tags — is reached through its adapter, read-only first. Which robots can accept tasks and which can only report is settled here and recorded.
Zones, stations, chargers, lifts, doors and aisles become resources with calendars. The layout is the customer’s, and so is every rule configured on top of it.
The coordination plan runs against the layout and a replay of recorded demand: throughput, waits, conflicts and charge levels, beside how the floor runs today.
A named person at the customer releases the plan. From then on every task dispatched traces to that release, and every change goes through the same simulate-and-release step.
Tasks flow through vendor interfaces, refusals and faults are replanned inside the released plan, and the record of what was sent to each robot — and why — is there for the next review.
What stays yours
Said plainly, because it is the question an integrator should ask first.
What we assume
This is not a replacement for integration work, and it does not compete with the controllers, safety systems or fleet managers you install. It gives you one coordination layer to deploy across mixed-vendor sites instead of writing a new one each time, with an API you can build on and a record you can hand the customer. If a site needs only one vendor’s fleet manager, it probably does not need this — and we will say so.
The vendors on the floor, what the glue code does today, and what broke last time somebody changed it. We will tell you plainly which parts this would replace and which it would not.
Get in touch
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