How anomaly detection works inside Captia.ai
The module identifies deviations from the normal behaviour of a signal or an asset. The load-bearing phrase in that definition is not deviation, it is normal behaviour: the module does not compare against a figure somebody typed into a screen, it compares against the asset's own past. That past exists because 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 drop does not open a gap the model would later read as an event.
On that normalised history the module does three things. First it builds a reference of normality per signal and per asset, which is not a flat average but an expected behaviour conditioned on the moment: hour, day of week, shift, machine state and operating regime wherever that context is available in the platform. Second, it measures how far the current observation departs from that reference and produces a deviation score, continuous rather than a yes or no. Third, it decides which deviations deserve to become an event: score above a level, persistence over time and, where applicable, agreement between several signals of the same asset.
That third step is what separates a useful detector from a noise generator. An instantaneous deviation on a single signal is almost never a finding; a moderate deviation sustained for hours across two coupled signals of the same machine almost always is. Sensitivity is not an internal technical setting, it is an operating decision: how many notifications per shift the team is willing to review, and what it costs not to look.
The output lives where the plant already works: traceable events in the history, alerts and rules when a pattern repeats, dashboards per asset, line, role or plant, workflows for the review loop, periodic reporting and APIs towards ERP, MES, CRM or SAP. There is no separate report anybody has to go and find.
The boundary between a threshold rule and anomaly detection
Rules and alerts are a native Captia.ai capability and depend on no AI module. The boundary is worth understanding, because the most expensive mistake in these projects is paying for analytics to solve something a comparison already solved. A threshold rule encodes knowledge that already exists: somebody knows that above 85 degrees there is risk, and writes it down. It is explainable, auditable, immediate and needs no history. Anomaly detection covers the opposite case: nobody knows which value is bad, or the bad value depends on context, or the fault does not show in the level of the signal but in its shape, its rhythm or the relationship between several signals.
| Criterion | Threshold rule | Anomaly detection |
|---|---|---|
| Where the criterion comes from | Plant knowledge: setpoint, nameplate limit, process specification | The asset own history, conditioned on the operating context |
| What it needs before it works | The signal connected and an agreed limit value | Enough history for the asset normality to be represented |
| What it detects well | Breaches of a known, stable limit | Changes in shape, slow drifts and abnormal combinations across signals |
| Where it fails | Faults below the threshold and conditions that depend on the operating regime | Failure modes with no precedent in the history and signals dominated by noise |
| Explainability to the operator | Total: the value exceeded the limit | Relative: the signal departs from its pattern, and you must show what it is compared to |
| Maintenance cost | Revisiting the threshold when the process or the product changes | Watching false positives, retuning sensitivity and retraining after process drift |
The two capabilities coexist, and the right order is outside in: first the rules that encode what the plant already knows, then anomaly detection for the territory the rules do not cover. The loop closes when a repeated anomaly is understood, given a name and turned into an explicit automated rule: from that moment it is no longer a finding, it is a control. In that sense anomaly detection is a factory of future rules.
Data requirements: what is needed before switching it on
The first requirement is a continuous history with homogeneous timestamps. Gaps are not neutral: a series with unflagged acquisition outages teaches the model that zero is a possible process state, and after that zero stops surprising it. Telling a stopped machine apart from a datum that never arrived is the acquisition layer's job, not the module's.
The second is a sampling rate consistent with the time constant of the phenomenon. A thermal drift over days is perfectly visible at one-minute sampling; cavitation or a torque spike is not, no matter how much analytics you apply, because the phenomenon is no longer in the data. Granularity is decided during the diagnosis, signal by signal, according to what you want to be able to see.
The third is signal identification. A series called AI_07 lets you detect that something changed, but not say which asset did it or notify the right person. Associating every signal with an asset, a line or an area is part of the normalisation Captia Connect performs, and it is the condition for the event to be actionable.
The fourth is operating context. Without knowing whether the machine was running, idling, changing over or under maintenance, a good share of the detected deviations will be legitimate transitions. That context can come from the plant data itself or from the integration with ERP and MES, and it is what allows each moment to be compared against its own normality rather than against an average that blends different regimes.
The fifth is a calendar matter. A plant with marked seasonality has to have lived through its seasons before anyone, human or model, can say what normal means for it. Switch the module on in winter with winter-only history and the first heatwave will produce a flood of events that are not breakdowns but summer. There are two legitimate ways out: wait for the full cycle, or bring the exogenous variable that explains the seasonality (ambient temperature, campaign calendar) into the context, so the reference of normality is conditioned on it instead of ignoring it.
The sixth is not data but a commitment: somebody has to review the events. A detector whose notifications nobody classifies cannot improve, because the information about what was real and what was not simply does not exist. The discipline of labelling, review and retraining belongs to the model lifecycle, and is developed in the industrial MLOps guide.
Industrial application cases
In practice, what a plant calls an anomaly is four different phenomena that are detected differently and produce different outputs in the platform. Confusing them is the usual reason a detection project disappoints.
| Type | How it shows in the signal | Shop floor example | Useful output |
|---|---|---|---|
| Point anomaly | An isolated value far from the usual range of that signal in that context | A current spike on a start-up that should not have one | Event in the history and immediate alert if it persists |
| Contextual anomaly | A value that is normal in absolute terms, abnormal for the moment or the regime | Production-level consumption on a Sunday with the line stopped | Context-conditioned alert and a review of the operating calendar |
| Collective anomaly | A stretch whose shape or rhythm departs, even though no single value is extreme | A machine cycle lengthening steadily without breaching any limit | Event over the whole stretch and comparison against previous cycles |
| Relational anomaly | A break in the expected relationship between two or more signals of the same asset | Flow falling while pressure and consumption hold steady | Event at asset level rather than signal level, notified to the equipment owner |
One cross-cutting and distinctly unglamorous case deserves its own mention: the anomaly of the instrument itself. A signal frozen at its last valid value, a drifting sensor or a saturating transmitter are, statistically, abnormal behaviours, and the module detects them just as it detects a process fault. Watching instrumentation health is often the module's first return, because bad data does not merely fail to help: it contaminates everything built on top of it.
When the detected deviation points to progressive deterioration of rotating equipment, the natural ground is the predictive maintenance module, which goes beyond flagging the deviation and estimates its evolution. When it points to consumption that does not respond to activity, the right angle is energy optimisation. Anomaly detection is the general surveillance layer that makes the problem visible; diagnosis and action live in whichever module applies, and the design of the notification loop is addressed by the prediction and alerts solution.
How it is deployed in phases
Deployment follows the phases of the industrial data platform and never starts with the module. Switching a detector on from day one is the fastest way to burn the shop floor team's trust.
- Diagnosis. Inventory of signals and critical assets, available protocols, granularity required per phenomenon and, above all, what you want to be able to detect. This is also where you decide what a rule already covers and needs no model.
- Edge deployment. Captia Connect on the floor, normalisation, buffering and persistence without connectivity. From this point on there is history of sufficient quality to talk about normality.
- Rules and alerts first. Everything the plant already knows is encoded as a rule in Captia.ai. This is not a wasted preliminary step: it defines the baseline the module will have to add something different to.
- Shadow observation period. The module is enabled on a bounded set of assets and raises events that are logged but wake nobody up. You review what it would have flagged, how many times a day and with what proportion of hits acknowledged by the team. This is the moment to tune sensitivity, persistence windows and event grouping.
- Promotion to alerts with a recipient. Only when the noise is acceptable are events wired to alerts and workflows, with a named owner per notification type and a loop for marking false positives. Without a recipient there is no alert worth raising.
- Operation and lifecycle. Periodic reporting, review of the false positive rate, consolidation into rules of the anomalies already understood, and retraining when the process drifts. That last point is permanent, not a phase that closes.
Limits and when it does not apply
This section saves badly framed projects. Anomaly detection does not apply, or adds little, in these scenarios:
- When a rule already solves it. If a known, stable, process-justified limit exists, the right answer is a threshold rule: cheaper, faster and explainable to any auditor. Adding a model on top only introduces uncertainty where there was certainty.
- With no history, or with unrepresentative history. A signal connected this week has no normality to be compared against. Worse still: a history containing an unflagged faulty period teaches the module that the fault is the norm.
- When the relevant failure has no precedent. The module learns from what has happened. A catastrophic failure mode that has never occurred, or whose signature is absent from the instrumented signals, will not be found by analysing the history. What belongs there is a failure mode analysis and, most likely, more instrumentation.
- When the process changes constantly without recorded context. A plant alternating products, recipes and regimes without those changes reaching the data produces a steady stream of legitimate deviations. The module cannot tell a changeover from a fault if nobody tells it there was a changeover. What is missing there is context, not algorithm.
- When the signal is dominated by noise or by instrument resolution. If the real variation of the phenomenon is smaller than the measurement step or the background noise, no model recovers what the sensor never captured. The problem is instrumentation.
- When nobody will review the notifications. A detector without a review loop degenerates within weeks: notifications get muted, the team stops looking and the model never receives the information it needs to improve. Better not to switch it on than to switch it on without a recipient.
- When what you want is the cause. The module tells you that the behaviour departs and what it is compared against. It does not tell you why. Root cause diagnosis is engineering work on that evidence, and often work for whichever specialised module applies.
Three limits deserve their own treatment, because they decide whether the deployment succeeds.
False positives. They are not a defect to be eliminated, they are a parameter to be chosen. Lowering the score that triggers an event raises detection and raises noise; raising it does the opposite. The right point depends on the relative cost of the two errors on that specific asset: checking an accessible pump in vain costs little, missing the failure of a machine with no spare costs a great deal. That is why sensitivity is set asset by asset with the maintenance owner, not globally.
Seasonality. Almost every industrial signal carries several superimposed cycles: the machine cycle, the shift, the week and the year. A detector that ignores periodicity flags every Monday morning. The right alternative is not to raise the threshold until they go quiet, but to condition the reference of normality on the moment and on the exogenous variables that explain it.
Process drift. An asset's normality expires. A change of raw material supplier, a mechanical modification, a new setpoint or plain ageing shift the behaviour without any fault occurring. If the model is never revisited, it will mistake the new regime for a permanent failure, and the team will learn to ignore it. Monitoring that drift and the criteria for retraining are described in the industrial MLOps guide.
And one transversal limit: the module evidences, it does not act. Stopping or modifying a process is done by the operation, through the rules and workflows the team defines and supervises. That separation between detection and actuation is deliberate in an industrial environment.