Reducing false positives in industrial anomaly detection

Alarm management as a discipline exists because of this problem. Process industries learned, expensively, that operators presented with more alarms than they can act on stop treating any of them as information. The standards that followed set limits on alarm rates precisely because the failure is behavioural rather than technical.

Analytics deployments inherit that lesson and frequently ignore it. A model producing several unexplained alerts a day during commissioning teaches the control room that the new system cries wolf, and that lesson is very hard to unteach. The trust is spent in the first few weeks, usually before the system has been tuned.

The consequence is that a system with excellent detection and poor precision performs worse in practice than a less sensitive one that is believed, because alerts nobody reads have no value at all.

Unfamiliar conditions, not faults. A purely statistical model learns the relationships present in its training history and flags departures from them. On a renewable-coupled asset, conditions the model has not seen occur constantly, and the alert generated is technically correct and operationally useless. On the plants we have looked at, this is the largest single source.

Sensor problems presented as process problems. A drifting transmitter, a blocked impulse line or a failing thermocouple produce readings that are genuinely anomalous. Without a way to check readings against each other, the model reports a process event and sends an operator to investigate a healthy process.

Unmodelled operating modes. Startup, shutdown, standby, purge, regeneration and maintenance all look nothing like normal operation. If mode is not an explicit input, every transition generates alerts, and transitions are frequent on a plant that stops daily.

Correlation without mechanism. Models trained on historian data learn associations that held for reasons unrelated to causation, often seasonal or driven by a common upstream factor. When the association breaks, an alert fires about a relationship that never meant anything.

Thresholds set statistically rather than by consequence. A threshold placed at a fixed number of standard deviations produces a predictable alert rate regardless of whether those alerts matter. Consequence, not distribution, is what should set sensitivity.

A first-principles model can answer a question a statistical model cannot: is the observed combination of readings physically possible.

Conservation gives most of this for free. Mass and energy have to balance. A measured hydrogen production rate implies a current. A power input at a stated efficiency implies a heat rejection. When a set of readings cannot be reconciled with those constraints, something in the set is inconsistent, and it is not necessarily a sensor: time misalignment, an unaccounted inventory term, a missing stream, the wrong boundary or an incomplete model will all produce a residual. That is a different conclusion from the process being in trouble.

This is what turns an anomaly into a diagnosis. If a mechanism exists that would produce the observed pattern, the alert is about the plant and it can be named. If no physically possible mechanism fits, the inconsistency lies in the measurement chain or the model rather than in the process, and the candidates are a faulty reading, an unmeasured stream, a boundary error, a timing misalignment or physics the model does not carry. Both outcomes are useful. They go to different people.

It also constrains what can be claimed. A physics layer does not make detection more sensitive. It makes the alerts that survive it more likely to be worth acting on, which is the property that determines adoption. The wider comparison is set out in physics-driven AI against generic industrial analytics.

Make operating mode an explicit input. Modes are known from the control system and do not need to be inferred. Re-baselining detection for startup, standby and maintenance removes a large share of alerts. Suppressing it outright does cost sensitivity, and those are modes in which real faults occur, so re-baseline rather than blind and validate the mode-specific thresholds against events that happened in those modes.

Validate sensors against each other before trusting any of them. Redundant and related measurements can be checked for mutual consistency, and a reading that fails that check should raise an instrument alert rather than a process alert.

Set thresholds from consequence. Ask what happens if this is missed and what happens if this is raised wrongly, then set sensitivity so the ratio is acceptable. A failure mode that costs a shutdown deserves a more sensitive threshold than one that costs a small efficiency loss, and neither number comes out of a distribution.

Require an action, which is the central demand on any operator decision support system. An alert that cannot state what should be done should not reach an operator. If the system cannot name a probable cause and a response, the finding belongs in an engineering review rather than in the control room.

Two numbers matter and they trade against each other. Precision is the share of alerts that turn out to be real. Recall is the share of real events that were caught. A single accuracy figure conceals the trade-off and should be treated as a warning sign in any vendor material.

For anything a human reads on shift, precision dominates, because it determines whether the next alert is believed. Recall dominates where the consequence of missing an event is severe and the response is automated rather than human. Most plant analytics sits firmly in the first case.

Report both, per failure mode, over a defined period, with a stated definition of what counted as a real event. Aggregate figures across all failure modes are dominated by whichever mode is most common and say little about the modes that matter.

The number worth agreeing before a pilot starts is how many alerts a day the control room will accept, because that is the real constraint, and every tuning decision follows from it.