What counts as an anomaly
An anomaly is a reading, or a run of readings, that does not fit what is normal for that sensor in that situation. A freezer that suddenly warms up, a pump that vibrates more than usual, or a meter that reports zero for a day are all examples. The word “unusual” does not mean “bad”. A spike might be a fault, a real event such as a door being left open, or just a glitch in the sensor. Detection finds the candidates; a person or a further check decides what they mean.
Every method works from the same idea: build a picture of normal, then measure how far a new reading departs from it.
Start with fixed limits
The simplest approach is a threshold. If a refrigerator should stay between two limits, any reading outside that band raises a flag. Thresholds are easy to understand and explain, and for many safety limits they are exactly right.
Their weakness is that “normal” often changes. A room is warmer in the afternoon than at night. A machine behaves differently when idle than when running. One fixed band either misses problems in quiet periods or sets off alarms in busy ones.
Use the recent past as the baseline
A step up is to compare each reading with the sensor’s own recent history. Two common tools are a moving average and a standard deviation. The standard deviation is a measure of how much readings typically wander around their average.
Here is a hypothetical example. Suppose a temperature sensor has recently averaged 21.0 degrees with a standard deviation of 0.5 degrees. A new reading of 24.0 differs from the average by 3.0 degrees. Dividing by the standard deviation gives 3.0 / 0.5 = 6, so the reading is six standard deviations from normal. Readings that far out are rare when the data behaves normally, so it is a good candidate for an alert. A reading of 21.8 would score 1.6 and be ignored.
Teams often use a rule such as “flag anything more than three standard deviations away”, but the right cutoff depends on the sensor and how costly a false alarm is. Using the median and the spread of the middle of the data, instead of the average, makes the baseline less affected by occasional wild values.
Allow for rhythms and seasons
Much sensor data has a pattern over time: daily cycles, weekday and weekend differences, seasonal swings. A better baseline compares a reading with what is typical for that hour and day, not with all hours mixed together. A building’s energy use at 3 a.m. should be judged against other nights, not against midday. This is one reason the way time series data is stored and labeled with timestamps matters for analysis.
Learned models
When normal behavior depends on many signals at once, hand-written rules become unwieldy. Machine learning methods can learn a baseline from historical data. A few broad families exist.
- Distance and density methods treat each moment as a point described by several measurements and flag points far from any crowded region of normal behavior.
- Clustering groups readings into typical operating modes and flags those that fit none.
- Prediction-based methods train a model to forecast the next reading from recent ones. A large gap between forecast and actual value signals something odd.
- Reconstruction methods, such as autoencoders, learn to compress and rebuild normal data. They rebuild unusual data poorly, and the size of the error becomes the anomaly score.
Most of these can be trained without examples of failures, which is useful because failures are rare and often not recorded. The tradeoff is that a score such as “0.93” is harder to explain than “six standard deviations above the recent average”.
Single points, groups and context
Anomalies come in different shapes. A single point may be a spike. A contextual anomaly is a value that would be fine at another time, such as a heater running at midday in summer. A collective anomaly is a sequence in which each reading looks fine alone but the pattern is wrong, such as a flat line where a sensor should show natural variation, which often means the sensor has frozen. Methods that look only at one value at a time miss the last two kinds.
The problem of false alarms
The hardest part in practice is balancing two kinds of error. Setting the sensitivity too high produces many false alarms, and people begin to ignore alerts. Setting it too low misses real events. There is no setting that removes both errors, so it helps to decide in advance which mistake is more costly. A freezer holding medicine justifies more sensitivity than a hallway light sensor.
Alerts become more useful when they require several consecutive unusual readings, combine signals from more than one sensor, or reach a person through well-designed sensor dashboards instead of a flood of messages.
Check the sensor before blaming the world
Many apparent anomalies are not events at all. They come from a dropped connection, a loose wire, a low battery, a drifting sensor or a unit mix-up. Basic data quality checks, such as rejecting impossible values and noting gaps, should run before any detection. Sensors that slowly lose accuracy can make the baseline itself wrong, so periodic sensor calibration is part of keeping detection trustworthy.
Where it is used
Detection of this kind supports condition monitoring of machinery, early leak or fault warnings in buildings, and the watch for odd network behavior from connected devices. It is also one input to predictive maintenance, though a flagged anomaly is only a prompt to investigate, not a prediction that something will fail.
A practical path is to begin with thresholds and rolling statistics, learn from the alerts they generate, and add learned models only where the simpler tools clearly fall short.