Equipment failures don't happen out of the blue: pressure drifting lower, or a slightly different vibration pattern precedes the failure over weeks or months. None of these is big enough to cause an incident on its own, but the trend would show that action is already necessary.
BlueScope, an Australian steel manufacturer, used to monitor their equipment through visual checks and basic low-level switches, until they introduced Siemens Senseye predictive maintenance system. Half a year after installation, one of the sensors spotted a gradual drop in hydraulic tank levels and sent a warning well before the pressure drop would be critical. The maintenance staff had enough time to investigate, find a leak and fix it into a scheduled maintenance window. Over time, predictive maintenance prevented 1,950 hours of unplanned downtime and 53 complete process interruptions for Bluescope.
The market already recognizes the value: Grand View Research states the global PdM industry was valued at $14.29 billion in 2025, and is expected to reach $98.16 billion by 2033, at a CAGR of 27.9%. Growth is driven by the growing pressure to eliminate unplanned downtime, and the integration of AI and edge computing into maintenance operations. Manufacturing and energy lead adoption today; aerospace and defense is the fastest-growing segment.
How Predictive Maintenance Works in 2026
The hard part is no longer whether a system can detect a subtle signal: it can. More importantly, the alert must reach the right technician and result in a work order, rather than stay on the dashboard. So what do we let the system handle on its own, and where is human judgement still necessary?
The Architecture Behind Modern PdM
A modern PdM system has four jobs: collect sensor data, transmit and store it reliably, run models that distinguish real signals from noise, and route alerts to the right people in time to act. Each layer depends on the one below it, and each has its own failure mode.
Layer 1 — Sensors and Data Collection
Getting sensor coverage used to be the hard part: multiple devices, cable runs, commissioning the setup resulted in a financial toll on business before the work even started. Today, a single wireless unit can measure multiple parameters at the same time, and installation has become easier as well, especially for complex or remote equipment.
But the easier it is to collect data, the more noise there is to deal with. We worked with a data center operator that had 107 sensors running on their cooling system, and one of the pumps still kept regularly failing. With more than a hundred signals available, nobody could see which of them mattered. We compared the sensor data against the failure dates, and found that only four of them consistently changed before each failure. While other ones were delivering real data reflecting the state of the system as well, this data just wasn't relevant to that particular failure.
Layer 2 — Transmission and Storage
Most PdM systems today successfully combine edge and cloud architecture. The ultimate deciding factor is whether the decision needs to happen close to the machine, or whether it requires a wider data overview.
Edge is default when it comes to high-speed or high-precision operations: servo correction, defect rejection, or safety response can't wait for a network round trip. The same applies to remote or offshore premises, or plants with inconsistent connectivity: if transmission drops, cloud models train on gaps and alerts reflect machine state from hours ago. Another major factor is data control: in heavily regulated industries like oil and gas or aerospace, data can't leave the building, so on-premise deployment is the only viable option regardless of what the scalability argument says.
Cloud is the pick where the system needs a broader view: model training across multiple facilities or long-term trend analysis need more data than a single facility can produce. But this only works if the edge is feeding the cloud consistently — without a reliable learning loop, models run stale and nobody notices until the alerts start missing things they used to catch.
Most organizations outside regulated industries end up combining both edge and cloud. This delivers value only if both layers are well-coordinated — otherwise, the edge runs stale models and the cloud trains on unreliable data.
Layer 3 — Modeling and Anomaly Detection
Most modeling failures come down to trust or time. If the system fires more alerts that the maintenance team can reasonably process, the trust erodes. If the model was accurate once deployed, but gradually became less reliable as conditions change, it can go unnoticed until something fails that the system should have caught.
Södra's three pulp-and-paper mills had 1000 sensors that produced between 300 and 500 alerts every week because the threshold-based system couldn't distinguish between natural process variation and real failure. When they showed the model what normal operations and failures looked like for each individual asset over time, they started receiving about 20 alarms per week.
We ran into both problems when we worked on adding an anomaly detection layer to a client’s monitoring platform. They already had good sensor coverage, sending vibration and temperature data to the cloud, but didn’t have labeled failure data, so we had to train the model from scratch. We assessed several algorithms, finding the most consistent one and built a retraining scheduler that updates the model every 14 days.
Layer 4 — Routing, Action, and Human Oversight
Detection is important, but the overall value of PdM deployment depends on who sees the alert and how fast they act on it. Strongest deployments combine automation and human oversight, handling routine steps automatically: routing the anomaly, drafting work order, checking spare parts and notifying the necessary team. Ambiguous and consequential cases reach human specialists, while the system should already provide them necessary context, instead of firing an alert for them to investigate.
Omya caught a developing gearbox bearing fault on one of their roller mills when vibration started drifting 0.5 to 1mm/s above the model's baseline. A case was opened, the signal tracked over several weeks, and the bearing was replaced before it failed. When the maintenance team intervened, they had a case backed by weeks of trend data.
The SCG Chemicals gas turbine case shows what happens when the system and human experts disagree. In September 2023, the system spotted an anomaly in the turbine's cooling zone and identified a stator ring as the likely source. In December, the manufacturer inspected the turbine and said it was fine. SCG Chemicals didn't force an immediate intervention, but prepared spare parts and waited for the next planned shutdown. When the machine was inspected in June 2024, the damage was confirmed. The model was right, and the incident was resolved successfully because the anomaly and its exact location were detected before the issue became visible to the manufacturer, and the machine was able to operate for eight months after detection.
The Changing Role of the Maintenance Team
PdM doesn’t remove the human maintenance work, but eliminates manual inspections, unexpected failures at 2am or chasing a fault in three systems that don’t talk to each other. That overhead is most of what maintenance teams mostly do: industry benchmarks put hands-on wrench time at 18 to 30% for most facilities, meaning 70 to 80% of a technician's day is already going to everything except the skilled work.
What’s filling the freed-up time? In a mature PdM environment, the technician spends more time reviewing what the system flagged and deciding whether action is needed, based on what they know about that specific machine or line. Sometimes the system catches a real developing fault, sometimes it’s reacting to a normal process it hasn't seen before. In the SCG Chemicals case, the anomaly flagged was so subtle that even the manufacturer's inspection couldn't see it 4 months after the initial detection. Human judgement to wait until scheduled shutdown was right, and no algorithm was positioned to make that decision.
Predictive Maintenance Trends Shaping 2026
The 2026 PdM trends are often presented as a list of separate advances: the models are getting smarter, the sensors are easier to deploy and edge computing work faster. All is true, but the major shift is integration that closes the gap between detection and action: the right alert reaches the right person with context already prepared, the response chain runs without waiting for human initiation, and the system can act on detected anomaly rather than just report it.
IoT as Operational Infrastructure
IoT sensors are the foundation the rest of the stack runs on — without reliable data coming in, there's nothing for the models to learn from and nothing for the agentic layer to act on. Sensor coverage used to be the hard part, but now entry-level kits from ifm and Tractian cost hundreds of dollars per monitored asset and are installed wirelessly within minutes. The main question now is how to make the most out of data that was already collected.
Ajinomoto's amino acid plant in Eddyville, Iowa had years of process data before they started building a predictive model, and the first task was deciding what data to keep. Shutdowns, upsets, and abnormal operating periods had to come out of the training set. A model that learns from those periods treats disruption as normal and starts flagging healthy operation as suspicious.
Once the baseline was clean, the model flagged a fluidized bed dryer whose blower motor was running harder than it should. No standard alarm had fired. The team inspected during a scheduled wash day and found the bed 80% blocked with caramelized product — cleared on schedule, not during an unplanned stoppage. The plant now avoids 10 to 15 hours of unplanned downtime per month across their monitored assets.
Edge AI — Intelligence at the Source
The more assets you monitor continuously, the more decisions need to happen faster than a cloud round-trip allows. It takes about 200 milliseconds for sensor data to travel to a cloud server and back. On a high-speed production line with built-in inspection checking 600 units per minute, a 200ms delay means 2 potentially defective items may pass through before the system can respond. On a live production line, an electrical fault needs to trigger a shutdown in under 20 milliseconds. With cloud processing taking 50 to 500ms, by the time the response comes back, the safe shutdown window is already closed.
In 2025, Siemens embedded Armv9-based AI processors directly into production line sensors. When a bearing runs above its optimal temperature range, the sensor slows the motor, rebalances the load, and activates a cooling cycle. The response happens on the chip, without the data leaving the machine.
Most industrial facilities run equipment that's decades old — machines built before wireless connectivity existed, too costly or critical to replace. Edge devices make those assets monitorable without modifying them, acting as an intelligence layer on top of existing infrastructure. Managing that layer across multiple sites and machine types is its own engineering challenge — one we've covered in depth in our guide to DevOps for embedded systems.
Agentic AI — From Prediction to Autonomous Action
At the earliest stages of PdM development, the system’s job ended at the alert, and what happened next depended on how experienced the alert recipient was, whether they hadn't missed the useful alert in a hundred false ones, or whether they were even on shift. With hundreds of assets monitored continuously and edge devices detecting faults in milliseconds, the volume of signals that need a response has outgrown what a human-initiated workflow can keep up with. Agentic AI removes this variability, and a detected anomaly now can trigger case opening, relevant data collection, drafting working order, checking spare parts and scheduling a technician.
In one research deployment at a ceramic manufacturer in Italy, the system monitored hydraulic presses, kilns, and glazing lines using four specialized agents working in sequence. Sensing agents detected equipment anomalies, reasoning agents classified the fault type and estimated remaining useful life, action agents checked spare parts availability and scheduled the repair, coordination agents managed the handoffs. The system handled 92% of decisions autonomously, escalating the remaining 8% to humans when confidence was low or safety-critical assets were involved.
The SCG Chemicals case shows what that 8% actually protects against. When the system flagged the cooling zone anomaly and the manufacturer's inspection came back clean, no autonomous workflow was positioned to resolve that contradiction. The decision to prepare spare parts and hold until the planned shutdown wasn't a routing step — it was a judgment call about whom to trust, made by a person, without a protocol that would have produced the same outcome automatically.
In agentic PdM, the boundary between what the system can handle and what needs human approval has to be defined before deployment: otherwise, instead of getting value from agentic PdM, companies replace old maintenance problems with governance ones. We've covered the practical steps for governing agentic workflows in more depth separately.
Digital Twins — Now Powered by Generative AI
A digital twin is a virtual model of physical equipment where you can simulate failure scenarios, test maintenance strategies, and train predictive models without waiting for real failures. What you can simulate is limited: the twin is only as good as the failure data it's built on — and that same ceiling determines how much an agentic system can handle autonomously. A reasoning agent classifies faults confidently only for failure modes it has seen enough times to recognize. Everything outside that boundary gets escalated to a human, which is exactly the variability agentic AI was supposed to remove.
The limitation shows when it comes to rare failures that don't generate enough training data: a turbine blade fracture that happens once in twenty years is only one example — not enough for a model to learn the pattern. Other failures are disasters you genuinely hope will never happen, which means hoping your training dataset stays empty.
Rather than waiting for rare failures to accumulate, generative models, such as GANs and diffusion models primarily, create synthetic datasets that simulate those failure conditions at scale, training a model on thousands of virtual examples of something that may have occurred once in the real world, or never. A 2026 review of 86 studies on synthetic data in predictive maintenance found this approach being used across heavy machinery and industrial processes, specifically where real failure data is too rare or too consequential to wait for.
Healthcare — Reliability as a Patient Safety Issue
West China Hospital runs one of the busiest radiology departments in the world. When their CT scanner fails unexpectedly, a patient doesn't get scanned, a procedure gets rescheduled, a clinical decision gets made without the information it needed. That's what makes equipment reliability in healthcare a different problem from equipment reliability in manufacturing.
Their CT predictive maintenance program worked from real-time data across more than two million exposures collected between 2019 and 2023. The model predicted overheating events within a 20-minute window and arcing faults roughly one to two days in advance: specific failure modes, on specific equipment, with lead times calibrated to what the clinical environment actually needs to respond.
That changes who owns the problem. "The vibration readings look slightly elevated" triggers a maintenance ticket. "This scanner has a 70% probability of an arcing fault within 48 hours" triggers a patient scheduling conversation.
SMEs — PdM Without the Enterprise Budget
A three-person maintenance team can now run a monitored plant on a modest monthly budget — the hardware is affordable, the software is subscription-based, and managed service providers handle the modeling. What takes longer is the conversation that should happen before the first alert fires: which assets get priority, who has authority to pull a machine offline, and what counts as a signal worth acting on versus background noise.
There's a business case angle that smaller operations often miss. Insurers writing equipment breakdown coverage for manufacturers treat documented sensor monitoring as a risk reduction — and price it accordingly. Operations with continuous monitoring and maintenance records qualify for premium credits that unmonitored plants don't. That discount typically runs 10 to 15% on equipment breakdown premiums. For a smaller operation scrutinizing every line of the business case, it's a return that shows up regardless of whether the system ever catches a specific failure.
Case studies
Preventing Recurrent Pump Failures in a Datacenter Cooling System
A technology company running large data centers for clients in finance, healthcare, and e-commerce had a recurring problem with a pump in their cooling infrastructure. It kept failing despite regular inspections, and every time nobody knew anything was wrong until the pump had already failed.
The client's dataset contained over 100 sensor parameters monitoring temperature, pressure, flow rates, and system behavior. The main problem was that there was no labeling connecting specific sensor readings to failure events.
We built an unsupervised anomaly detection system using Isolation Forest, ECOD, and One-Class SVM. To filter out single-algorithm noise, we established that an anomaly gets flagged only when two of them agree it's there.
Once we had failure data, we ran a correlation analysis against the known pump replacement dates and identified 4 out of 107 sensors that consistently changed behavior before each incident. The client now has a real-time monitoring system watching those 4 sensors — when the pattern appears, they get an early warning.
Real-Time Machine Monitoring and Anomaly Detection Solution
A client came to us with a condition monitoring platform that already had solid infrastructure — wireless sensors capturing triaxial vibration and velocity data, streaming via MQTT through AWS IoT Core into MongoDB. Their customers could see machine status, run time, downtime, and sensor readings in real time. None of it gave them any warning before something failed.
They needed an anomaly detection layer on top of what already existed. Six algorithms were tested against a single criterion: how consistently each one characterized normal behavior — because an inconsistent model generates false positives, and false positives are how a maintenance team learns to mute the alerts. HBOS came out ahead across all six sensor features: consistent enough to trust, light enough to run continuously.
They needed an anomaly detection layer on top of what already existed. Six algorithms were tested against a single criterion: how consistently each one characterized normal behavior — because an inconsistent model generates false positives, and false positives are how a maintenance team learns to mute the alerts. COPOD flagged near-continuously across the triaxial acceleration and velocity readings, making it effectively unusable in a live environment. HBOS produced the most stable characterization of normal behavior across all six sensor features and became the default — consistent enough to trust, light enough to run continuously.
Each machine gets its own model trained on its own sensor history, because a motor and a conveyor don't share a baseline. Models retrain automatically every 14 days so accuracy doesn't drift as conditions change without anyone having to trigger it manually.
Conclusion
Detection is the part that gets talked about. Sensors, models, accuracy rates — these are the problems the industry has largely solved, and there's no shortage of vendors ready to demonstrate them.
What happens after the alert fires is harder to talk about than the detection itself. Someone has to see it, decide it's worth acting on, and have the authority to do something about it. The system needs a defined boundary between what it handles alone and what it escalates — and that boundary needs to hold up when the model and the expert reach different conclusions. Most organizations have the detection layer working. The organizational work around it is where implementations are still catching up.
If you're still in the monitoring-and-alerting phase, get in touch to talk through what the next step looks like for your operation.
Top comments (0)