11 Statistical Anomaly Methods

analytics-ml

anomaly

statistical

methods

11.1 Start With the Story

Picture an IoT team using the ideas in Statistical Anomaly Methods during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.

Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.

11.2 Statistical Baseline Detectors

Statistical anomaly methods score how far a new reading is from a reference baseline. They are useful for IoT because they are explainable, cheap to run, and easy to review. The tradeoff is that each method carries an assumption about the data: symmetry, spread, sample window, stationarity, or context.

Use statistical methods first for point anomalies and simple residual checks. Do not treat them as universal anomaly detection. If normal behavior depends on time, season, operating mode, or related sensors, the statistical score must be computed against the matching context or residual, not against a global baseline.

A statistical alert should preserve the baseline window, statistic, threshold, score, sample quality, missing-data handling, and sensor-health state. Without that evidence, the alert cannot be tuned or defended.

Statistical method choice depends on signal assumptions: Z-score fits stable Gaussian-like signals, IQR handles skew and outliers, and adaptive thresholds handle drift and seasonal baselines.

Worked example: a cold-room sensor may have 200 recent normal readings with a stable mean and spread, so a z-score check is cheap enough to run on the gateway. A battery-voltage signal from an energy-harvesting node may be bounded and skewed, so an IQR fence is easier to defend. A pump current signal that changes after maintenance may need an adaptive baseline with a holdout review before new limits become trusted.

The important step is to record why the statistic was chosen. A later reviewer should be able to see whether the baseline was local to the asset, shared across a fleet, segmented by operating mode, or rebuilt after drift. Otherwise teams can mistake a method mismatch for a process fault and tune the wrong threshold.

Z-Score

Compares a value with the mean and standard deviation of a reference window. Best for roughly symmetric, stable signals.

IQR or MAD

Uses robust spread estimates so skewed data or existing outliers do not dominate the threshold.

EWMA

Smooths recent values to track gradual changes while still exposing sudden departures.

Control Limits

Monitors a process against expected variation and investigation thresholds, often with persistence rules.

Overview Knowledge Check

11.3 Choose Statistics by Signal

Start by plotting or summarizing the recent normal window. If the signal is stable and roughly symmetric, a z-score or control limit can be enough. If the signal is bounded, skewed, or already contains outliers, use IQR or median absolute deviation. If normal drifts slowly, use a rolling baseline, EWMA, or residual from a context model.

Worked example: z-score candidate
baseline mean: 21.0 deg C
baseline standard deviation: 0.5 deg C
new reading: 22.8 deg C

z = (22.8 - 21.0) / 0.5 = 3.6

candidate rule:
flag when abs(z) >= 3.0

review rule:
raise an alert only after persistence, confirmation,
or an operator-approved safety policy.

why this matters:
The score says the point is unusual under this baseline.
The alert rule decides whether the unusual point is operationally important.

Run the same reasoning against the signal shape before choosing the method. If the baseline has a few old excursions, compare the z-score decision with an IQR or MAD decision and store both scores during review. Disagreement is useful evidence: it often points to skew, stale calibration, or a baseline window contaminated by previous incidents.

Signal Condition

Good First Choice

Watch For

Evidence to Store

Stable, symmetric

Z-score, standard control limits, or EWMA residual.

Small baseline windows, zero variance, unit changes, and sensor recalibration.

Mean, standard deviation, window size, score, threshold, and persistence rule.

Skewed or bounded

IQR, median absolute deviation, percentile fences, or domain-specific bounds.

Thresholds that hide rare low-side or high-side events.

Quartiles, median, chosen fence, sample count, and clipped or stale samples.

Slow drift

Rolling baseline, EWMA, adaptive control chart, or residual against context.

Normal drift being learned too fast and real change being absorbed.

Update rate, holdout period, drift trigger, and examples accepted as normal.

Seasonal context

Context-specific baseline or residual before a statistical threshold.

Using one global baseline for several operating modes.

Context fields, selected baseline, missing-context fallback, and retest date.

Practitioner Knowledge Check

11.4 Thresholds Encode Costs

A threshold is a cost decision, not just a formula. Under a Gaussian assumption, a two-sided 3-sigma z-score rule flags roughly 0.27 percent of normal samples. That may be acceptable for one sensor sampled hourly and unacceptable for a fleet of thousands sampled every second. False alerts, missed events, latency, and investigation capacity must all shape the threshold.

Statistical detectors also fail in predictable ways. A tiny baseline window gives unstable estimates. A zero-variance window makes z-score undefined. Fast adaptation can learn an emerging fault as normal. Missing or stale samples can make a process look stable when the sensor is failing. Production code should handle these cases explicitly and report them as evidence.

The fleet-scale arithmetic is the usual surprise. If 1,000 sensors produce one scored sample per minute, the fleet produces 1,000 x 1,440 = 1,440,000 scored samples per day. A normal-data false-positive rate of about 0.27 percent is still roughly 1,440,000 x 0.0027 = 3,888 flagged normal samples per day before persistence, grouping, and operator triage. That is why a statistically rare event can still be operationally common.

Guard cases should be explicit in the implementation. If a baseline window contains 30 identical values after a sensor freeze, the standard deviation is zero and a z-score cannot be computed honestly. The detector should switch to a sensor-health alert or domain-bound check, keep the zero-variance state with the incident, and avoid presenting the result as a normal statistical anomaly.

Adaptive baselines need their own guardrail. During a pump bearing fault, vibration may rise gradually for several hours. If the rolling baseline updates every minute with no freeze rule, the abnormal trend becomes the new normal before anyone reviews it. A safer design freezes updates during open incidents, stores the held baseline id, and resumes learning only after a reviewed disposition.

Warm-Up

Do not alert from a baseline until the sample count and coverage are sufficient for the selected statistic.

Variance Guard

If spread is zero or near zero, use domain bounds, robust fences, or a sensor-health state instead of dividing by zero.

Multiple Sensors

Fleet-scale alerts multiply false-positive burden, so thresholds need fleet-level review, not only per-sensor math.

Retest Trigger

Maintenance, firmware changes, placement changes, and seasonal shifts should trigger baseline review.

Failure Mode

What It Looks Like

Likely Cause

Mitigation

False-alert flood

Operators dismiss many alerts as normal variation.

Threshold ignores base rate, season, context, or fleet size.

Use context baselines, persistence, review feedback, and alert-budget checks.

Missed slow fault

The baseline follows the fault until it looks normal.

Adaptive update rate is too fast or has no holdout review.

Limit adaptation speed, freeze baseline during incidents, and monitor drift separately.

Sensor fault treated as process anomaly

Stuck, clipped, stale, or dropout samples trigger process investigations.

Health checks are missing or run after alert escalation.

Run sensor-health checks before scoring and keep health state with the alert.

Under-the-Hood Knowledge Check

11.5 Summary

Statistical anomaly methods are the first tools to try when an IoT alert can be explained by a baseline, spread estimate, score, and threshold. Z-scores suit stable and roughly symmetric signals, robust methods such as IQR or median absolute deviation suit skewed or bounded signals, and adaptive or residual methods help when normal behavior changes. The method is only trustworthy when its baseline, assumptions, sensor-health checks, threshold, and alert burden are visible.

Key Takeaway

Choose the statistic from the signal shape, not from habit. Store the baseline, score, threshold, context, and sensor-health evidence so each statistical alert can be reviewed and retested.