Predictive maintenance of machines & equipment

Unplanned stops of pumps, motors, compressors, spindles, conveyors or gearboxes cost production, energy, scrap and overtime. Fixed-interval maintenance replaces parts that are still healthy and still misses sudden failures. Predictive maintenance (PdM) learns the normal behaviour of each asset from vibration, temperature, current and controller data. It flags deviations weeks before a failure, names the likely fault and opens a work order at the right time. In 2026 the analytics are mature. Most projects succeed or fail on sensor coverage, alert quality and integration into the maintenance workflow, and LLM copilots now turn alerts and work-order history into instructions that technicians can follow.

Problem & value

• Today: Mittelstand plants mix reactive maintenance (run to failure), time-based servicing and occasional manual vibration rounds with handheld analysers. Expertise sits with a few senior technicians. Failures of critical assets stop entire lines.
• Cost of downtime: Siemens' True Cost of Downtime 2024 survey estimates that unplanned downtime costs the world's 500 largest companies 11% of revenue, about $1.4 trillion a year. One lost hour costs about $36,000 in FMCG and up to $2.3 million in a large automotive plant [1].
• AI value: earlier detection (weeks instead of hours), fewer unnecessary preventive jobs, planned rather than emergency repairs, lower spare-parts stock, longer asset life, and diagnostics that let less experienced staff act like vibration specialists.
• Reported results (vendor-commissioned, treat as upper bounds): an IDC study cited by IBM reports 47% less unplanned downtime, 17% longer asset life and 6.3% lower maintenance cost for Maximo customers [7]. A Forrester TEI study cited by Augury reports 310% ROI [8]. Validate these figures against your own baseline.

Variants

• Retrofit condition monitoring (SMB entry point): battery-powered wireless vibration and temperature sensors on motors, pumps, fans and gearboxes, with cloud analytics and a phone app. No PLC integration is needed.
• Process-plant / multivariate: hundreds of historian tags per asset (compressors, turbines, heat exchangers, boilers). A model learns normal behaviour across all of them and residuals flag drift. The boundary to ANOM-005 is that PdM targets asset degradation, while ANOM-005 covers process upsets.
• Machine-tool and robot health: spindle, ball-screw and axis-drive signatures taken from CNC/robot controller data. No extra sensors are needed.
• Machine builder / OEM service: connected machines at customer sites, with fleet-wide models sold as a service contract. The EU Data Act gives the machine user access rights to this data and lets them share it with third-party service providers [16].
• Mobile assets and infrastructure: rail vehicles and track, wind turbines (SCADA plus drivetrain CMS), elevators and escalators, agricultural and construction machinery, and fleet vehicles. Distinct domains are covered elsewhere: battery SoH (PRED-026), buried networks without sensors (PRED-033), civil structures (PRED-046), building HVAC (ANOM-031) and product field failures (PRED-025).
• Public sector: municipal utilities (Stadtwerke) pumping stations and wastewater plants, public transport depots, hospital technical equipment.
• Private / prosumer: essentially limited to built-in diagnostics (heat-pump or car service apps). Not a separate build target.

How it works

1. sensors / PLC / historian (OPC UA, MQTT)
2. edge gateway: buffering, resampling, FFT/envelope spectra, feature extraction
3. streaming ingestion + time-series store
4. models: (1) anomaly detection on normal behaviour (2) fault classification (3) RUL / time-to-failure (survival or degradation models)
5. alert triage: thresholds, de-duplication, context (load, product, maintenance just done)
6. human-in-the-loop: reliability engineer confirms / labels alert
7. CMMS/EAM work order, spare-part check, scheduling slot
8. feedback: confirmed findings & failure codes
9. retraining

• Anomaly detection first: real failure labels are rare, so most systems start with unsupervised normal-behaviour models (isolation forest, autoencoders, multivariate state estimation, residuals from a forecast model) for each asset or asset class.
• Diagnosis: rule-based vibration analysis (ISO 10816/20816 severity, bearing defect frequencies) combined with classifiers trained on labelled fault spectra across the vendor's fleet. Fleet-trained models are the main asset of commercial vendors.
• Prognosis (RUL): degradation curves, survival models (Weibull/Cox) or deep sequence models. RUL is reliable only for well-understood wear modes with run-to-failure history.
• LLM layer (new since 2024): explains an alert in plain language, retrieves similar past work orders and manual sections (RAG), drafts the work order and the procedure, and answers technician questions (see KNOW-004).
• Human-in-the-loop points: alert confirmation before an intervention, decisions to stop a line, and labelling of outcomes. The labels are what makes the system better over time.

Data preparation

Needed are sensor time series (vibration, temperature, current), PLC/SCADA tags and the maintenance history. In an SMB these live in machine controllers and historians (often not stored at all), the CMMS or ERP maintenance module, Excel lists and paper maintenance logs and technician notes. Typical gaps: no sensors on the critical machines, short or missing failure history, free-text failure descriptions without codes, inconsistent asset IDs between PLC, ERP and CMMS, unsynchronised timestamps, and OEM manuals only as scans.

Preparation steps: (1) pick 3-5 critical assets and map their data sources, (2) retrofit sensors where needed and collect a baseline of normal operation (weeks to months), (3) store signals centrally via OPC UA/MQTT into a time-series database (InfluxDB, TimescaleDB), (4) harmonise asset IDs and failure codes and turn paper logs into digital records, (5) label past failures and maintenance events with the technicians, (6) OCR and index manuals for a RAG assistant. Useful PREP cases: PREP-005, PREP-006, PREP-008, PREP-019, PREP-020. Also DATA-007 and DOC-014 for manuals.

Rough share of effort: 60-70 percent of the project, the highest of all steps, because labels for real failures are rare. Start with anomaly detection that needs no failure labels. See GUIDE-003.

Implementation paths

Which path for whom

• SMB — Path A: Retrofit sensor kits with a condition-monitoring dashboard from established vendors are mature and avoid building ML expertise for a few critical machines.
• Enterprise — Path C: Many assets, trade-secret production data and a shared edge and time-series platform favour an own stack with open-source tooling.
• Developer — Path C: Open-source time-series and anomaly-detection libraries on edge hardware give full control of signals and models.
• Public — Path C: Utilities, water and infrastructure operators need sovereign, on-premises operation of plant data.

Path A — Buy (recommended for most SMBs)

• Sensor + analytics bundles (fastest start): Schaeffler OPTIME (DE, EU), SKF Enlight/Axios (SE, EU), ifm moneo (DE, EU, can run on-prem), Festo AX (DE, EU), ABB Ability Smart Sensor, Augury (machine-health-as-a-service with vibration analysts) [8], Tractian.
• Industrial PdM platforms: Siemens Senseye Predictive Maintenance (DE, EU). It is vendor-agnostic, connects to existing CMMS and historians, and starts with priority assets [2]. Others: IBM Maximo Application Suite (Monitor/Health/Predict, now with AI agents for condition insight and FMEA building [7]), SAP Asset Performance Management, AVEVA PI System with predictive analytics, GE Vernova SmartSignal, AspenTech Mtell, Cognite Data Fusion (NO, EU).
• Built into machines: many OEMs (machine tools, compressors, pumps, drives) ship condition monitoring in the controller or service portal.
• Choose A when: standard rotating equipment, little in-house data-science capacity, and results needed within a quarter. Check EU hosting, on-prem/edge option, a CMMS connector, and that raw data can be exported (Data Act).

Path B — Build on cloud APIs

• Cloud building blocks change often, so check before committing: Amazon Lookout for Equipment was discontinued on 7 Oct 2026. AWS points to AWS IoT SiteWise, which has native multivariate anomaly detection since July 2025 [3][4]. Azure AI Anomaly Detector was retired on 1 Oct 2026. Microsoft points to Microsoft Fabric Real-Time Intelligence anomaly detection (preview as of 2026) or the open-source microsoft/anomaly-detector [5][6].
• Typical stack: IoT SiteWise / Azure IoT Operations / Fabric Eventhouse for ingestion (EU regions such as Frankfurt), managed ML (SageMaker, Azure ML, Vertex AI) for custom models, and Google BigQuery ML for TimesFM forecasts in production [10]. An LLM API (EU-hosted Mistral, or Claude, GPT or Gemini in EU regions) handles alert explanations and work-order drafting. The LLM never makes the shutdown decision.
• Choose B when: data already lands in a hyperscaler, you have many heterogeneous asset types, or you are a machine builder offering a fleet service.

Path C — Self-host (open source)

• Connectivity and data: OPC UA (open62541), MQTT broker (Eclipse Mosquitto, EMQX), Node-RED or Apache Kafka, a time-series DB (TimescaleDB, InfluxDB, QuestDB), Grafana dashboards, ThingsBoard as an IoT platform.
• Models: PyOD 3 (60+ outlier detectors, BSD-2) [13], scikit-learn, LightGBM/XGBoost, tsfresh features, scikit-survival / lifelines for RUL, Darts / sktime. Time-series foundation models for forecasting-residual detection: Amazon Chronos-2 (120M, Apache-2.0, covariates, Oct 2025) [9], IBM Granite TimeSeries TTM, MOMENT (MIT, includes an anomaly-detection reconstruction mode) [12], and TiRex (35M xLSTM, NX-AI Linz, EU; community licence) [11]. Note that TimesFM 3.0 weights are licensed for non-commercial use only. Use version 2.5 (Apache-2.0) or the Google Cloud route for production [10].
• Edge: ONNX Runtime or TensorRT on industrial PCs or NVIDIA Jetson. TinyML on the sensor node is covered in ROBO-011.
• LLM layer: a 7–30B open model (Mistral Small, Qwen3, Llama) with RAG over manuals and work orders, served with vLLM or Ollama.
• Hardware: HW1 is sufficient for the core analytics (CPU server or edge box). Add HW2 only if you also host the LLM copilot. Operations effort is substantial: data pipelines, model monitoring for each asset and alert tuning.

Path D — Custom training

Worth it for machine builders and large fleets: fault classifiers trained on your own labelled spectra, physics-informed or hybrid digital-twin models (simulation of the drivetrain plus ML on the residuals), and RUL models for specific wear modes. Data required: months to years of high-frequency data per asset class plus documented failures. Run-to-failure examples are scarce, so data is augmented with test-bench runs (SCI-022), simulated faults or public datasets (NASA C-MAPSS, CWRU bearing data) for pre-training. Fine-tuning a time-series foundation model on fleet data is an emerging middle path.

State of the art (2026)

• Classical methods are still competitive. The TSB-AD benchmark (NeurIPS 2024; 1,070 series, 40 algorithms) found that simple and statistical methods often match or beat neural networks. Neural models were stronger on multivariate data and foundation models on point anomalies [14]. The maintainers of the widely used Time-Series-Library warned in 2026 that many older anomaly-detection benchmarks may no longer be meaningful [15].
• Time-series foundation models (Chronos-2, TimesFM 2.5/3.0, TiRex, Moirai, Toto, MOMENT) give zero-shot forecasting baselines and residual-based detection without per-asset training. Their value is fastest onboarding of new assets rather than better diagnosis of specific mechanical faults [9][10][11][12].
• Agentic maintenance: vendors are adding LLM agents for alert explanation, root-cause suggestions, FMEA/RCM strategy building and work-order creation. Examples are IBM Maximo (Condition Insight, Alert Insights, RCM Strategy Builder) [7] and Augury's Reliability and Operations Agents [8]. PyOD 3 adds an agentic workflow for selecting detectors [13].
• Platform consolidation: hyperscalers retired stand-alone anomaly APIs in 2026 [3][5]. The capability moves into IoT/analytics platforms, so design for portability.
• Limits: false alarms erode trust quickly. Sudden failures with no precursor (electrical faults, operator error) are not predictable. Operating-regime changes (new product, speed, season) look like anomalies. RUL estimates have wide uncertainty. Retrofit sensors miss failure modes they cannot see, such as lubrication contamination without oil sensors.

Shared resources & combinations

• Same sensor/stream stack (streaming + time-series + anomaly-detection): ANOM-005 process anomalies, PRED-014 soft sensors, ANOM-031 HVAC fault detection, PRED-026 battery health, PRED-046 structural health monitoring. One OPC UA/MQTT pipeline, historian and model-serving layer on an HW1 server can serve all of them.
• Data collection: ROBO-015 inspection robots and VIS-003 drones collect thermal, acoustic and gauge readings. SPEECH-009 acoustic event detection shares audio models (audio-classification). ROBO-011 moves models onto the sensor.
• Technician layer (llm-general + embedding-text + vector-db): KNOW-004 service-manual assistant, KNOW-021 spare-part identification, SPEECH-011 hands-free voice. A single RAG stack and LLM server (HW2) can serve all of them.
• Downstream optimisation: OPT-002 schedules maintenance windows into production plans, OPT-019 dispatches field technicians, OPT-005 plans spare-part stock.
• Upstream/adjacent: PRED-025 links field failures to product quality, and SCI-022 supplies test-bench degradation data for pre-training.

Effort, cost & KPIs

• Path A: pilot on 10–30 critical assets in 4–12 weeks. Costs are wireless sensors (one-time hardware) plus a subscription per asset or per sensor. Installation and gateways are often underestimated.
• Path B: 3–6 months for an ingestion pipeline, first models and CMMS integration. Cost drivers are data volume, streaming compute and engineering time.
• Path C: 4–9 months. Mostly staff cost: data engineering, ML and OT/IT security.
• Path D: 6–18 months with a data-science team and labelled failure history.
• KPIs: unplanned downtime hours, MTBF/MTTR, OEE availability, share of planned vs. reactive work orders, maintenance cost per asset, spare-parts inventory value, detection lead time, alert precision (confirmed findings ÷ alerts) and missed failures.

People & change

Start with management and the maintenance or production lead (process owner), then bring in the technicians who know the machines: they label failures and judge alerts. IT and IT security must be involved because sensor data crosses from the OT network into IT or cloud (segmentation, remote access, GUIDE-013). Machine builders and sensor suppliers are partners for interfaces and warranty questions. The data owner of the CMMS and ERP clears access.

Works council: depends. Machine data is not personal by itself, but if it can be linked to operators, shifts or work pace (e.g. load patterns per shift), the system is objectively suited to monitor performance and §87(1) no. 6 BetrVG applies; §90(1) no. 3 requires early information on AI-supported work processes. Agree on a works agreement that machine data is not used for individual evaluation (GUIDE-004). The DPO is only needed if operator or shift data is stored.

Support AI literacy (Art. 4 AI Act) for maintenance staff: what an alert means, false alarms, limits (GUIDE-006). Pilot on one line with a few machines and run in shadow mode first. Typical concerns: fear of replaced know-how (the model supports planning, the technician decides) and alert fatigue (tune thresholds jointly). Humans approve every intervention and shutdown. See GUIDE-009 and GUIDE-008.

Risks, regulation & compliance

• EU AI Act: usually minimal risk. Advisory maintenance planning is not an Annex III use, and the Art. 4 AI-literacy duty applies. It can become high-risk if the AI system is a safety component in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity (Annex III point 2) [17]. The same applies if it is a safety component of a product under Annex I harmonisation law. Example: an automatic trip or interlock on a grid or water asset based on the model's output. Keep PdM advisory and separate from safety functions, which stay with certified protection systems.
• Machinery Regulation (EU) 2023/1230 (applies from 20 Jan 2027) adds specific requirements for safety components with self-evolving (ML) behaviour. Relevant to machine builders that embed AI-based protective functions, less so to advisory PdM [18].
• EU Data Act (applicable since 12 Sep 2025): users of connected machines can access the data the machines generate and share it with third-party repair and service providers. This affects OEM business models and contracts [16].
• GDPR: machine data is mostly not personal. Operator logins, shift-linked performance data, technician notes and location data are personal. Do not use PdM data for performance monitoring of individuals without a legal basis, and involve the works council (§87(1) no. 6 BetrVG in Germany). Data processing agreements and EU hosting apply.
• Sector rules: NIS2 and the KRITIS framework for utilities. IEC 62443 for OT security, because gateways open the OT network. Rail (ECM regulation) and aviation (EASA Part-M/CAMO) require documented, approved maintenance programmes, so an AI recommendation does not replace approved intervals without regulatory change.
• Mitigations: segmented OT/IT architecture with one-way data flow, alert review by humans, drift monitoring, documenting models and thresholds, and a vendor exit plan, since cloud services have been discontinued [3][5].

Getting started

1. Pick 10–30 critical assets using criticality analysis (cost of failure × likelihood) and record a baseline of downtime, reactive work orders and maintenance cost for each.
2. Check which data already exists (PLC tags, historian, CMMS failure codes) before buying sensors. Clean up failure codes in the CMMS.
3. Pilot one Path A bundle (e.g. Schaeffler OPTIME, SKF, ifm moneo or Senseye) on those assets for 3 months, and require CMMS integration and raw-data export in the contract.
4. Define alert handling: who confirms, response times, and how outcomes are labelled. Measure alert precision from week one.
5. Scale to more assets and add the LLM technician layer (KNOW-004) or an own model stack (Path C) once alert quality is proven.

Sources

1. Siemens — The True Cost of Downtime 2024 — https://assets.new.siemens.com/siemens/assets/api/uuid:1b43afb5-2d07-47f7-9eb7-893fe7d0bc59/TCOD-2024_original.pdf
2. Siemens — Senseye Predictive Maintenance — https://www.siemens.com/global/en/products/services/digital-enterprise-services/analytics-artificial-intelligence-services/predictive-services/senseye-predictive-maintenance.html
3. AWS — What is Amazon Lookout for Equipment (discontinuation notice) — https://docs.aws.amazon.com/lookout-for-equipment/latest/ug/what-is.html
4. AWS ML Blog — 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/
5. Microsoft Learn — What is Anomaly Detector? (retirement notice) — https://learn.microsoft.com/en-us/azure/ai-services/anomaly-detector/overview
6. Microsoft Learn — Anomaly detection in Fabric Real-Time Intelligence — https://learn.microsoft.com/en-us/fabric/real-time-intelligence/anomaly-detection
7. IBM — Maximo predictive maintenance — https://www.ibm.com/products/maximo/predictive-maintenance
8. Augury — Machine Health & Industrial AI — https://www.augury.com/
9. Amazon Science — Chronos / Chronos-2 forecasting models — https://github.com/amazon-science/chronos-forecasting
10. Google Research — TimesFM — https://github.com/google-research/timesfm
11. NX-AI — TiRex xLSTM time-series model — https://github.com/NX-AI/tirex
12. CMU Auton Lab — MOMENT time-series foundation model — https://github.com/moment-timeseries-foundation-model/moment
13. PyOD — Python outlier detection library — https://github.com/yzhao062/pyod
14. TSB-AD — Time-series anomaly detection benchmark (NeurIPS 2024) — https://github.com/TheDatumOrg/TSB-AD
15. THUML — Time-Series-Library — https://github.com/thuml/Time-Series-Library
16. European Commission — Data Act — https://digital-strategy.ec.europa.eu/en/policies/data-act
17. Regulation (EU) 2024/1689 (AI Act), Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
18. Regulation (EU) 2023/1230 (Machinery Regulation) — https://eur-lex.europa.eu/eli/reg/2023/1230/oj