KutupASP Dijital
TROpen NQ
ML

What is anomaly detection in sensor data?

Short answer

Anomaly detection learns what normal behaviour looks like in a system’s historical data, then flags observations that deviate clearly from it. On a sensor table it marks rows that look unusual. A flag is not a diagnosis: it says the process has changed, not why. Finding the cause still needs operator knowledge and maintenance records.

October 4, 20263 minKutup · ASP Dijital

Core idea

An anomaly is an observation that differs from expected behaviour. The classic approach sets a fixed low and high limit for each sensor. That is simple, but it ignores operating conditions. Anomaly detection instead has the model learn the normal state from most of the history, then score new measurements against it.

Three kinds of anomaly are commonly described. A point anomaly is a single reading far from all the others. A contextual anomaly is a value that is not wrong in itself but is wrong for its condition, such as a high temperature at low load. A collective anomaly is a run of readings that are each normal alone but form an unusual pattern together.

Methods also differ in the labels they need. Unsupervised methods learn normal behaviour from unlabelled history. Supervised methods need examples of past faults, which plants usually have few of.

Hypothetical pump example

Suppose a pump’s bearing temperature stayed between 55 and 60 °C over the last month, and its load was logged alongside it.

A fixed upper limit of 62 °C would not fire on these readings. Yet 60 °C at 20 % load may still be unusual. Assume a simple linear relation learned from the same month predicts about 50 °C at 20 % load. The observed 60 °C is then 10 °C above the prediction. That gap is a deviation the model should report. It is not proof of a bearing fault, because a change in cooling flow or a sensor shift would produce the same gap.

Limits and common mistakes

An anomaly is not the same as a fault. A flag shows departure from normal and nothing more. A sensor drift, a valve change, a new product or a shift handover can each create one.

Common mistakes follow. If the training window already contains a failure period, the model learns that failure as normal. If start-up, shutdown and product changes are mixed into one model, every mode change raises an alarm. And if the process drifts over months while the model stays frozen, it keeps judging today’s plant against last year’s normal.

Follow-up questions

Do I need labelled failure data for anomaly detection?

No. Unsupervised methods learn normal behaviour from unlabelled history and flag departures. Labelled failures help when they exist, but they are usually few and inconsistently recorded. Maintenance logs can serve as a rough check, though they are an imperfect label source and should be treated as one.

What does an anomaly score tell me?

A score measures how far an observation sits from the behaviour the model considers normal. A threshold then decides which scores raise an alert. Its level should be chosen by weighing false alarms against missed events. The direction of the score depends on the method, so read the library documentation before setting a limit.

Sources

Example numbers are hypothetical, not measured field results.

Read the full guide.

Full library

Related questions

All questions
How can I detect sensor drift in an industrial process?CUSUM, EWMA or Shewhart: which should I use, and when?How does Isolation Forest work for sensor anomaly detection?What are Hotelling T2 and SPE in multivariate process monitoring?How do I reduce false alarms in an anomaly detection model?How do I split time series data into training and test sets?