How Forecasting works inside Captia.ai
The module does one thing, and it does it on any process variable: it projects that variable's future evolution from its past behaviour. The variable can be the temperature of a furnace, the active power of a line, the level of a silo, the pressure of the compressed air network or the flow rate of a circuit. What never changes is the input: the consolidated history of that variable with its source timestamps.
It is worth being precise about what a source timestamp is, because it is the piece that separates a defensible forecast from one that merely looks like it. It is the timestamp attached to the moment the signal was read on the plant floor, not the moment the data reached the server. Captia Connect acquires the signal 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 it into time series and sends it to the platform with local buffering. That buffering is exactly why the distinction matters: when connectivity drops and comes back, a two hour block of data arrives at once. If the system dated it by arrival time, the series would be compressed and reordered, and the model would learn a dynamic that never happened. With source timestamps, that same block lands in its place and the history preserves the real spacing between samples.
From there, processing has three movements. First, reconstruction of the series on a regular time grid: aligning samples, handling gaps and deciding how to aggregate when the native sampling rate is finer than the working granularity. Second, extraction of structure: level, trend, cycles tied to the industrial calendar (shift, day of week, planned shutdown) and the dependence of the variable on its own recent values. Third, projection to a defined horizon, with an uncertainty band that widens with distance, because a forecast without a band is not a prediction but an assertion.
The output lives where the team already works: projected series shown next to the actual series in dashboards per asset, line, role or plant; rules and alerts that fire when the projection crosses a threshold before the variable actually crosses it; traceable events in the history; periodic reporting; and APIs towards ERP, MES, CRM or SAP when the projection has to feed a management system.
| Layer | What it contributes | Where it lives |
|---|---|---|
| Input | Consolidated history of the variable with its source timestamps, plus the calendar and operating context available in the platform | Captia Connect (edge) and the Captia.ai history |
| Processing | Series reconstruction on a regular grid, extraction of level, trend and cycles, and projection to the horizon with an uncertainty band | Forecasting module over the platform industrial models |
| Output | Projected series in dashboards, anticipatory rules and alerts, events, reporting and APIs towards ERP, MES, CRM or SAP | Captia.ai, in the same views the operation already uses |
All of the above is what the module does. The underlying methodological discussion (which model family suits the problem, how error is measured, which baseline has to be beaten) belongs to the industrial forecast guide: demand, energy and supply signals, and bespoke modelling work on operational data is described in advanced AI models.
Data requirements: horizon, granularity and history
Two parameters have to be fixed before switching the module on, and in this order: the horizon (how far ahead you want to see) and the granularity (at what resolution). Both come from the decision to be taken, not from the technology. If the decision is to stagger start-ups within the shift, the horizon is hours and the granularity minutes. If the decision is to schedule a maintenance stop, the horizon is weeks and daily granularity may be enough. Asking for the finest possible resolution over the longest possible horizon is the most common briefing error: it multiplies the number of points to be predicted without any decision using them.
From those two parameters the third one follows, and it is the hard requirement: how much history is needed. The practical rule is not an absolute number but a relation. The history has to cover several complete repetitions of the slowest cycle you want to reproduce. A variable with a weekly pattern needs many weeks before the model can tell the pattern from a coincidence; a variable with annual seasonality needs to have lived through those seasons. And the horizon cannot be stretched beyond what the history supports: projecting three months ahead from three months of past is extrapolation, not forecasting.
| Decision to be taken | Coherent horizon and granularity | What it demands from the history |
|---|---|---|
| Anticipate a setpoint or a threshold crossing within the shift | Horizon of hours, granularity of minutes | Fine native sampling, no long gaps and reliable source timestamps; intraday cycles must be well represented |
| Prepare the next day or the weekend operation | Horizon of days, hourly granularity | Several weeks of continuous history covering working days, public holidays and planned shutdowns |
| Schedule an intervention or size a resource | Horizon of weeks, daily granularity | History covering several complete cycles of the operating pattern and, where present, the seasonality of the plant |
Three quality conditions are then non-negotiable. The first is continuity: gaps are not neutral, an hour lost in a one minute series removes the immediate reference that short range projection leans on. The second is signal identification: a series called sensor 7 can be projected, but nobody will know which decision it supports; associating the signal with an asset, a line or an area is the normalisation work Captia Connect does. The third is homogeneity of the past: if halfway through the history the sensor was replaced, the measuring point moved or the unit rescaled, the model is learning from two different variables glued together.
Finally, context. A variable that depends on external decisions (production calendar, product mix, ambient temperature) is projected better when that context is available in the platform or integrated from ERP and MES. Without context the module still projects, but it can only rely on the inertia of the series itself.
Industrial application cases
The most direct case is threshold anticipation. A silo level approaching its minimum, a process temperature drifting towards the quality limit, an air network pressure falling towards the critical setpoint. A classic alert warns once the limit has already been crossed; with a projected series, the rule can be defined on the projection and the warning arrives with margin to act. That is the underlying change: moving from reacting to preparing.
The second case is short term energy consumption projection. Seeing where the load curve of the next few hours is heading allows start-up sequences and shiftable loads to be decided before the peak happens. It is the natural counterpart of the energy optimisation module, which looks at past consumption and its relation to activity; forecasting looks at the stretch that has not happened yet.
The third is planning resources tied to a physical variable: inflow to a treatment plant, ambient temperature driving cooling load, occupancy of an intermediate buffer. In all of them the variable is not commercial demand, it is a process magnitude, and that is why it belongs to this module.
The fourth is using the projection as a reference. Once an expected series exists, the difference between actual and projected becomes a signal in its own right: a sustained deviation from what the variable should be doing. This module is then best read together with anomaly detection, which works precisely on deviations from normal behaviour.
And one boundary that avoids confusion. If what you want to estimate is the demand the plant will have to serve, that is orders, volume to produce or material to procure, the right module is not this one but demand forecasting, which combines production histories with data integrated from ERP and MES to size production and resources. Forecasting projects any process variable from its own past; demand forecasting estimates the demand to be served. They share a mathematical family and do not share a question.
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. The decision currently taken without anticipation is identified, and from it follow the variable to project, the horizon and the granularity. The native sampling rate of the equipment is also checked: working granularity can never be finer than the sensor's.
- Edge deployment. Captia Connect on the floor, signal connected, normalisation into a time series, source timestamps and local buffering. From here on, a history fit for modelling starts to exist.
- Platform go-live. The variable appears in dashboards and observed history accumulates. The duration of this phase is set by the calendar, not by the project: you have to wait for the pattern to repeat often enough.
- Operationalisation. Rules, alerts, workflows and reporting on the actual variable, plus API integration if the data has to reach ERP or MES. The team uses the series before any projection exists.
- Intelligence. With enough history, Forecasting is activated. The projection is first compared against the simplest possible reference over an observation period, and only when it adds over that reference are rules and alerts connected to the projected series.
Limits and when it does not apply
This section saves badly framed projects. Forecasting does not apply, or adds little, in these scenarios:
- No history, or a history shorter than the cycle to be reproduced. A signal connected last week has no past to learn from. And a history that has not seen a complete cycle cannot reproduce it: it will project the stretch it knows and be wrong precisely at the turning point.
- When the process has changed. A recipe change, a new machine, a modification to the installation or a change of shift regime breaks the statistical continuity of the history. The past before the change stops being representative, and in practical terms the module returns to the first point of this list.
- When the variable is dominated by one-off human decisions. If the future value depends on someone deciding to start a line or change a setpoint, there is no pattern to extrapolate. What is needed is not a model but the data of that decision, that is, integration with planning.
- Against exogenous events with no prior signal. A sudden breakdown, a supply cut or an external incident are not written in the past of the variable. No forecast anticipates them, and promising otherwise is where this kind of project breaks.
- When granularity below the real sampling rate is requested. If the equipment delivers one value every fifteen minutes, there is no legitimate way to project minute by minute. What is missing is instrumentation or acquisition configuration, not analytics.
- When the requested horizon exceeds what the history supports. A projection to a long horizon can be computed, but the uncertainty band widens until it stops being actionable. An interval as wide as the operating range of the variable informs no decision.
- When the question is a different one. If you want to know what will have to be produced or procured, that belongs to demand forecasting. If you want to detect that something is going wrong right now, that belongs to anomaly detection. Projecting a variable is not the answer to every question about the future.
And one transversal limit, common to every module in the platform: Forecasting projects and evidences, it does not change setpoints on its own. Action on the process is decided through the rules and workflows the team defines and supervises.