Development of an AI System for Optimizing Energy Consumption in Manufacturing

Energy consumption optimization: where production wastes energy

Energy consumption optimization at a manufacturing facility begins not with purchasing new equipment, but with analyzing how the site consumes energy over a 24-hour period.

The main energy losses in production come from three things: uneven load on lines, manual control of high-power consumers, and lack of metering by area. Individually, each looks harmless; together, they produce consistent overconsumption during peaks.

The peak is formed by coinciding start-ups. The compressor room, pump groups, furnaces, refrigeration and ventilation units start according to schedule or by operator command, not according to the actual demand of the area.

Several starts in a row raise consumption to maximum, and it is this maximum that determines grid requirements and the load on service entrances.

Uneven load adds a second component. The line reaches operating mode gradually, runs underloaded at the end of the shift, while the consumers serving it continue to operate at nominal: pumps deliver full flow, ventilation maintains design capacity. The same amount of energy is consumed as at full load, although less useful work is done.

Third, without breakdown by metering points, overconsumption is visible only in the overall bill. It is impossible to separate start-up losses from inefficient mode or compressed air and steam leaks, so decisions are made by feel, and the resulting effect is not sustained. Next, we examine how this is closed.

What changes at the site: load peaks and consumption per ton of product

The effect of implementation is visible not in a report, but in four site metrics: load forecast, peak power, consumption per ton of product, and equipment downtime.

We record them before the start on the baseline period and again after, on the same units and the same product mix.

• The load forecast is built a day ahead according to the production plan, not based on actual switching: the shift sees in advance the windows where energy-intensive operations can be moved.
• Peak power drops by 10–20% compared to the baseline period — the daily profile is smoothed, and simultaneous start-up of heavy units is removed from the schedule.
• Consumption per ton of product becomes stable: the spread between shifts is reduced, and deviation is visible within a shift rather than at the end of the month.
• Equipment downtime is reduced — a class of failures associated with overload and drive overheating goes away, along with unscheduled stops during peak hours.
• Mode boundaries are tied to the nameplate limits of the equipment, so smoothing is not bought at the cost of accelerated wear.

To ensure the effect is not confused with seasonality or a change in product mix, the comparison follows the ISO 50001 methodology: the baseline period is normalized by weather and output volume.

Then the reduction in peak power and consumption per ton is a consequence of management, not a lucky quarter.

System operating modes: advisory, automatic, closed loop

Control mode is not a setting to 'turn on automation', but a choice of acceptable risk for a specific area. The advisory mode does not switch anything itself: the model gives the dispatcher a set of actions with expected effect, and the decision remains with the human.

A closed control loop removes this safeguard — the controller changes setpoints itself, and along with the quality of the model, the risk of error grows.

Limitations of automation at the start

We do not enable a closed loop for the entire enterprise at once. First, the advisory mode tests the model on historical data: whether the forecast matches actual consumption.

Then automation takes a limited list of units with clear dynamics, and the rest remains on recommendations. Return to manual control is one command, without restarting the system.

How we implement the system: from consumption audit to handover for operation

The order of stages here is not a formality: the optimization model is built on data, not assumptions, so the reliability of metering is checked first.

If some points are counted as a single number or the meter archive breaks, analytics will produce a beautiful graph with no connection to the shop floor.

1. Consumption audit. We inspect metering points along the entire chain — service entrance, distribution boards, individual lines and equipment groups — and compare the design scheme with the actual topology.

   We record where measurement exists and where load is counted as a single number for several consumers.

2. Assessment of metering data quality. We consolidate meter archives and manual logs, looking for gaps, time stamp desynchronization, and duplicate records.

   We restore a continuous series for a full production cycle — without seasonality and shift modes, the model cannot be trained.

3. Analysis of consumption structure. We break down consumption into base load, process component, and losses: it becomes visible what can actually be managed and what is set by the process itself.

4. Model building. The model calculates the expected profile based on output, temperature, and line load and compares it with actual data — deviation becomes a measurable signal instead of a debate about causes.

5. Scenario setup. Together with process engineers, we discuss setpoints, priorities, and intervention boundaries: what the system changes itself and what it gives to the dispatcher as a recommendation.

6. Trial operation. The system operates in parallel with the usual control, we compare its conclusions with the actual decisions of the service, and bring accuracy to a stable level.

7. Handover of the system for operation. We provide regulations, instructions, and access rights, and train personnel: who, within what timeframe, and how they respond to a deviation.

What remains at the site: models, metering schemes, regulations

The energy consumption optimization system lives longer than the implementation project, so together with the working loop, the customer receives a complete set of documentation and settings — to develop the solution on their own or with any contractor. Below is the list of artifacts handed over to the site at the end of the work.

• Consumption forecasting model — trained on historical production data, with fixed features, forecast horizon, and a methodology for quality validation on a holdout sample.
• Metering scheme — a map of measurement points linked to equipment units, polling frequency, list of data transmission channels, and rules for handling gaps.
• Exchange configurations with existing dispatching and metering systems: which data are read, which signals go back, and where the responsibility boundary lies.
• Maintenance procedure — retraining frequency, procedure for actions when forecast diverges from actual data, and alert thresholds.
• Responsibility matrix — who owns the model, who is responsible for data completeness, who responds to deviations, and how incidents are escalated.
• Instructions for process engineers and dispatchers: how to read system recommendations, which decisions remain with humans, and what to do when calculations are unavailable.
• Versioning and rollback procedure: where previous model versions are stored and how to return to a working one when quality degrades.
• Effect evaluation methodology — how the consumption baseline is calculated and how the result is confirmed over time, so that the effect does not depend on seasonality and shop loading.

Implementation example: how load peaks stopped determining consumption

A site with a continuous cycle: three lines, drying and compressor units. Average monthly consumption looked normal, but twice a day — at shift start and after process pauses — the load went above the contractual maximum.

The dispatcher saw the peak after the fact, when the service entrance approached the cutoff, and manually removed some units.

We collected telemetry from metering points and built a daily profile model tied to the shift and start-up schedule.

Then came smoothing rules: stepped heating of energy-intensive units, spreading line starts over a 40-60 minute window, a buffer for compressed air and cooling, a peak forecast half an hour ahead with a hint of which unit to shift.

Energy consumption optimization was based not on the monthly average, but on the daily profile; reporting was brought in line with ISO 50001 requirements.

Metrics before and after: peak service entrance power is 19% lower, specific consumption per unit of product is 11% lower, and the spread between shifts narrowed from ±14% to ±5%. Service entrance overload protection trips — one per quarter instead of five to seven per month.

Customer feedback: 'The shift no longer starts with a jolt. We see the peak in advance, we spread starts according to schedule — the service entrances handle the load without manual shutdowns.'

Energy consumption optimization by schedule or by load forecast?

The difference is visible where actual load diverges from the plan. Schedule-based control switches equipment according to a pre-fixed calendar of shifts and tariff zones; forecast-based control recalculates for each interval which consumption profile will be advantageous. The first approach does not need production data; the second definitely does.

A schedule is a set of setpoints and time windows loaded into controllers and the dispatcher's chart. It is predictable, understandable to operations, and continues to work when communication with the calculation server is lost.

The weak point is deviations: a line goes down for unscheduled repair or a shift catches up with the plan earlier, while switching follows yesterday's logic, and flexible load turns on at the most inconvenient moment.

The forecast mode builds the expected profile several hours ahead: consumption history, output plan, shift schedule, and weather factors go into the model. The optimizer distributes shiftable load — storage units, compressors, pumps — across windows where consumption is minimal.

The price for this is requirements for data and model maintenance: when the product mix changes, it must be retrained, otherwise forecast error eats up the effect.

A schedule is sufficient for a stable cycle, a small share of flexible load, and small deviations from plan — a complex model does not pay off there. A practical compromise is a two-level scheme: schedule as a reliable base, forecast on top for large consumers.

We make the choice based on the consumption archive: spread of deviations, share of shiftable load, and horizon of reliable production data.

Doubts before launch: metering, data, and responsibility for decisions

Dispatching usually already exists in production, so our layer reads data from the existing APCS loop and does not replace it: archives, event logs, and current readings are pulled through standard exchange interfaces, while control actions remain with personnel.

Incomplete metering data is the norm, not the exception: meters are polled at different intervals, some channels are silent during downtime, and intervals are duplicated.

Therefore, before training, we build a reliability profile — mark gaps, verify balances by point, restore short breaks, and explicitly show where the calculation relies on measurements and where on estimation.

Will existing dispatching have to be rebuilt?

No. We connect to existing sources in read mode and change nothing in the control loop. If exchange is possible only via exports, we work according to an agreed export procedure — with a delay of one polling interval.

Who is responsible for recommendations and model errors?

The model proposes modes with confidence and expected effect indicated; the decision is made by a process engineer or power engineer — they have the final say.

Responsibility for equipment operation remains with operations; responsibility for calculation quality and clarity of justifications remains with us; this is fixed by procedure before launch.

What is included in support after launch?

We monitor data drift and divergence of forecast from actual, retrain the model when the load mode or equipment composition changes. The support procedure with a fixed response time is agreed in advance.

Let's discuss the task: where to start at your site

To come back with an assessment and plan, rather than general considerations, we need a minimum of information about the site. Usually this data is already available from the chief power engineer and dispatcher — it does not need to be prepared specially.

• Pilot boundaries at the area: the specific line, shop, or unit where we launch the first version, and who is responsible for this loop.
• Metering and data: which devices are installed at the service entrance and on equipment, how often readings are taken, and whether the archive for the past period can be exported.
• Distribution scheme: where the common service entrance is, where individual feeders are, what is already automated and controlled remotely.
• Operating mode: shift pattern, daily peaks, planned and unplanned downtime, and whether there is manual load control.
• What has already been tried: local systems, manual schedules, procedures — and why they did not take root.
• Process constraints: what cannot be stopped or changed due to technology, regulations, or safety requirements.
• Site contact: who approves access to data and connection to equipment.

Then the work order is as follows: we compare the data with actual consumption, fix the baseline consumption level at the selected area, deploy the pilot, and compare the result with the baseline.

If the effect is confirmed, we replicate the solution to neighboring areas using the already proven scheme.

Describe your task — we will come back with an assessment and a pilot launch plan.