The power

When the plant draws power is a production decision

For an energy-intensive plant the bill is decided by the schedule — which line runs when, when the fleet charges, whether a peak lands inside the contracted limit. These pages describe how the software plans against that, and what it refuses to claim.

Demand forecasting

Consumption forecast per line, per cell and per fleet from metered history and the production plan, so the energy a schedule will draw is known before it is released rather than read off the next bill.

Forecasts built from metered consumption, joined to the orders and operations that drew it
A plan’s expected draw shown beside its throughput when it is simulated, not after it runs
Every forecast carries the history window and the plan it was built from
Meters that stop reporting are shown as stale, and a forecast built on stale data says so
Forecast against actual recorded for every period, so accuracy is measured rather than assumed

Energy-aware scheduling

Production scheduled against the tariff in force on the day and the plant’s contracted demand limit. Flexible work moves into cheaper or cleaner windows; work that cannot move is never moved to save money.

Tariffs, time-of-day bands and demand limits are effective-dated data, not constants
A schedule whose forecast peak breaks the contracted demand limit is refused, naming the interval
Only work a planner has marked as flexible is shifted; delivery dates are constraints, not costs to trade
Each shift in timing shows the price and forecast that justified it
The trade-off between energy cost and throughput is shown to the person releasing the plan, not decided for them

Charging, storage and generation

Robot charging, battery storage and on-site generation coordinated with the production schedule, so a fleet charging at shift change shaves a peak instead of creating one.

Fleet charging planned against the demand limit and the next shift’s work, not just battery level
Battery storage charge and discharge windows recommended against tariff and forecast
On-site solar or other generation monitored and its forecast output used in scheduling
Setpoints and schedules go to the site’s own energy or battery management system, which may refuse
A charging plan never leaves a robot below the reserve its next task needs

Savings

A saving is a computation, not a claim

Energy software is easy to oversell, because a saving is a counterfactual: it is the difference between what happened and what would have happened otherwise, and the second number is never measured. So the software only shows a saving it can compute against a recorded baseline — a defined period, its consumption, its production volume and its tariff — and it shows the baseline beside the figure.

Baselines are normalised for what actually changed. A month that produced less used less power, and that is not a saving; the comparison is made per unit produced, at the tariff in force, and a period with no comparable baseline shows no saving rather than an estimate.

Every figure on an energy report traces to the meter readings and tariff rows beneath it, so a saving can be checked by the finance team that will be asked to believe it.

Where the software stops

It schedules. The site’s own systems operate the plant.

Switchgear, protection relays, inverters, battery management systems and generation controls carry safety functions and grid obligations of their own, and they are validated for them. The software does not operate any of them directly. It produces schedules and setpoint recommendations and sends them to the site’s own energy, building or battery management system, which executes them under its own logic and limits — and may refuse.

A refusal is recorded and the schedule is replanned around it. Nothing retries a setpoint until it is accepted, and nothing in the software can override a protection function, a grid-connection limit or a manufacturer’s battery limit. If that ever changes it will be a decision announced on this page rather than a capability that appeared in a release note.

Said plainly

Tariffs and limits are a maintenance commitment, not a dataset

Electricity tariffs change by regulatory order, time-of-day bands are revised, contracted demand limits are renegotiated, and an export arrangement for on-site generation has its own terms. Any product in this category is only as current as the person whose job it is to keep those current — so we would rather say that than let a page imply the software knows things it cannot know. Tariffs, bands and limits are effective-dated and loaded from one reviewed source each, and a period with no reviewed tariff is refused rather than scheduled with the previous one’s prices. Every schedule and every saving records which tariff produced it, so if a tariff is later found wrong, the figures it produced can be found rather than guessed at.

Bring last quarter’s energy bills

The useful test is a real bill. Send us the last three months, the production volumes behind them and the contracted demand limit, and we will show you where the peaks came from, which work was flexible, and what a schedule informed by price and demand would have changed — computed, not estimated.

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