Skip to content
Motion, interlocks and emergency stops stay with the validated controller — always
LegosphereIndustrial

Robotics · Manufacturing · Energy

One operating record for
mixed robot fleets

Legosphere Industrial coordinates robots, cells and plants that other companies build — fleet status, task allocation, production orders, maintenance and the energy they draw — from one record. It plans, schedules and monitors above your controllers and fleet managers, and it never commands a motion or a safety function that a validated control system owns.

Talk to usHow a task is allocated
  • Safety stays in the controller
  • A plan is released by a person
  • Every dispatch traces to its plan
  • Equipment from any vendor

Three surfaces

The fleet, the plant, and the power behind them

One record underneath all three: it holds the robots, the orders and the meters, the planner schedules against it without being able to move anything, and the console is where a person reviews a plan and releases it.

The fleet

Robotics and swarm coordination

One view of every robot, whoever built it, and one allocator deciding which of them does what. Availability, faults and battery come in through each vendor’s own interface; tasks go out as assignments its fleet manager or controller executes. Coordination happens at the level of tasks, zones and shared resources — never at the level of motion.

  • Status, faults, battery and position from mixed fleets, normalised to one vocabulary
  • Distributed task allocation across robots and vendors where their interfaces allow it
  • Shared resources — lifts, doors, chargers, aisles — reserved so two robots never hold the same one
  • Replanning when a robot faults or goes offline, with the reassignment recorded and explained
  • Swarm behaviour simulated against your own layout before a new plan reaches the floor

Fleet managers · automation engineers · shift leads

Robotics and swarm coordination
The plant

Manufacturing and automation

The planning layer a plant actually runs on: production orders, schedules, materials, maintenance and the events coming off the line. It joins the robot fleet to the enterprise plan, so a schedule knows which cells and robots it can count on before a shift starts rather than after it stalls.

  • Production plans and schedules built from orders, routings, capacity and material on hand
  • A schedule that needs material which is not there, or a cell that is down, is refused rather than published
  • Equipment monitoring and predictive maintenance from the signals your systems already emit
  • Bottleneck analysis grounded in recorded cycle times, not estimates
  • Manufacturing orders and operational reporting with every figure traceable to its event

Production planners · plant managers · maintenance leads

Manufacturing and automation
The power

Energy intelligence

Demand forecasting and energy-aware scheduling for plants whose biggest variable cost is the power they draw. It moves flexible work into cheaper or cleaner windows, coordinates charging and storage, and shows every recommendation beside the tariff and forecast that produced it.

  • Demand forecasts per line, per cell and per fleet, built from metered consumption
  • Production schedules that respect a contracted demand limit and the tariff in force on the day
  • Robot charging and battery storage coordinated so a peak is shaved rather than created
  • Monitoring and scheduling support for on-site generation and storage
  • Every saving claimed is computed against a recorded baseline, not asserted

Energy managers · plant managers · facility operators

Energy intelligence

The specification

What it is, and what it is not

The questions that decide this purchase are specification questions — what it controls, what it only plans, and where it stops. They are answered here rather than on a second call.

What this is

An operating record and orchestration layer for robot fleets, production and energy: robots, cells, lines, orders, materials, maintenance, meters and the plans that tie them together — with a deterministic planner over the top, a vendor adapter for every system it talks to, and a person who releases each plan before it reaches the floor. It is built for plants that already own their equipment and want it coordinated, not replaced.

What this is not

Not a robot, not a robot controller and not a safety system. It does not generate trajectories, command motion, drive actuators or perform any safety function, and it cannot override an interlock, an emergency stop or a safety-rated monitor. It sends tasks to the controllers and fleet managers that already own execution, through their own interfaces, and those systems remain free to refuse.

DomainRobot fleets, manufacturing operations, industrial automation and energy — the planning and coordination above the equipment, not the equipment itself
HardwareNone of ours. Robots, PLCs, fleet managers and meters are supplied by other companies and reached through their own interfaces
SafetyMotion control, interlocks, emergency stops and safety-rated monitoring stay in validated control systems. The software never commands them and has no way to bypass them
ExecutionThe software assigns tasks; the vendor’s controller or fleet manager executes them and may refuse. A refusal is recorded and replanned, never retried around
ReleaseA production plan or a fleet-wide task plan reaches the floor only after a named person releases it. The release is recorded against their name
AllocationTask allocation is deterministic for the same state and the same plan. A model may suggest; it never assigns a task to a robot
Shared resourcesLifts, doors, chargers, aisles and stations are reserved explicitly. Two tasks holding the same resource at the same time is refused at planning, not discovered on the floor
EventsStatus, faults and meter readings are stored with when they happened and when they arrived. Every plan, alert and forecast uses the first
ProvenanceEvery dispatched task carries the plan it came from, the state it was planned against and the person who released it
IntegrationAdapters per vendor and protocol — fleet-manager APIs, VDA 5050, OPC UA, MQTT and PLC tags — with the console as one client of the same API
EnergyTariffs, demand limits and baselines are effective-dated data. A saving is computed against a recorded baseline or it is not shown
TenancyThe organisation is the tenant, enforced where the query is built. A read across organisations answers as though the record does not exist

Why it is built this way

In this domain a wrong plan does not produce a wrong document. It produces a stopped line.

Industrial operations have a property the other domains this company builds for do not: the output moves. A plan that assigns two robots to the same lift, schedules a cell that is down for maintenance, or sends a fleet to charge in the same fifteen minutes does not produce an error message. It produces a robot waiting in an aisle, a line starved of parts, or a demand peak on next month’s bill. The software is therefore written to refuse a plan at planning time, while there is still a person able to change it.

The robots themselves are already well served. Every serious manufacturer ships a controller, a safety system and usually a fleet manager, and those are validated for the job of moving a machine safely. What a plant with three vendors does not have is anything above them: one view of the whole fleet, one allocator that can hand work across vendor boundaries, and one schedule that knows about robots, people, material and power at the same time. That gap is where this line sits, and it deliberately sits nowhere else.

So the architecture draws one hard line and builds everything around it. Below the line are motion, interlocks, emergency stops and safety-rated monitoring — owned by validated control systems, never commanded from here. Above it are tasks, zones, schedules, orders, maintenance and energy — planned here, released by a named person, and dispatched through each vendor’s own interface, which remains free to refuse. A refusal is a fact the planner records and works around, never an obstacle it retries past.

Swarm coordination is where that discipline matters most. Distributed allocation, shared-resource scheduling and replanning when a robot drops out are genuinely hard problems, and the tempting failure is a clever algorithm nobody can audit. Here allocation is deterministic for the same state, every assignment carries the reason it was made, and every new behaviour is simulated against your own layout before it reaches the floor.

None of that makes a plant run itself. It makes the plan reviewable and the floor predictable, which is the property software can actually give an operation this physical. The safety case stays with the systems — and the people — who are qualified to own it.

How it works

What happens to a plan

Five stages between a production order and a robot starting work, each with a rule attached. Most of the rules exist because of a way an automated floor fails quietly.

  1. 01

    Read the state

    Robot status, faults, battery and position arrive through each vendor’s adapter; machine signals arrive from PLCs and the line; meters report consumption. Each reading keeps when it happened and when it arrived, and a source that has gone quiet is marked stale rather than assumed healthy.

  2. 02

    Plan against it

    Production orders, routings, material and capacity become a schedule; the schedule becomes tasks; tasks are allocated across robots and cells by a deterministic planner that reserves every shared resource it needs. A plan that depends on a faulted robot or missing material is refused, naming what it depended on.

  3. 03

    Simulate, then release

    A new plan or a new coordination behaviour runs against your own layout in simulation first. A named person reviews what it will do — throughput, conflicts, energy draw — and releases it. Nothing reaches the floor unreleased.

  4. 04

    Dispatch through the vendor

    Each task goes to the controller or fleet manager that owns the robot, in that vendor’s own interface. The vendor system executes it under its own safety logic and may refuse; a refusal is recorded with its reason and replanned rather than retried around.

  5. 05

    Watch, and replan

    Progress, faults and energy draw are monitored against the released plan. When a robot drops out or a cell stops, the affected tasks are replanned under the same rules, and the reassignment is shown to the person who released the original.

Coordination, stage by stage

What it has to satisfy

Twelve rules that constrain the software

Each one is a constraint rather than a capability, and each is written so a customer can hold the software to it. Most of them describe something it refuses to do.

  • Safety stays in the controller

    Motion, interlocks, emergency stops and safety-rated monitoring belong to validated control systems. The software never commands them, has no interface that could, and treats any request to bypass one as something it cannot do rather than something it declines.

  • A plan reaches the floor only when a person releases it

    Production plans and fleet-wide task plans are proposed by software and released by a named person. The release is a field on the record, not a click in a workflow, and an unreleased plan cannot dispatch a single task.

  • The vendor system may refuse, and that is final

    Tasks go to the controller or fleet manager that owns the robot, through its own interface. When it refuses, the refusal is recorded and the work is replanned. Nothing in the software retries around it.

Read all twelve

Questions

What people ask first

Mostly one question in several forms: does the software move the robots? It does not, and these are the mechanisms that keep it that way.

No. Legosphere is a software company. This line manages, coordinates and optimises robots and industrial systems manufactured or supplied by other companies — arms, mobile robots, conveyors, cells, PLC-controlled lines and the energy systems behind them. Every robot it talks to is somebody else’s equipment, reached through that vendor’s own controller, fleet manager or published interface.

Bring the shift that went wrong

The useful conversation starts from a real floor rather than from a deck: which robots you run and who built them, where work waits today, and what last month’s energy bill looked like. Tell us that and we will tell you plainly whether this fits.

Talk to usSee pricing

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

Please keep network addresses, controller credentials, safety configurations and plant layouts out of this box — it is an ordinary enquiry form, not a channel for live plant data.