Anomaly Detection Demo

Tune an IoT anomaly detector and see precision, recall, false alarms, and missed events change.

animation
anomaly-detection
data-analytics
time-series
IoT-sensors
intermediate
A learner-ready anomaly detection animation with generated IoT time-series data, moving sample cursor, detection bounds, confusion matrix feedback, and technical accuracy notes.
Animation Intermediate with ramp Time series Precision and recall

Anomaly Detection Demo

Watch an IoT sensor stream move through baseline training, scoring, thresholding, and classification. Tune the detector until learners can see why catching every anomaly can also create false alarms.

-- Precision: alerts that were truly anomalous
-- Recall: true anomalies that were found
-- Balanced score across precision and recall
Balanced Current detector diagnosis

1. Start with a baseline

The first clean samples define normal behaviour. Bad training data makes the detector learn the wrong normal.

2. Score each sample

The detector turns the latest value into a deviation score: how far it is from the expected range.

3. Compare to a threshold

Lower thresholds create more alerts. Higher thresholds reduce noise but can miss subtle faults.

4. Read the tradeoff

Precision, recall, false positives, and false negatives tell whether the detector is useful for the IoT task.

1

Train

Use clean early samples to estimate the normal range.

2

Stream

A new IoT reading arrives from the device.

3

Score

Calculate deviation from the baseline or rolling window.

4

Threshold

Mark readings outside the detection bounds.

5

Classify

Separate true positives, false positives, and missed events.

6

Tune

Use metrics to choose a threshold that fits the application.

Animated sensor stream

Play or step through the stream. The shaded band is the detector's normal range, the vertical cursor is the current sample, and coloured markers show what the detector got right or wrong.

sensor reading normal range true anomaly false alarm true positive

Scenario and controls

Try a different stream, detector, threshold, and window to see how each choice changes the result.

Detector diagnosis

The detector is finding most injected events without too many false alerts.

True positives

0

Injected anomalies that produced alerts.

False positives

0

Normal readings that were flagged as abnormal.

False negatives

0

Injected anomalies missed by the detector.

True negatives

0

Normal readings correctly left alone.

A balanced detector should match the safety and cost of the application, not simply maximize one metric.
score = abs(sample - baseline mean) / baseline standard deviation
alert when score > threshold

Method behaviour

Rolling z-score follows slow changes but can also learn a slow fault if the window is too short.

Threshold tradeoff

Lower thresholds improve recall but often reduce precision by creating more false positives.

Training risk

The clean training region is shaded. If it contains faults, the detector may normalize bad behaviour.

IoT decision

Choose the tuning based on alert cost: missed freezer warming is worse than one extra warning.

Quick Reference

Precision

precision = TP / (TP + FP). It answers: when the system alerts, how often is the alert correct?

Recall

recall = TP / (TP + FN). It answers: of all real anomaly points, how many did the system catch?

F1 score

F1 = 2PR / (P + R). It is useful when precision and recall both matter, but it does not encode business cost.

Static z-score

Uses one training baseline. It is simple and stable for stationary data but weak when the normal operating level drifts.

Rolling z-score

Uses recent samples as the baseline. It adapts to drift but can be fooled by short windows and repeated anomalies.

Rolling IQR

Uses quartiles from recent samples. It is more robust to outliers than mean and standard deviation, but it still needs enough data.

Technical Accuracy Notes

No future leakage

The rolling methods score each sample using previous samples only. That better matches online IoT monitoring than using future data.

Known labels are for teaching

The orange true anomalies are injected by the demo so precision and recall can be calculated. A real deployment rarely has labels immediately.

Point labels are simplified

The demo evaluates each sample independently. Real incidents often need event-level scoring, suppression windows, and escalation rules.

Threshold is not universal

A threshold that works for vibration may be poor for temperature. Sensor noise, sampling rate, and cost of missed events all matter.

Drift is tricky

A rolling baseline can follow normal seasonality. It can also follow a slow fault, which turns an incident into the new normal.

Alert quality needs context

An anomaly score is only evidence. Good IoT systems combine sensor context, device state, maintenance history, and alert routing.

Practice 1

Set the threshold low. Explain why recall rises first, then identify where false positives start to make the detector noisy.

Practice 2

Switch from static z-score to rolling z-score on the greenhouse scenario. Which method handles drift better, and what risk does it introduce?

Practice 3

Use the cold chain scenario. Tune for recall first. Explain why missing a warming event may be more costly than sending an extra alert.