How the predictive maintenance module works inside Captia.ai
The module does not watch a machine: it watches the record the plant already holds about that machine. 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 network outage does not open a gap in precisely the period that would later have explained a failure. The module works on that consolidated history, with homogeneous timestamps, and on the events recorded in Captia.ai.
That second input, the events, is what separates this module from generic signal analytics. A time series on its own describes how a machine behaves, but it does not say what happened to it. An event does: a stoppage, an alert raised by a rule, a recorded intervention, a machine state change. When signal and event share the same time axis inside the platform, the history stops being a curve and becomes a case file for the asset, and a case file is something you can anticipate from.
Processing has three movements. First it establishes the reference for the machine itself: how that specific asset behaves under comparable operating conditions, because two units of the same model in the same building do not share a baseline. Second, it measures the separation between current behaviour and that reference and tracks it over time, which is what turns a one-off deviation into degradation. Third, it places that evolution against the events already recorded for the asset, so the signal is read alongside what the plant did: whether the drift started after a setpoint change or after an intervention is part of the reading.
The output is not a loose prediction on a panel. It is actionable material inside the platform itself: dashboards per asset, line, role or plant; rules and alerts when degradation crosses the agreed threshold; traceable events kept in the asset history; workflows that route the alert to whoever can act; periodic reporting for the maintenance review; and APIs towards ERP, MES, CRM or SAP when the intervention has to become a work order in the management system. The alert should end in the system where the work is executed, not in an email.
| Layer | What it contributes | Where it lives |
|---|---|---|
| Input | Equipment operating signal history, normalised into time series, plus the events recorded in the platform (stoppages, alerts, interventions, state changes) | Captia Connect (edge) and the Captia.ai history |
| Processing | Behaviour reference for the asset itself, measurement of the separation from that reference over time, and joint reading with the asset events | Predictive maintenance module over the platform industrial models |
| Output | Per-asset dashboards, rules and alerts, traceable events, intervention workflows, reporting and APIs towards ERP, MES, CRM or SAP | Captia.ai, in the same views and with the same roles maintenance already uses |
It is worth drawing the boundary with two neighbouring modules, because they get confused on the floor. The anomaly detection module answers this is not normal right now. This one answers this is getting worse and there is a window to act. And forecasting projects the future value of a variable without pronouncing on the condition of the asset. All three can run on the same machine and none replaces another.
Data requirements: what is needed before switching it on
The first requirement is that a signal from the equipment exists, and not just any signal. What is needed is the one that moves as the failure mode of concern progresses. An asset with nothing but a digital run or stop bit offers no gradient: it only separates running from stopped, and degradation lives between those two states. Which variable resolves which failure mode is an engineering decision taken during the diagnosis, and the conceptual framework sits in the industrial predictive maintenance guide, not in the module.
The second is sampling frequency. The cadence has to be enough for the phenomenon to be visible: a signal averaged hourly erases any behaviour that happens in seconds. This is decided earlier, when acquisition is configured in Captia Connect, because what was never captured cannot be recovered later.
The third is asset identification. The signal has to be tied to a specific machine, and that machine has to be stable across the history. If a single tag has designated two different units after a replacement, the history mixes two lives and the behaviour reference is contaminated. This normalisation and contextualisation work is exactly what Captia Connect does when capturing the data, and it is the part most often underestimated in a project.
The fourth, and the one most specific to this module, is the record of interventions and events. Without knowing when a machine was worked on, an improvement in the signal looks like a spontaneous recovery and a returning degradation looks like a new fault. That record can live in the platform itself as events and workflows, or arrive through API integration from the ERP or the maintenance management system. The poorer it is, the more the module is limited to describing how the signal evolves and the less it can bound the window for intervention.
The fifth is a calendar matter rather than a technical one: history has to cover the normal operating cycle of the asset, including product changeovers, planned shutdowns and seasonality where it exists. A machine whose baseline has only been observed during one campaign will raise alerts as soon as the next one starts, and those alerts will not be degradation but ignorance.
Industrial application cases
The most frequent case is the continuously running auxiliary rotating asset: compressors, pumps, fans, chillers. They are rarely instrumented like process equipment because they do not stop the line the day they fail, yet they drive consumption and quality while they degrade. Here the module provides something no inspection round can: continuity. The comparison is against the machine own past, every day, weekends included.
The second case is the bottleneck asset of a line. When a single machine sets the pace of the plant, the value is not in detecting the failure but in being able to choose when to stop. There the useful output is not the alert: it is the event in the asset history that lets production and maintenance negotiate a window with margin, and the workflow that records that decision.
The third is slow consumption drift of a machine against its own past. Equipment that needs more energy than six months ago for the same duty is saying something about its condition. This module and the energy optimisation module look at the same curve from two angles: one asks what it costs, the other asks why it is rising. Read together they usually close the diagnosis.
The fourth is the distributed fleet: several machines of the same type across different sites. The advantage is not applying one single model to all of them, which rarely works, but having the same normalised signals and the same event schema for all of them, so that comparison between units is legitimate. That homogeneity is produced by the acquisition layer, not by the model.
The fifth is the asset under an external maintenance contract. When a third party executes the work, the signal and event history in the platform is the objective basis for the conversation: what was done, when, and what happened to the signal afterwards. The module does not replace the contract, it makes it verifiable.
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. It starts with having a case file for the asset.
- Diagnosis. Asset criticality, the failure modes that genuinely matter, existing signals and available protocols. This is where you decide which machines are in scope, what is measured, at what cadence, and what instrumentation is missing. An asset whose failure carries no relevant operational consequence should stay out, however easy it is to measure.
- Edge deployment. Captia Connect on the floor, equipment and sensors connected, normalisation, buffering and persistence without connectivity. From this point history exists, and the project clock genuinely starts.
- Platform go-live. Per-asset dashboards, users and roles, and the first deterministic rules and alerts on known thresholds. This phase is not a formality before the module: it is what generates the event record the predictive layer will later live on.
- Operationalisation. Alert and intervention workflows, periodic reporting and API integration with ERP or MES so an intervention becomes a work order. This closes the loop: every alert ends with a record of what was done, and that record is tomorrow training data.
- Intelligence. With a consolidated signal history and recorded events, the predictive maintenance module is switched on. Before this point it has no past to compare against and no outcome to learn from. The engineering support that tunes thresholds and alert routing is the work of prediction and alerts.
| Output | What it requires | What it lets you decide |
|---|---|---|
| Per-asset dashboard | Signal identified per machine and a consolidated history | See how the asset evolves against its own past, without waiting for a threshold |
| Rule and alert | A threshold agreed with whoever receives the alert and a recipient by role | Turn sustained degradation into a justified interruption |
| Traceable event | That the alert and its closure are recorded in the asset history | Reconstruct afterwards what was seen, what was done and what followed |
| Workflow and API integration | A connection to ERP, MES or the maintenance management system | Make the intervention a work order rather than a conversation |
Limits and when it does not apply
This deserves stating plainly, because this is the module that raises the most expectations and accumulates the most badly framed projects. Captia.ai predictive maintenance does not apply, or adds little, in these scenarios:
- Sudden failures with no prior degradation. A brittle fracture, an instantaneous electronic failure or an operating error leave no growing trace in the signal. There is nothing to anticipate because there is no evolution to observe. Against those failure modes what protects you is design, redundancy or protection, not analytics.
- No failure or intervention history. The module can describe how a signal evolves from day one, but bounding the window for intervention requires having seen how earlier episodes ended. A plant with no record of what has happened to its equipment starts building one the day it deploys the platform, not before.
- Assets with very few running hours. Equipment that runs sporadically accumulates history by calendar, not by use. The behaviour reference takes long to form and the module spends a long time unable to tell a start-up condition from degradation.
- Instrumentation that does not cover the failure mode. Measuring a variable that does not move as the machine degrades produces noise, not prediction. What is missing here is sensing and engineering judgement, not a model. The module will make the gap visible but will not fill it.
- When there is no capacity to act. If there is no spare part, no shutdown window, no contract and no crew to respond to the alert, anticipation does not change the outcome: it only brings forward the date on which somebody knew. Before switching the module on it is worth checking that a real decision exists at the other end.
- When what is needed is a maintenance plan. Defining the strategy for a fleet, its criticalities and its policies is prior engineering and organisational work. The module feeds that plan with continuous evidence; it does not write it.
- When what is needed is understanding the discipline. If the question is how a condition indicator is chosen, what horizon makes sense or how a predictive programme is structured, the ground is the industrial predictive maintenance guide. This page describes the capability of the module, not the methodology.
And one transversal limit that applies to every AI module in the platform: the module evidences and alerts, it does not stop equipment on its own. The decision to intervene is taken by the operation, through the rules and workflows the team defines and supervises. In maintenance that separation is not a formality: an unrequested stoppage costs the same as the failure it was meant to avoid.