How production and consumption optimisation works inside Captia.ai
The module starts from an uncomfortable fact about most plants: production and energy are managed separately, in different meetings and by different people, even though they share the same machines and the same hours. Running faster is almost never free in energy terms, and saving energy is almost never free in throughput terms. The module works exactly at that intersection: it searches for the operating point that balances production and energy consumption, using the consolidated history of both dimensions.
The raw material arrives through the same route as the rest of the platform. Captia Connect acquires the available signals at the edge over MQTT, OPC UA, Modbus TCP, Modbus RTU over RS-485, OpenWebNet, IEC 870-5-102, REST API, webhooks or CSV files, normalises them into time series and forwards them with local buffering, so a network drop leaves no gaps in the history. This module needs both families of signals at once and on the same timestamp: production signals (machine state, piece counters, rejects, changeovers) and energy signals (power and consumption of the asset or the line). Without that synchrony, any ratio between energy and units is noise.
On that history, processing follows three movements. First it builds specific consumption, that is energy per good unit produced, resolved per line, per product and per operating window, not as a monthly plant average. Second, it relates that specific consumption to the actual rate the line was running at in each period, and to the other conditions the platform already records: product, format, shift, calendar, stoppages. From that cross comes the shape of the plant curve, which rarely matches the team intuition. Third, using the industrial models and the simulation over the platform digital twin, it evaluates configurations that have not happened yet: a different nominal rate, a different start-up sequence, a different split of the plan across equivalent lines, a different time window for the same batch.
It is worth pausing on why the curve has that shape, because it is the reason the module exists. At low rates, the fixed part of consumption (compressors, extraction, lighting, HVAC, auxiliary services that do not depend on how many pieces come out) is spread over few units and kWh per unit shoots up. At high rates the losses at the other end appear: rejects rising as the machine is pushed, minor stoppages and restarts that force process conditions to be re-established, auxiliaries pulled out of their efficient range. Between the two extremes there is a band where the sum is at its lowest. That band is what the module delivers, and it is not a universal figure: it depends on the product, the equipment and the context of each installation.
The output lives inside the platform, not in a separate report: dashboards with specific consumption per asset, line, role or plant; rules and alerts when operation drifts outside the defined band; traceable events in the history so what happened can be reconstructed afterwards; periodic reporting; and APIs towards ERP, MES, CRM or SAP when the criterion has to reach planning. The Operator Layer is where that criterion becomes something the shift can read without opening a spreadsheet.
| Layer | What it contributes | Where it lives |
|---|---|---|
| Input | Production history (machine state, counters, rejects, changeovers) and energy history (power and consumption) on a common timestamp | Captia Connect at the edge and the Captia.ai history |
| Processing | Specific consumption per line, product and window; relation to the actual rate; simulation of configurations that have not occurred, over the digital twin | Optimisation module over the platform industrial models and simulation |
| Output | Recommended operating band, specific consumption dashboards, rules, alerts, events, reporting and APIs towards ERP, MES, CRM or SAP | Captia.ai, including the Operator Layer the shift sees |
The boundary with the neighbouring module is worth fixing. The energy optimisation module looks at consumption and isolates the part that does not respond to activity: overnight baseload, peaks caused by simultaneity, drift in a machine. This module assumes that consumption is already legitimate and asks a different question: given that a plan has to be produced, at what rate and with what split is it cheapest in energy without breaking it? One cuts what is avoidable, the other chooses between alternatives that are all valid. They are usually deployed in that order.
Data requirements: what is needed before switching it on
The requirement that decides whether the module makes sense is simultaneity. Having production data and energy data is not enough: both are needed over the same physical perimeter and at the same temporal resolution. Plant level energy meters against per-shift production reports do not support a useful specific consumption figure, because a shift is too coarse to separate start-up from steady state and the plant perimeter mixes lines making different things. The correct pairing is energy metering and piece counter on the same line or the same asset.
The second requirement is a clean denominator. If the piece counter does not separate good pieces from rejects, specific consumption comes out systematically optimistic, because it attributes energy to output that was never sold. Here the module depends on data that already exists on most lines (ejectors with a counter, inspection records) but that often never reaches the platform.
The third is product and format context. Comparing the specific consumption of two periods that made different references says nothing. The module needs to know what was being made in order to compare like with like, and that data usually comes from the ERP or MES integration, or from the master record already used for plant indicators.
The fourth is the observed operating range. A model cannot describe a curve in a region that has never been visited. If the line has always run at the same nominal rate, the history holds one point rather than a curve, and simulation over the digital twin starts from a poorer base. In those cases the diagnosis usually proposes short controlled trials at different rates, which is decided with production and never improvised.
The fifth is a calendar matter. As with every analytical module, enough history is needed for the plant usual conditions to be represented, including the seasonality of the thermal share of consumption, which is the part that moves most with outside temperature.
Industrial application cases
The central case is choosing the nominal rate on lines where speed is configurable. The prevailing shop-floor intuition is that faster is always better because it dilutes fixed costs, and on many lines that holds up to a point beyond which rejects and minor stoppages eat the gain and consumption per good unit turns back upwards. Locating that point with your own history rather than with a belief is an operating decision with no capital attached.
The second case is splitting load across equivalent lines or machines. Two lines making the same product almost never share the same specific consumption nor the same sensitivity to rate, because of age, retrofits or instrumentation. When a plan can be split, allocation stops being a question of availability and becomes a decision with a measurable energy consequence.
The third is batch sequencing and changeovers. A changeover does not only cost the downtime: it costs the start-up that follows, with its scrap and its energy to bring conditions back. Ordering batches to reduce the number of changeovers affects production and energy at once, and it is one of the few levers that improves both without a trade-off.
The fourth is fitting the plan into the time window. When the same volume can be made under different shift configurations, that choice has a direct effect on the baseload kept running and on the number of cold start-ups. This case is only actionable if planning takes part, because it is not decided on the line.
The fifth is tracking specific consumption as a drift indicator. When a line starts needing more energy per unit for the same product at the same rate, it is telling you something about its condition. That signal reads better alongside the predictive maintenance module, which watches the same degradation from the asset side.
All these cases sit squarely on OEE territory, because rate is exactly the variable behind the performance factor and rejects are the variable behind quality. It is worth being explicit here: this module neither computes nor explains OEE, it uses it as a constraint. The derivation of its formulas, the time cascade, the six big losses and the measurement mistakes that inflate or sink the indicator are covered in the OEE guide with the formula and a worked calculation. What the module adds is the dimension OEE deliberately leaves out: the energy cost of each point on that curve.
| Lever | Effect on rate | Effect on consumption per unit | Where it shows in Captia.ai |
|---|---|---|---|
| Raising the nominal rate | More units per hour while the line holds up | Falls at first as the fixed base is spread, rises later through rejects and minor stoppages | Specific consumption dashboards per line and product |
| Splitting the plan across equivalent lines | No change in the total, the origin changes | Depends on each line own curve, which rarely matches | Per-asset comparison and simulation over the digital twin |
| Grouping batches to cut changeovers | More time available to produce | Fewer cold start-ups and less set-up scrap | Changeover events in the history and periodic reporting |
| Concentrating the plan into fewer shifts | Same volume, narrower window | Fewer hours of baseload, more start-ups and stops | Load curve and rules on the operating window |
How it is deployed in phases
Deployment follows the general platform phases described in the industrial data platform hub, with one particularity: this module is among the last to be switched on, because it needs both data chains, production and energy, to be mature at the same time.
- Diagnosis. A double inventory: electrical measurement points and production signals available on each line. This is where the usual mismatch shows up, which is good measurement of one of the two and none of the other over the same perimeter.
- Edge deployment. Captia Connect on the floor, meters, PLCs and sensors connected, normalisation and buffering. From here on there is history on a common timestamp, which is the condition that makes the ratio possible.
- Platform go-live. Web SCADA, dashboards per asset and line, users and roles, and the first rules. The plant starts seeing its real specific consumption, and this phase already changes conversations without any model involved.
- Model and simulation. Building the digital twin of the line or of the relevant set and validating it against known historical periods. A model that cannot reproduce the past is no use for exploring the future.
- Optimisation. Exploring the operating point with the real quality, contractual and safety constraints written down, and carrying the result into rules, alerts, workflows and the Operator Layer so it reaches the shift.
The fourth and fifth phases are engineering work, not configuration: the model has to be built and validated with the people who know the process. That work is described in the industrial digital twin service.
Limits and when it does not apply
This module is very easy to mis-sell, so it is worth stating where it does not apply before a half-finished project finds out.
- When rate is not a free variable. In processes where speed is fixed by a quality recipe, a product approval or a contractual commitment, there is no operating point to search for: there is one and it is mandatory. The module can document its energy cost, which helps in negotiation or in justifying investment, but not in deciding daily operation.
- When the line is demand-saturated. If everything produced is sold and capacity is the constraint, the plant has no incentive to seek the kWh per unit minimum if that means producing less. The module remains useful as an observatory of specific consumption, but the trade-off it optimises is not in play.
- When one of the two halves of the data is missing. Energy metering without a piece counter, or a piece counter without electrical sub-metering on that line, leave the module with no ratio. What is missing then is instrumentation, and it is more honest to say so at diagnosis than to manufacture an estimate from an invented proportional split.
- When the history holds a single operating point. A line that has always run at the same rate has not generated the information needed to describe the curve. It can be completed with simulation and bounded trials, but the result carries greater uncertainty and has to be presented that way.
- When the dominant consumption does not depend on rate. In installations where most energy goes to services that run the same whether or not there is production, this module has little room and the problem belongs to energy optimisation or straight to an installation redesign, which is Captia Energy work.
- When the goal is an OEE target. Maximising OEE and minimising specific consumption do not always point the same way, and pushing the indicator can worsen the bill. If the organisation is only going to look at OEE, the module recommendation will lose every argument. That decision comes first and is a management matter, not a platform one.
And the transversal limit, shared by every module: it evidences, simulates and proposes, but it does not change setpoints on its own. Quality and safety constraints are inputs to the problem, not variables to optimise, and action on the process is carried out by the operation through the rules and workflows the team defines and supervises.