41 Time-Series Anomalies: Machine Learning
41.1 Start With the Decision
A motor can sound healthy while its vibration pattern starts to shift. A learned model must flag that shift and still show why the score rose.
41.2 Route Overview
This is part 3 of 5. Review Time-Series Anomalies: Statistical Methods for the preceding evidence.
41.3 Learning Objectives
- Select features for isolation-forest and autoencoder detectors.
- Connect a model score to a reviewable alert threshold.
41.4 Chapter Roadmap
- ML-Based Anomaly Detection
41.5 ML-Based Anomaly Detection
41.5.1 Begin With the Pattern a Rule Missed
Picture a motor whose heat, sound, and current each look normal on their own. Together they begin to shift before a fault. A learned model may find that weak pattern. The first choice is still the field decision: warn, inspect, slow down, or do nothing. Name the cost of a missed case and a false alarm.
Build a plain baseline first. Keep examples from later time or a different site for the test. Check missing, stuck, noisy, and new kinds of input. Compare the model score with the real event and with the simple rule. Save the input set, model version, score, limit, action, and fallback. An operator should be able to see why the result reached the queue.
A flexible model can catch joint patterns, but it can also learn site quirks or old faults. A high score can rank risk, but it does not name the cause. A good test set can still miss future change. Use the Practitioner layer to choose a method by the evidence need and cost. Use the Under the Hood layer to inspect training leak, drift, run limits, checks, and fallback. The deeper routes keep a useful score from becoming an unsupported fact.
41.5.2 Start With the Story
Picture an IoT team using the ideas in ML-Based Anomaly Detection 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.
41.5.3 ML Scores Subtle Patterns
Machine-learning anomaly detection is useful when the abnormal evidence is a pattern across several features, a sequence, or a learned representation of normal behavior. It should not be the first answer to every alerting problem. Start with statistical and time-series baselines, then move to ML when a simpler detector cannot represent the evidence boundary.
Before choosing a learned detector, use Figure 41.1 to match the shape of the abnormal evidence to the least complex method that can represent it.
Read Figure 41.1 from anomaly type to method and only then to placement. Point evidence begins with statistical checks; context adds time-series structure; collective or high-dimensional evidence can justify Isolation Forest, autoencoder, or sequence models. The final edge-versus-cloud branch is an operational constraint, not a model-quality ranking. This preserves the chapter's running argument: complexity is earned by the evidence boundary and must still fit latency, compute, review, and fallback requirements.
ML detectors still need a baseline, score, threshold, and review record. Isolation Forest scores how easily a point can be separated from normal examples. Autoencoders score reconstruction error after learning to reproduce normal feature vectors. Sequence models score departures from expected temporal patterns. None of these scores is operationally useful unless the feature set, training window, threshold, drift state, and sensor-health checks are kept with the alert.
The first design question is therefore not "which model is most advanced?" but "which evidence boundary do we need?" A single tank-level spike can usually be handled as a point anomaly with a robust threshold. A temperature pattern that is normal during production but abnormal during shutdown is contextual and needs mode or calendar features. A slowly worsening combination of vibration, current, and heat is collective; each feature may look acceptable alone, while the combined feature vector is drifting away from healthy operation. That is the case where ML earns its complexity, and where reviewable model evidence prevents guesswork.
ML anomaly detection is not a substitute for evidence. Treat the model score as one reviewed signal alongside context, sensor health, feature provenance, threshold policy, and operator feedback.
Isolation Forest
Good for tabular feature vectors when anomalies are rare and labeled fault examples are scarce.
Autoencoder
Good for high-dimensional normal-pattern learning when reconstruction error is explainable enough for review.
Sequence Model
Good when order and timing matter, such as vibration windows, current traces, or operating-cycle stages.
Hybrid Rule
Often best in production: simple health and safety gates first, ML score second, operator review third.
Overview Knowledge Check
41.5.4 Pick Models by Evidence Need
Before training, define the alert record. Decide which features are allowed, which period counts as normal, which maintenance events must be excluded, and how the score will be reviewed. If labeled fault examples are available, use them for evaluation, but many IoT anomaly systems begin with mostly normal data and only sparse incident labels. That makes validation examples and operator feedback essential.
Worked example: motor feature-vector detector features per 10-second window: - temperature residual after operating-mode baseline - RMS vibration - current residual - RPM stability - sensor-health flags first pass: train Isolation Forest on reviewed normal windows hold out a recent normal period for false-alert review replay known maintenance or fault windows when available alert record: window start/end, feature vector, model version, score, threshold, top contributing features, sensor-health state, and operator disposition. deployment rule: edge or gateway can compute features and cheap scores. cloud review can handle retraining, drift checks, and fleet comparison.
Make the feature vector small enough to review. If a gateway summarizes each 10-second motor window into 12 numeric features and stores 7 days at 8,640 windows per day, the review set is 12 x 8,640 x 7 = 725,760 feature values before labels and metadata. That is manageable for replay and drift plots; storing every raw vibration sample may not be.
Practitioner Knowledge Check
41.5.5 Drift and Deployment Limits
ML anomaly models are sensitive to training data. If the training period contains hidden faults, the model may learn faulty behavior as normal. If the site changes equipment, firmware, sampling rate, sensor placement, or operating modes, the model can drift. If the score is opaque, operators may ignore alerts even when the model is technically correct. A production ML detector therefore needs model governance, not just model training.
Deployment tier matters. Feature extraction and small-tree inference may fit at an edge gateway. Larger neural models, fleet comparison, retraining, and drift dashboards usually belong in cloud or offline workflows. A reliable design records where each step runs, what happens when connectivity is missing, and how alerts degrade when required features are absent.
Size the deployment path before choosing a model. A gateway with 256 MB RAM can comfortably score a compact Isolation Forest over 12 features, but it may struggle with a neural model that needs large rolling tensors and GPU-style batching. If 500 motors send one 12-feature window every 10 seconds, the fleet produces 500 x 6 x 60 = 180,000 windows per hour. Pushing all raw windows to cloud may be acceptable on Ethernet, but edge scoring plus cloud review may be cheaper on cellular or congested plant networks.
Drift review should compare both feature distributions and score distributions. For example, if median motor load rises after a process change, a stable model may suddenly score normal production as abnormal. The right response is not simply to retrain overnight. First replay a recent normal window, check whether known incidents still score high, compare false-alert volume with operator capacity, and record the approved baseline version. That makes model change a controlled release instead of a hidden dashboard adjustment.
Training Window
Normal data must be curated; hidden faults and maintenance periods should be excluded or explicitly labeled.
Threshold Policy
Score thresholds should be tuned against false-alert burden, missed incidents, and operator capacity.
Drift Monitor
Feature distributions, score distributions, and operator feedback should trigger retraining review.
Fallback Mode
If features, context, or model service are missing, the system should report degraded evidence instead of pretending certainty.
Under-the-Hood Knowledge Check
41.5.6 Anomaly Detection for IoT Systems
41.5.6.1 Start With the Story
Picture a cold-room sensor that suddenly reports a high temperature. Is the room warming, is the sensor broken, or was the door open for a delivery? Anomaly detection helps a team decide which unusual readings need review. It must also show why an alert can 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.
41.5.6.2 Anomaly Scores from Normal
An anomaly is a reading or pattern that differs from what is normal. A detector first defines normal behavior. It then gives new evidence an anomaly score, which states how unusual it is. Finally, an alert rule decides whether a person should review it. This rule matters because sensors are noisy, the setting changes, and true problems are rare.
An anomaly score is only useful when a reviewer can trace how raw evidence became an action. Figure 41.2 makes that chain visible before the worked cold-chain example adds its baseline and persistence rules.
In Figure 41.2, the Data Stream contains readings and logs. The Feature Engine turns them into values that can be compared, such as an average over time. One of three model families then scores the evidence. A Threshold is the boundary between normal, warning, and critical results. Actions state what happens next. The Feedback Loop returns the review result so the team can improve the detector. Keep the feature version, model, threshold, action, and reviewer label together.
Several cases can look alike in raw data. The process may have failed, or the sensor may be faulty. The setting may have changed. Data may be missing, a normal seasonal pattern may be present, or the threshold may fit the wrong operating mode. Keep the normal baseline, score, threshold, persistence rule, setting, and operator feedback so a reviewer can tell these cases apart.
For example, a vibration sensor sends motion readings, event counts, and maintenance logs. The feature engine turns them into an average vibration level, peak count, operating mode, and time since service. A simple detector can compare one value with a normal range. A machine-learning detector can compare several features with normal groups. The next block labels the result as normal, warning, or critical. The action block logs the evidence and baseline version as well as alerting a person. The review result then helps tune the next version.
If you only need the intuition, this layer is enough: anomaly detection is not a magic label. It is a normal baseline plus a score plus a threshold or model rule, with evidence explaining why the alert was raised and when the rule must be retested.
Point Anomaly
One reading is unusual compared with the current baseline, such as a pressure spike or impossible temperature.
Contextual Anomaly
A reading is unusual only in context, such as normal daytime power demand appearing during a closed overnight period.
Collective Anomaly
A group of individually ordinary readings forms an unusual pattern, such as synchronized drift across several zones.
Sensor Fault
A stuck, clipped, stale, or miscalibrated sensor can look like a process anomaly unless health checks are kept separate.
Overview Knowledge Check
41.5.6.3 Baseline Plus Persistence Rule
A practical first detector for a stable single sensor is a z-score or robust alternative such as median absolute deviation. That does not mean the threshold should directly page an operator. IoT signals often need persistence, hysteresis, or confirmation from related sensors so single noisy samples do not become costly alerts. For drifting or seasonal signals, move from fixed thresholds to rolling baselines, EWMA, STL residuals, ARIMA residuals, or other context-aware scores.
Worked example: simple temperature z-score alert baseline mean: 21.0 deg C baseline standard deviation: 0.5 deg C new reading: 23.0 deg C z-score: (23.0 - 21.0) / 0.5 = 4.0 candidate rule: flag a candidate when abs(z) >= 3.0 alert rule: raise an alert only if 3 consecutive readings are candidates, or if a related sensor confirms the event. why this matters: The z-score identifies an unusual point. The persistence rule decides whether it is operationally important. The detector still needs sensor-health checks for stuck, clipped, stale, or miscalibrated readings.
For a 1-minute temperature stream, three consecutive candidates means the signal must remain outside the gate for about 3 minutes before alerting. If the equipment can overheat in 30 seconds, that persistence rule is too slow; if the sensor occasionally spikes for one sample after radio reconnect, it may be exactly right. Match the rule to the process time constant, not to a generic analytics default.
Practitioner Knowledge Check
41.5.6.4 Base Rates and Alert Feedback
IoT anomaly data is usually imbalanced: normal samples dominate. That makes accuracy a weak metric, because a detector can look accurate by ignoring rare but important events. Precision, recall, false-alert rate, missed-event review, detection latency, and operator feedback are more useful for tuning. The threshold should be tied to the cost of investigation and the cost of missing an event, not copied from another site.
The base-rate arithmetic is the trap. Suppose a site produces 1,000,000 readings per day and only 20 are true process events. A detector with 90% recall catches 18 of them. If its false-positive rate is 0.1%, it also creates about 1,000 false alerts, so precision is only 18 / (18 + 1000) = 1.8%. Operators will mostly see noise even though the headline accuracy still looks excellent. Reducing the false-positive rate to 0.01% gives about 100 false alerts and precision of 18 / (18 + 100) = 15.3%, still imperfect but far more reviewable.
That does not mean "raise the threshold until alerts are rare." A threshold that hides dangerous events may improve precision while damaging recall. Under the hood, the detector needs an explicit review ledger: every alert gets a disposition such as true process fault, sensor fault, maintenance activity, expected context shift, duplicate, or unknown. Each disposition has a retest action. Sensor faults update health rules; maintenance activity updates context calendars; real misses lower a gate or add a confirming feature. Without that feedback loop, the model will drift while the dashboard continues to show familiar numbers. The review should also record who accepted the change, which baseline version changed, and what replay window proved the new rule does not break recent normal data.
Base Rate
When true events are rare, even a small false-positive rate can produce many false alerts.
Latency
Some alerts need immediate edge action; others can wait for cloud confirmation or batch review.
Drift
Normal changes over time when equipment ages, seasons change, or operating modes shift.
Feedback
Operator confirmation, dismissal, and root-cause notes are training data for better thresholds and models.
Under-the-Hood Knowledge Check
41.5.6.5 Summary
Anomaly detection defines normal behavior and scores departures from it. An alert rule then uses the score and operating setting. Start with a simple, sturdy threshold when the signal is stable. Compare actual values with expected values over time when the setting or season matters. Use a model with several inputs when one signal cannot explain the pattern. Keep sensor-health checks separate from process-fault alerts. Tune rules from review evidence rather than copied values.
An anomaly alert is useful only when it is reviewable. Preserve the baseline, score, threshold, persistence rule, context, sensor-health state, and operator feedback so the detector can be retested when normal behavior changes.
41.5.6.6 See Also
Types of Anomalies
Separate point, contextual, and collective anomalies before choosing a detector.
Statistical Methods
Use z-score, IQR, robust statistics, and control limits for edge-friendly candidate scoring.
Time-Series Methods
Use residuals, smoothing, and seasonal context when fixed thresholds are too brittle.
Anomaly Metrics
Evaluate precision, recall, false-alert burden, missed events, and latency for imbalanced alert streams.
41.5.7 Summary
ML-based anomaly detection helps when IoT evidence is multivariate, sequential, or too complex for a simple threshold. Isolation Forest is a practical first choice for tabular feature windows with few labels. Autoencoders score reconstruction error for high-dimensional normal patterns. Sequence models can help when timing and order are central to the anomaly. In every case, the deployed system must preserve feature provenance, model version, score, threshold, drift state, sensor-health evidence, and review feedback.
Use ML only when the evidence boundary justifies it. A useful ML anomaly alert is not just a score; it is a reviewable record of features, model version, threshold policy, drift checks, and sensor-health state.
41.5.8 See Also
Anomaly Detection
Connect model scores to baselines, thresholds, persistence, and alert evidence.
Types of Anomalies
Decide when the abnormal evidence is point, contextual, or collective before selecting ML.
Statistical Methods
Use simpler robust baselines before escalating to ML.
Time-Series Methods
Compare sequence models with residual and temporal-baseline methods.
41.6 Continue to the Next Part
Carry this evidence into Time-Series Anomalies: Evaluation and Types, which begins with Anomaly Detector Evaluation.