Anomaly does not mean “large value”
In a factory, an abnormal condition is often subtle. A pump may still be running while its vibration pattern changes. A temperature loop may remain inside its alarm limits while the controller output becomes increasingly active. A filling process may pass individual checks while the relationship between pressure, time and flow gradually drifts.
Traditional alarm systems are built around known limits. That is necessary, but not sufficient for many condition-monitoring problems. Machine learning becomes interesting when the process has a recognisable normal pattern but the abnormal state is difficult to define with a short list of thresholds.
Start with the process, not the algorithm
The first project decision should be the asset and failure mode. “Detect anomalies on the line” is too broad. “Detect behaviour that tends to precede seal failure on this packaging station” is much more useful.
Next, identify which signals actually describe the process. It is tempting to export hundreds of tags because storage is cheap. More data is not automatically better. Some tags duplicate one another, some are operator-entered values, some change only because the HMI is open, and some are derived from the same raw signal.
Domain knowledge is valuable here. A controls engineer can often remove half the candidate signals simply by understanding how the machine is wired and sequenced.
Define a meaningful normal operating envelope
Most industrial equipment has several normal modes. A pump at 20% load behaves differently from the same pump at 90% load. A filling machine during startup is not the same as the machine during steady production. A batch reactor changes its dynamics as the recipe progresses.
If all of those states are treated as one population, the model may learn that normal operation is “anything we have ever seen.” That makes detection weak.
Segmenting by operating mode can be more important than choosing a sophisticated model. Build the model around recipe, product family, machine state, speed range, ambient conditions or other factors that materially change the process.
Common modelling choices
Several approaches are useful depending on the data. Statistical process monitoring can work surprisingly well for stable processes. Principal Component Analysis can help with correlated multivariable data. Isolation Forest and similar methods are useful when anomalies are rare and labels are limited. Autoencoders can model complex nonlinear patterns when enough historical data exists.
The engineering question is not which model is newest. It is which method provides a sensible trade-off between detection performance, explainability, maintenance burden and computational cost.
False positives are an engineering problem
A model that raises too many alerts will be ignored. This is one of the most common reasons anomaly detection projects lose credibility.
Suppose the system flags 30 events per shift. The maintenance team may investigate the first few, discover that most are caused by normal production changes, and eventually stop looking at the alerts. Model accuracy measured offline may still appear excellent.
Alert design should therefore include persistence, hysteresis, state awareness and aggregation. A single unusual sample is not necessarily an incident. A sustained deviation across several related signals may be.
Time matters
For industrial processes, sequence often matters more than individual values. A motor current spike followed by a thermal rise followed by a slower acceleration pattern may be more informative than any one variable on its own.
That is why time windows, lagged features and sequence models are useful. Before reaching for a recurrent neural network or transformer, however, establish a baseline using simple features: mean, standard deviation, slope, range, rate of change and relationships between signals.
Build the feedback loop into the project
Anomaly detection becomes more useful when the system records what happened after an alert. Was there a maintenance intervention? Was the alert dismissed? Was a quality deviation confirmed? This information can later become a label for supervised learning.
Without feedback, the model is effectively frozen. With feedback, the organisation begins building an asset-specific knowledge base.
How to judge the first deployment
Do not judge the project on model accuracy alone. Ask whether the alert arrives early enough to matter, whether engineers can understand why it fired, whether the maintenance team trusts it and whether the system reduces unplanned work.
The best anomaly-detection projects often look almost boring on the shop floor. The screen produces a small number of useful signals, the engineer knows what to check, and the machine continues to run. That is exactly the point.
Feature design should reflect the machine
For a rotating asset, useful features may include vibration statistics, motor current, speed and load. For a thermal process, the useful signal may be a rate of change, time above a target band and the relationship between inlet and outlet conditions. A model becomes easier to validate when the features have a physical interpretation.
Thresholds still have a place
Machine learning is not a replacement for every alarm. A high-pressure trip should remain a well-defined protection function. An anomaly model is better used for the grey area around normal behaviour, where fixed thresholds either create too many alarms or miss gradual degradation.
Separate detection from diagnosis
It is useful to distinguish “this pattern is unusual” from “the bearing is failing.” The first can be supported by a broad model; the second requires stronger evidence. Keeping those outputs separate prevents a model from making a diagnosis it cannot actually justify.
Bring operators into the evaluation
Operators know which changes are normal during product transitions and which ones are genuinely unusual. Review alerts with them. A model trained without operator context often mistakes expected process transitions for faults.
Build a review loop
Every alert should have an eventual disposition: confirmed issue, normal variation, data-quality problem or false alarm. Recording that outcome is valuable because it turns the anomaly detector into a learning system rather than a static dashboard.
Choose the right baseline
A useful anomaly-detection study should compare the machine-learning model with simpler alternatives. A rolling mean, control chart or engineering threshold may already capture most of the operational value. The purpose of the model is not to win a benchmark; it is to identify changes that matter to the process.
Separate machine behaviour from data artefacts
When an anomaly appears, inspect the collector first. Network interruptions, historian gaps, PLC downloads and sensor replacement can create patterns that look abnormal but say nothing about equipment health. A production-grade detector should carry data-quality status alongside the prediction.
Make alerts explainable enough to act on
An engineer should be able to see which signals contributed to an alert and during which operating window the deviation developed. That does not require exposing every internal model weight. It requires useful evidence.
Use anomaly detection where the consequence is measurable
Good candidates are processes where an earlier intervention changes an outcome: avoiding a quality loss, reducing downtime, or preventing an unnecessary investigation. Without a practical action, the detector becomes another dashboard that competes for attention.