13 Time-Series Anomaly Methods

analytics-ml

anomaly

time

series

13.1 Start With the Story

Picture an IoT team using the ideas in Time-Series 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.

13.2 Time-Series Residual Scoring

Time-series anomaly detection asks whether a reading is unusual for its temporal context. A value can be normal at one hour, season, operating mode, or cycle stage and abnormal at another. The usual pattern is to forecast or decompose the expected value, compute a residual, and alert only when the residual is large enough to matter.

This makes time-series methods a natural fit for contextual anomalies in IoT: load profiles, temperature cycles, vibration windows, occupancy patterns, battery discharge, and watermarks in stream processing. The detector must record the forecast window, seasonal context, residual, threshold, missing-data handling, and latency budget.

Do not threshold raw time-series values when context defines normal. Threshold the residual after trend, seasonality, operating mode, or forecast context has been accounted for.

Time-series detectors first model temporal context, then score the residual: ARIMA-style forecasts, exponential smoothing, and STL decomposition each expose different kinds of departures.

Worked example: a freezer temperature of 6 deg C may be normal during a scheduled defrost cycle and abnormal during a steady cooling period. A raw threshold cannot tell those cases apart. A time-aware detector compares the reading with the expected value for that minute, operating mode, and recent history, then stores the residual and context that made the decision reviewable.

This is also why two identical readings can produce different decisions. A 13 kW residual at 02:00 may be suspicious if the site is normally idle, while the same raw load during a shift change may be expected. The alert should preserve the forecast horizon, context fields, residual band, data freshness, and whether the score came from a complete or provisional window. That evidence lets reviewers compare the alert with the baseline that actually existed at decision time.

Forecast Residual

Predict the next value from recent history, then score the difference between observed and expected.

STL Residual

Separate trend and seasonality, then detect spikes in the remaining residual component.

EWMA Shift

Track a smoothed baseline and flag level shifts or sustained departures from recent behavior.

Window Pattern

Compare a recent window with expected shape, lag, phase, or operating-cycle stage.

Overview Knowledge Check

13.3 Choose Temporal Baseline First

Start by asking what makes the signal predictable. If the signal has daily or weekly cycles, use a seasonal baseline or STL residual. If it has autocorrelation and stable sampling, use a forecasting residual such as ARIMA or a simpler rolling model. If it changes slowly but has sudden level shifts, use EWMA or Holt-Winters-style smoothing. If anomalies are window shapes, score windows rather than single points.

Worked example: forecast-residual alert
sensor: building power demand
time context: weekday, 02:00
forecast from seasonal baseline: 18 kW
expected residual band: +/- 4 kW
observed reading: 31 kW

residual:
31 - 18 = 13 kW

candidate rule:
flag when abs(residual) > 4 kW

alert rule:
raise an alert only if the reading is fresh, the meter health is good,
and either two consecutive residuals exceed the band or an occupancy
signal confirms the abnormal context.

Choose the method from the shape and deadline. If samples arrive every minute but the operations team can wait five minutes, a short persistence rule can suppress one-off meter noise. If a motor trip must be caught within one sample, use an edge EWMA or threshold residual and send a richer window to the gateway for review. The design should state which layer owns the first alert and which layer owns the later explanation.

Signal Pattern

Good First Method

Evidence to Preserve

Watch For

Strong seasonality

STL residual, seasonal profile, Holt-Winters, or context-specific baseline.

Seasonal period, trend window, residual, threshold, and context fields.

Missing timestamps, daylight-saving changes, holiday modes, and new schedules.

Autocorrelated series

ARIMA-style forecast residual, rolling forecast, or state-space residual.

Forecast horizon, residual band, model version, and recent history coverage.

Non-stationary drift, abrupt maintenance changes, and unstable sampling intervals.

Slow baseline drift

EWMA, adaptive control chart, or residual against a slowly updated baseline.

Smoothing factor, update policy, holdout window, and drift trigger.

Learning a real fault as normal because adaptation is too fast.

Window shape

Windowed features, dynamic time warping, shape residual, or sequence model.

Window length, stride, alignment rule, feature set, and latency budget.

Alerting too late because the window must finish before scoring.

Practitioner Knowledge Check

13.4 Sampling, Drift, and Latency

Time-series detectors rely on timestamp quality. Irregular sampling, delayed packets, clock drift, duplicated readings, and gaps change the residual. Stream deployments also need explicit watermarks or late-data policies: a detector cannot safely score a window if the window may still receive late readings. The alert record should say whether the data was complete, late, imputed, or scored in degraded mode.

Drift control is equally important. Seasonal baselines become stale when equipment, firmware, occupancy, weather, or operating policy changes. Adaptive methods can reduce false alerts, but they can also absorb a slow fault into the baseline. Production systems should separate drift monitoring from incident scoring and require baseline review after known site changes.

For a five-minute window sampled every 30 seconds, the detector expects 10 readings. If only eight have arrived when the one-minute watermark expires, the system can either score a provisional residual, wait and violate the latency budget, or mark the window as incomplete and route a sensor-health review. The chosen policy changes both alert quality and response time, so it belongs in the incident record.

Gap handling needs the same precision. Carrying the last value forward through six missing samples may hide a pump shutdown, while dropping the window may hide a short overload. A robust implementation records the gap count, imputation method, clock source, model version, and baseline id beside the residual. Reviewers can then distinguish a true contextual anomaly from an artifact of timing or missing evidence.

Latency budgets should be checked against the method. A 30-minute STL window cannot support a two-minute safety response unless an edge rule raises a provisional alert first. Conversely, a one-sample edge residual may be fast but weak, so the gateway or cloud path should attach the later context review to the same incident id instead of creating a second, disconnected alert.

Watermark

Defines when a time window is complete enough to score despite late or out-of-order events.

Gap Policy

Records whether missing samples are dropped, imputed, held, or treated as sensor-health evidence.

Latency Budget

Balances waiting for enough context against responding quickly to operational risk.

Baseline Review

Triggers retesting after maintenance, firmware updates, schedule changes, or sustained drift.

Failure Mode

Symptom

Likely Cause

Control

Late data false alert

A partial window looks abnormal, then becomes normal after delayed readings arrive.

No watermark or late-data policy.

Score only complete windows or mark low-confidence early alerts as provisional.

Baseline absorbs fault

A slow degradation stops alerting after the adaptive baseline catches up.

Update rate is too fast or training windows are not reviewed.

Freeze baselines during incidents and monitor drift separately from alert scoring.

Seasonal mismatch

Normal weekend or holiday behavior creates many alerts.

Temporal context is missing or the seasonal period is wrong.

Use context fields, calendar rules, and residual review by operating mode.

Under-the-Hood Knowledge Check

13.5 Summary

Time-series anomaly methods detect values or windows that are unusual for their temporal context. Forecast residuals, STL residuals, EWMA shifts, and window-shape scores all compare observed behavior with an expected time-aware baseline. Reliable IoT deployments must record the forecast window, residual, threshold, timestamp quality, gap policy, late-data handling, drift state, sensor-health state, and latency budget.

Key Takeaway

For temporal IoT signals, the residual is usually more useful than the raw reading. Score the departure from the expected time context, and preserve the timestamp, window, residual, threshold, and data-completeness evidence.