How Energy Optimization works inside Captia.ai
The module is not an isolated box: it is the last layer of a chain that starts at the meter and at the plant equipment. Captia Connect acquires the signals at the edge over the protocols available in the installation (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 sends them to the platform with local buffering, so a connectivity drop does not open gaps in the history. Energy Optimization works afterwards, on that consolidated history with homogeneous timestamps.
Processing has three movements. First it reconstructs the load curve: aggregate consumption and, where sub-metering exists, consumption per line, technical room or piece of equipment. Second, it relates that curve to the operating context available in the platform, because a kWh is only interpretable next to what the plant was doing at that moment: shift, calendar, machine state, recorded production. Third, on that relation it identifies where consumption does not respond to activity, which is the practical definition of avoidable consumption: baseloads that do not fall when the plant stops, overlapping start-ups that stack peaks, auxiliary equipment still running out of service, slow drifts of one machine against its own past.
The output is not an isolated number. It is operational material inside the platform itself: consumption dashboards per asset, line, role or plant; rules and alerts when a pattern repeats; traceable events in the history; periodic reports through reporting; and, if consumption has to reach management systems, API integration with ERP, MES, CRM or SAP. That is the difference between an energy analysis and a module: the result lands where the team already works, not in a separate document.
| Layer | What it contributes | Where it lives |
|---|---|---|
| Input | Electrical consumption and normalised load curves, plus the operating context available in the platform | Captia Connect (edge) and the Captia.ai history |
| Processing | Load curve reconstruction, relation to activity and detection of consumption that does not respond to that activity | Energy Optimization module over the platform industrial models |
| Output | Dashboards, rules, alerts, events, reporting and APIs towards ERP, MES, CRM or SAP | Captia.ai, in the same views the operation already uses |
Data requirements: what is needed before switching it on
The hard requirement is a consumption history with continuity and with a granularity consistent with the decision to be taken. A monthly figure from an invoice serves energy accounting, not optimisation: it cannot separate a start-up peak from a baseload. Useful granularity is the one that resolves the phenomenon you want to see, and that is decided during the diagnosis, not by default.
The second requirement is identification of what is being measured. A signal called meter 3 supports no operational conclusion. The signal has to be associated with an asset, a line or an area, which is exactly the normalisation and contextualisation work Captia Connect does when capturing the data. Without that association the module can describe the shape of the curve but cannot attribute it.
The third is activity context. Without knowing what the plant was producing, consumption is a series without a denominator. That context can come from the plant data captured by Connect or from the integration with ERP and MES. The poorer the context, the more the module is limited to detecting anomalous patterns and the less it can explain their cause.
The fourth is a calendar matter, not a technical one: enough history is needed for normal behaviour to be represented. A plant with marked seasonality has to have lived through its seasons before anyone, human or model, can say what normal means for it.
Industrial application cases
The most recurrent case is baseload outside production. Almost every plant consumes at night, at weekends or during planned shutdowns, and almost always part of that consumption is legitimate (refrigeration, servers, security) and part is not. Separating one from the other requires seeing the curve with the plant stopped, which is precisely when nobody is looking. The module makes that window observable and, with a rule, continuously watched.
The second case is demand peaks caused by simultaneity. When several machines start at once after a stop, the resulting peak responds to no process need: it is a coincidence of sequence. Seeing it in the load curve is the precondition for staggering start-ups, and that is an operating action, not an investment.
The third is the drift of a machine against its own past. A compressor or a chiller consuming more than six months ago for the same duty is telling you something, almost always about maintenance. Here the energy module and the predictive maintenance module look at the same reality from two angles and are best read together.
The fourth is specific consumption per unit produced. Crossing energy with production turns consumption into an indicator comparable across shifts, lines and periods, and it is the entry point to the production and consumption optimisation module, which no longer only observes but searches for the operating point.
How it is deployed in phases
Deployment follows the same phases as the rest of the platform, described in the industrial data platform hub, and it does not start with the module.
- Diagnosis. Inventory of existing measurement points, available protocols and network architecture. This is where you decide what is measured, at what granularity, and what sub-metering is missing.
- Edge deployment. Captia Connect on the floor, meters and equipment connected, normalisation and buffering. From this point on, history exists.
- Platform go-live. Consumption dashboards per asset, line, role or plant, users and roles, and the first rules and alerts. The plant starts seeing its load curve.
- Operationalisation. Workflows, periodic reporting and API integration with ERP or MES, so energy data reaches management without manual steps.
- Intelligence. With a consolidated history and enough context, Energy Optimization is activated. Before this point the module has nothing to work on.
Limits and when it does not apply
This is worth stating plainly, because it saves badly framed projects. Energy Optimization does not apply, or adds little, in these scenarios:
- No metering, or only aggregate metering at the main supply. If the only data is the plant total, the module can describe the global curve but cannot attribute consumption. What is missing then is instrumentation, not analytics.
- No history. A signal connected yesterday has no normal behaviour to be compared against. The module needs a past.
- When the problem is design or equipment. Oversized equipment or a badly designed installation are not corrected by reading their curve. The module will make it visible, but the fix is engineering work and belongs to Captia Energy.
- When there is no operating margin. If the process cannot vary sequence, schedule or setpoint because of quality, safety or contractual constraints, the identified avoidable consumption is not actionable. It still helps justify investment, but not to optimise daily operation.
- When what is needed is a regulatory document. A statutory energy audit or a certification has its own formal requirements. The module provides the continuous data that feeds them; it does not replace them.
And one transversal limit: the module evidences and proposes, it does not change setpoints on its own. Action on the process is decided by the operation, through the rules and workflows the team defines and supervises.