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

The plant

The planning layer a plant actually runs on

Orders, routings, capacity, material, maintenance and the robot fleet in one record — so a schedule knows which cells and robots it can count on before a shift starts, and every figure on a report can be walked back to the event that produced it.

The screens

Six surfaces, each built around one decision

The question above each screen is the one the person opening it is actually holding. If a screen cannot name the decision it serves, it is a table with a heading.

Production planning

What can we actually make this week?

Manufacturing orders against routings, capacity and material on hand, planned across people, cells and robots at once. The plan is proposed by software and released by a planner.

  • Orders scheduled against the capacity of every cell, line and robot the routing needs
  • A schedule that needs material which is not on hand, or equipment that is down, is refused naming what is missing
  • Robot availability comes from the fleet record, so a plan cannot assume a robot that is booked for maintenance
  • Every released plan records who released it and what it was planned against

Manufacturing orders

Where is this order, and what is it waiting for?

Each order as a sequence of operations with its state, the cell or robot doing the work, and — when it is stuck — the specific thing it is waiting for.

  • Operation-level status built from events off the line rather than from manual updates
  • A blocked order names its blocker — material, a cell, a robot, an inspection — rather than showing “delayed”
  • Quantities completed, scrapped and reworked reconcile to quantities started
  • Click any figure and see the events beneath it, with when each happened

Materials and inventory

Will the material be there when the line needs it?

Stock, reservations and consumption against the released plan, so a shortage is visible when it can still be fixed rather than when a station runs dry.

  • Material reserved against orders when a plan is released, not when it is consumed
  • Projected shortages raised against the operation that will hit them, with the time it will happen
  • Robot deliveries to the line planned from the same reservations, so intralogistics and production agree
  • Counted, reserved and consumed quantities reconcile; a difference is an exception, not a rounding

Equipment monitoring

Which machine is about to stop the line?

State, alarms and process signals from the systems your equipment already reports to — PLCs, SCADA, historians and fleet managers — read through adapters and shown against the plan.

  • Machine state and alarms read from your existing systems; nothing is written back to a PLC
  • Every signal keeps when it happened and when it arrived, and a silent source is shown as stale
  • Alarms grouped by the order and operation they affect, not just by the machine that raised them
  • Thresholds are effective-dated data with an owner, not constants in code

Predictive maintenance

What should we service before it fails?

Condition signals and maintenance history turned into a ranked list of what is likely to need attention — each with the evidence behind it — and maintenance windows planned into the production schedule rather than around it.

  • A prediction shows the signals and history it was built from, never a bare score
  • Maintenance windows booked into the schedule, so a robot or cell in service is never planned for work
  • A prediction is a recommendation to a maintenance lead; nothing is taken out of service automatically
  • Outcomes recorded against predictions, so their accuracy is measured rather than assumed

Bottlenecks and reporting

Where is the line actually losing time?

Bottleneck analysis from recorded cycle times, waits and stoppages, and the operational reports a plant runs on — every figure traceable to its events.

  • The constraining operation identified from measured cycle and wait times, not from a nominal rate
  • Availability, performance and quality shown with the events each was computed from
  • Robot waiting time attributed to its cause — a resource, a handover, material or a fault
  • Reports export as structured data with the working intact, not as a screenshot of a dashboard

Who can do what

Roles that match how a plant actually divides the work

Enforced where the query is built rather than hidden in the interface, so a role boundary is not something a direct API call can walk around.

  • Plant lead

    Everything a planner can, plus releasing a production plan or a fleet-wide coordination change. The release is recorded against their name.

  • Production planner

    Orders, schedules, materials and simulation. Can propose and simulate a plan, but cannot release one.

  • Shift lead

    The floor view for the current shift: progress, blocked orders, robot status and replanning inside a released plan. Changes outside it are raised, not made.

  • Maintenance lead

    Equipment monitoring, predictions and maintenance windows. Taking equipment out of service is their decision and is recorded as such.

  • Energy manager

    Tariffs, demand limits, forecasts and baselines. Can constrain a plan’s energy draw, but not release the plan.

  • Vendor or integrator

    Read their own equipment’s status and the tasks sent to it, and provably nothing else. Scoped at the query, tested against every access path.

Above the roles sits the organisation itself. It is applied where the query is built rather than at each endpoint, so a read, list, search or download across organisations answers as though the record does not exist — a 404 rather than a refusal, because a refusal confirms the record is there, and a plant’s layout, volumes and equipment list are commercially sensitive facts about somebody else’s business.

See it against one of your own lines

A planning layer is hard to judge from screenshots. Bring a line you run, its routing and last week’s schedule, and we will walk the whole chain from a manufacturing order to a robot starting work.

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.