Industrial process anomaly detection from sensor data

Plants and machines emit thousands of sensor signals, but fixed alarm limits on single tags either fire constantly or miss slow, multivariate drift. Anomaly detection models learn what "normal" looks like for each asset and operating state, flag departures early and show which signals changed. Mostly classic statistical and neural time-series methods do the work; LLMs and time-series foundation models are an emerging layer for explanation and zero-shot baselines, not a replacement.

Problem & value

• Today: operators rely on static high/low limits, SPC charts and experience. Alarm floods hide real issues; gradual degradation (fouling, bearing wear, sensor drift, leaking valves) is noticed late. Fault labels are rare because failures are rare.
• AI value: unsupervised or semi-supervised models learn normal multivariate behaviour per asset and operating mode, flag early deviations, rank contributing signals and cut false alarms versus single-tag limits. Earlier detection allows planned instead of unplanned downtime and catches quality drift before scrap is produced.
• Sourced evidence: Siemens cites Vorwerk reporting an OEE improvement of around 3 to 5 % across 500 connected machines with its Insights Hub platform (vendor-reported, not independently verified) [5]. A realistic benchmark view: on the large TSB-AD benchmark (1,070 labelled series, 40 sources), simple statistical methods often match or beat complex deep models, so expectations must be set carefully [1].
• Scope boundary: forecasting remaining useful life and failure probability is PRED-006; soft sensors for quality are PRED-014; OT network attacks are SEC-015; pipe-network leaks ANOM-013; grid/energy theft ANOM-008; building systems ANOM-031. This use case is the detection of abnormal behaviour in process and machine signals.

Variants

• Discrete manufacturing: CNC, presses, robots, injection moulding, motor current/vibration signatures.
• Process industry: chemicals, food & beverage, pharma, water treatment: multivariate drift in temperature, pressure, flow, pH; batch-phase aware models.
• Rotating equipment: pumps, compressors, fans, gearboxes (condition monitoring with vibration/acoustics, see audio-classification).
• Energy plants and wind/solar: inverter, turbine and transformer monitoring.
• Edge variant: model runs on a gateway or PLC-adjacent device for millisecond latency or air-gapped sites.
• Private/maker use: small-scale (3D printers, home-lab, heat pump data) is possible with open-source tools but not a market focus.

How it works

1. sensors/PLC
2. collection (OPC UA, MQTT/Sparkplug)
3. historian / time-series DB
4. cleaning + context (operating state, recipe, tag
5. asset mapping)
6. feature windows (statistics, spectra) or raw multivariate windows
7. detector (statistical | autoencoder/transformer | foundation model)
8. score + thresholding per asset
9. alert deduplication / grouping
10. explanation (top contributing tags; LLM summary with maintenance history)
11. CMMS/MES ticket
12. human verdict (true/false alarm)
13. feedback to threshold/retraining

• Detectors: residual-based (forecast the signal, flag large error), reconstruction-based (autoencoders, transformers), density/isolation methods (Isolation Forest, kNN, PCA) and subsequence methods (Matrix Profile). Operating-state conditioning is the single most important design choice: a pump at 40 % load is not an anomalous pump at 100 % load.
• Foundation models: pretrained time-series models (MOMENT, Chronos-2, TimesFM) can give zero-shot baselines for forecasting or reconstruction-based detection; MOMENT supports anomaly detection directly and ranks highly in its own evaluation with and without fine-tuning [4]. Results vary by dataset and they are not yet the default in production.
• LLM layer: turns the alert plus top signals plus past work orders into a readable diagnosis hypothesis and checklist. The LLM never decides; it summarises.
• Human-in-the-loop: operators and maintenance engineers confirm or dismiss alerts; automatic actions on the plant (setpoint change, shutdown) must go through the existing safety/control layer, never through this model.

Data preparation

Sensor data lives in PLC/SCADA systems, process historians (e.g. PI), edge gateways and often in CSV exports on file shares; context such as recipes, shifts and work orders sits in MES, ERP or the CMMS, and maintenance notes partly on paper. Typical gaps are inconsistent or undocumented tag names, missing asset hierarchies, drifting sensor calibration, gaps and wrong timestamps across systems, no record of operating states, and almost no labelled failures. Access rights to the OT network are usually restricted for good reason.

Preparation steps: - Build a tag inventory with asset hierarchy and units; agree on data owners (see PREP-004). - Pull data through standard interfaces such as OPC UA or MQTT instead of ad hoc exports (PREP-005). - Align timestamps, resample, mark outages and maintenance periods, and add operating-state context (recipe, product, set-points). - Harvest labels from work orders and downtime logs (PREP-020) and build an evaluation set with the maintenance team (PREP-018). - Digitise paper logbooks where they hold failure history (PREP-008).

Tools: historian exports, Node-RED or n8n for ingestion, pandas/Polars for cleaning. Expect roughly half of the project effort to go into data preparation; see GUIDE-003 for a readiness check and DATA-016 for related time-series pipelines.

Implementation paths

Which path for whom

• SMB: Path A, because mature condition-monitoring and process-analytics products with EU hosting exist and the task (learn normal, alert on drift) is standard.
• Enterprise: Path C, because plant data is core know-how and sensitive, and a shared internal industrial-data platform amortises models across many assets.
• Developer: Path C, because open time-series and anomaly libraries run on edge or HW1 hardware and give full control over models and OT integration.

Path A — Buy (recommended for most SMBs)

• Industrial analytics platforms: Siemens Insights Hub (DE; Asset Health & Maintenance, Quality Prediction, Production Copilot) [5], Seeq (US; process data analytics, Agent Q assistant) [6], TrendMiner (BE/EU; self-service time-series analytics and monitoring) [7], Cognite Data Fusion (Norway; industrial data platform with asset context), AVEVA PI / CONNECT, Aspen Mtell, Honeywell Forge. Specialised EU sensor/ML vendors exist for vibration and condition monitoring (e.g. KONUX, DE, for rail switches).
• Cloud-native: AWS IoT SiteWise offers native multivariate anomaly detection (launched July 2025) as the AWS-recommended replacement for Amazon Lookout for Equipment, which is discontinued on 7 Oct 2026 [2]. Azure AI Anomaly Detector was retired on 1 Oct 2026; Microsoft points to Fabric Real-Time Intelligence anomaly detection (preview) and the open-source library [3][8].
• Choose A when: the asset class is standard (pumps, motors, compressors), you lack data-science staff, and a vendor can show results on your data in a paid pilot. Check EU data residency and OPC UA connectivity.

Path B — Build on cloud APIs

• Streaming and storage: Azure Event Hubs / Fabric Eventhouse, AWS IoT SiteWise/Timestream, Google Cloud Pub/Sub + BigQuery, in EU regions. Fabric RTI anomaly detection runs models on Eventhouse tables (up to 30 minutes per analysis, preview) [8].
• Models: AutoML/ML platforms (SageMaker, Azure ML, Vertex AI) with custom detectors; foundation models (Chronos-2 on SageMaker/AutoGluon) for forecasting-residual detection.
• LLM explanation: a frontier model via EU-region endpoint summarises alerts; send only tag names and aggregated statistics, not raw production secrets.
• Choose B when: you already have a cloud data platform and need custom logic across many sites.

Path C — Self-host (open source)

• Libraries: PyOD (BSD-2, 60+ detectors incl. time-series ones, PyOD 3 with benchmark-backed ADEngine routing) [9], TSB-AD reference implementations [1], MOMENT (MIT) [4], Chronos-2 (Apache-2.0) [10], Darts, aeon, ADTK, River for online learning. Salesforce Merlion was archived in March 2026 and should not be a new dependency. TimesFM 3.0 weights carry a non-commercial licence (check before production use) [11].
• Stack: OPC UA / MQTT broker (Eclipse Mosquitto, EMQX), InfluxDB / TimescaleDB / QuestDB, Grafana alerting, Node-RED or n8n for ticket routing, ONNX Runtime for edge deployment.
• Hardware: HW1: CPU server or industrial edge gateway suffices for classical detectors across hundreds of assets; a GPU (HW2) only for transformer/foundation-model inference at high frequency or a local LLM explainer.
• Ops effort: needs a data engineer plus a domain expert for 2-3 months initially; ongoing model monitoring.

Path D — Custom training

Worth it for fleets of identical assets (OEM machine builders): train one model family on pooled data from all machines, with operating-state conditioning, and ship it on the machine controller or gateway. Needs months of normal-operation history (high data requirement) and ideally a few labelled failure episodes for evaluation. Federated or per-site fine-tuning helps when customers will not share raw data.

State of the art (2026)

• Benchmarks: TSB-AD (NeurIPS 2024) recommends the VUS-PR metric, finds simple statistical methods often beat advanced neural nets, neural nets are promising for multivariate data and foundation models for point anomalies [1]. Be sceptical of papers using point-adjusted F1, which inflates scores.
• Foundation models: Chronos-2 (120M, zero-shot univariate, multivariate and covariate forecasting) [10], TimesFM (3.0 released Aug 2026, multivariate with covariates; non-commercial weights) [11], MOMENT for reconstruction-based detection [4]. Use them as strong baselines.
• Platform consolidation: cloud vendors retired standalone services (Lookout for Equipment, Azure Anomaly Detector) in favour of capabilities inside IoT and data platforms [2][3].
• Agentic layer: vendors add copilots (Siemens Production Copilot, Seeq Agent Q, TrendMiner Analytics Agent) that query alerts, historians and documents in natural language [5][6][7].
• Limits and failure modes: concept drift after maintenance or recipe change; contaminated "normal" training data; unknown operating states causing false alarms; sensor faults mistaken for process faults (and vice versa); no ground truth to measure recall; alarm fatigue. An anomaly is not a diagnosis.

Shared resources & combinations

• Same building blocks (anomaly-detection, time-series, streaming): PRED-006 predictive maintenance (labels from confirmed alerts become failure-prediction training data), PRED-014 soft sensors, PRED-046 structural health monitoring, ANOM-008 grid anomalies, ANOM-013 network leaks, ANOM-030 KPI anomalies, ANOM-031 HVAC fault detection.
• Data foundation: DATA-016 (tag-to-asset mapping, ISA-95/AAS models) is a prerequisite for scaling across plants.
• Complementary signals: VIS-001 visual inspection (quality camera + process sensors correlated); SEC-015 OT network monitoring to distinguish cyber manipulation from process faults.
• Regulated production: HLTH-029 batch-record review uses process excursions detected here.
• Shared infrastructure: one historian/time-series DB, one MQTT/OPC UA ingestion layer and one HW1/HW2 edge or server host can serve all of the above; an optional local LLM serves explanation for several use cases.

Effort, cost & KPIs

• Path A: weeks for a pilot on a few assets; subscription per asset/tag or per site; integration with historian is the main work.
• Path B: 2-4 months; cost drivers are data ingestion/storage volume and engineering time.
• Path C: 2-4 months with in-house skills; low licence cost, higher engineering and maintenance cost.
• Path D: 6+ months; pays off for OEMs with many identical machines.
• KPIs: precision of alerts (share confirmed by operators), lead time before failure or quality deviation, missed events found in retrospective review, alarms per operator-shift, unplanned downtime hours, scrap rate, OEE. Avoid reporting "accuracy" on unlabelled data.

People & change

Involve management for scope and budget at the start, the department lead and maintenance as process owners in the use-case definition, and IT plus information security before any OT connection, because the data path touches production networks (GUIDE-013). Data owners of historian and MES data must release sources early. Operators and maintenance staff are the daily users and should join the pilot from week one.

Works council: depends. Pure machine data does not trigger §87(1) no. 6 BetrVG, but alerts tied to shifts, operators or logins can become suitable for monitoring behaviour or performance, which the BAG treats as sufficient. In every case §90(1) no. 3 requires timely information when work processes are planned with AI; start early (GUIDE-004). Personal data is normally absent, so a DPIA is rarely needed; still ask the DPO to confirm if operator IDs are logged.

Support AI literacy of operators and maintainers with short hands-on sessions (Art. 4 AI Act, GUIDE-006). Pick one line or plant as pilot group, show which signals triggered each alert, and tune thresholds with the crew to limit alarm fatigue. Typical concerns are job security and being second-guessed by a model; address them by positioning the tool as an assistant, with humans deciding on every intervention (GUIDE-008, GUIDE-009).

Risks, regulation & compliance

• EU AI Act: depends. Pure monitoring and maintenance support is generally minimal risk. AI used as a safety component in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity falls under Annex III point 2 (high-risk) [12]. Annex III obligations apply from 2 Dec 2027 and Annex I (product-embedded) from 2 Aug 2028 under the AI Omnibus changes [13]. Anomaly detection that only alerts is usually not a safety component, but one that triggers safety functions may be.
• Machinery Regulation (EU) 2023/1230: applies from 20 Jan 2027 and adds provisions for machinery with AI-powered safety functions and cybersecurity of safety control systems [14]. Machine builders embedding such models need conformity assessment.
• Functional safety and cyber: keep the model out of the safety loop (IEC 61511 / ISO 13849 logic stays deterministic); segment OT networks (IEC 62443); NIS2 applies to many manufacturers and energy operators.
• GDPR: sensor data is mostly non-personal, but machine data linked to operators (login, shift, performance) can be personal data and trigger works-council co-determination (§87 BetrVG in Germany). Avoid per-worker performance inferences.
• Pharma/GxP: validated-system rules (GMP Annex 11) apply when alerts affect batch release.
• Mitigations: human confirmation, audit trail, drift monitoring, documented operating envelope, data-sharing contracts for OEM remote monitoring.

Getting started

1. Pick 1-3 assets with expensive downtime and good sensor coverage; document tags, sampling rates, and known past incidents.
2. Verify data quality: time sync, gaps, units, operating-state tags; get 3-12 months of history including at least one known fault.
3. Run a baseline with PyOD / TSB-AD detectors plus a vendor pilot on the same data; compare with VUS-PR and operator review rather than accuracy.
4. Route alerts into the CMMS with an operator feedback button (true/false alarm) and tune thresholds per operating state.
5. Only then scale: map tags to an asset model (DATA-016), add an LLM explainer, and review AI Act/Machinery classification if any safety link exists.

Sources

1. TSB-AD benchmark (TheDatumOrg, NeurIPS 2024) — https://github.com/TheDatumOrg/TSB-AD
2. AWS — Preserve access and explore alternatives for Amazon Lookout for Equipment — https://aws.amazon.com/blogs/machine-learning/preserve-access-and-explore-alternatives-for-amazon-lookout-for-equipment/
3. Microsoft Learn — Anomaly Detector (retired 1 Oct 2026) — https://learn.microsoft.com/en-us/azure/ai-services/anomaly-detector/overview
4. MOMENT time-series foundation model (CMU Auton Lab) — https://github.com/moment-timeseries-foundation-model/moment
5. Siemens — Insights Hub — https://www.siemens.com/en-us/products/insights-hub/
6. Seeq — https://www.seeq.com/
7. TrendMiner — https://www.trendminer.com/
8. Microsoft Learn — Anomaly detection in Fabric Real-Time Intelligence — https://learn.microsoft.com/en-us/fabric/real-time-intelligence/anomaly-detection
9. PyOD — https://github.com/yzhao062/pyod
10. Chronos forecasting (Amazon Science) — https://github.com/amazon-science/chronos-forecasting
11. TimesFM (Google Research) — https://github.com/google-research/timesfm
12. AI Act Annex III — https://artificialintelligenceact.eu/annex/3/
13. European Commission — AI regulatory framework and AI Omnibus dates — https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
14. European Commission — Machinery Regulation (EU) 2023/1230 — https://single-market-economy.ec.europa.eu/sectors/mechanical-engineering/machinery_en
15. Salesforce Merlion (archived March 2026) — https://github.com/salesforce/Merlion