⚡The answer up front: when it works and when it does not
Predictive maintenance is one of the few industrial AI use cases with a genuinely long production history. Vibration analysis on rotating equipment has been saving plants money for decades; what machine learning added is the ability to fuse many weak signals — temperature drift, current draw, acoustic patterns, oil quality, operator notes — into an earlier and more specific warning than any single threshold alarm.
It works best on equipment that is expensive when it fails, fails with detectable precursors, and runs often enough to generate data. It works poorly on equipment that fails catastrophically without warning, on lines with almost no instrumentation, and in plants where the maintenance team will not act on a model output because nobody closed the loop into the work-order system.
The uncomfortable truth most vendor decks skip: the model is usually the cheapest and easiest part. The data plumbing, the sensor retrofit, the CMMS integration, and the change management with a maintenance crew that has seen three failed "digital initiatives" already — that is where the budget and the timeline actually go.
| Condition | Predictive maintenance works | Predictive maintenance struggles |
|---|---|---|
| Asset criticality | High — downtime is measured in thousands per hour | Low — run-to-failure is cheaper |
| Failure modes | Gradual degradation with sensor-visible precursors | Instantaneous failure with no warning signature |
| Instrumentation | Machines already sensorized or retrofittable | No data path off the machine |
| Failure history | Months to years of labelled or semi-labelled events | Brand new line, no history, rare failures |
| Maintenance process | CMMS in use, planners act on priority lists | Paper work orders, tribal knowledge |
| Team | A reliability engineer who owns the program | Project assigned to IT alone |
📡The sensor and IoT data foundation
Every successful program starts with an unglamorous question: what data can you actually get off the machines that matter, at what rate, and at what cost? Modern PLCs and CNC controllers expose far more than plants typically collect — spindle load, axis temperatures, cycle counts, alarm codes. Older equipment needs retrofit sensors, and the retrofit decision is economic: a wireless vibration sensor per motor might cost a few hundred dollars installed, while hardwiring into a legacy panel can cost ten times that once an electrician and downtime window are involved.
Sampling rate matters more than most teams expect. Slowly drifting degradation — bearing wear over weeks — is visible in one reading per minute. Detecting a developing imbalance or cavitation can require high-frequency vibration waveforms at thousands of samples per second, which changes the storage, bandwidth, and processing budget by orders of magnitude. Decide the failure modes you care about first, then let that dictate the sensor spec. The reverse order produces expensive data that answers nothing.
Context data is the other half. A vibration reading means little without knowing what the machine was doing: which product, which speed, which tool, ambient temperature, operator shift. Plants that join sensor streams to production context from the MES or historian get models that separate "behaving oddly" from "running a difficult recipe." Plants that skip this step get alert storms and a crew that learns to ignore the system within a month.
Budget honesty: instrumentation and connectivity for a meaningful pilot — one line or a cell of eight to fifteen critical assets — commonly lands in the $30,000 to $120,000 range as of writing, driven mostly by retrofit labor and network work rather than sensor hardware itself. Verify quotes against your specific machines before committing.
If you cannot answer "what was the machine doing when this reading was taken," you do not have a prediction problem yet — you have a data-context problem, and no model will fix it.
🧠Failure prediction models: what to use and when
There are three practical tiers, and most plants should start at the bottom. The first tier is anomaly detection: unsupervised models learn what normal looks like per machine per operating mode, and flag deviation. It needs no labelled failures, works within weeks of data collection, and its output is "this machine looks different from itself," which is genuinely actionable for a good technician. Its weakness is specificity — it rarely tells you what is failing or how long you have.
The second tier is classification and regression on labelled events: given historical failures, the model learns precursor patterns and estimates either failure probability within a window or remaining useful life. This is where the marketing claims live, and where the data requirement bites. You need enough failure examples per failure mode — which, for reliable equipment, you may simply not have. Teams solve this with physics-informed features, fleet-level pooling across identical machines, or by importing failure modes from similar equipment.
The third tier is hybrid: physics-based models of the machine (thermodynamic, kinematic, degradation curves) combined with learned residuals. More engineering effort, but it performs better on rare events and extrapolates more safely than a purely statistical model. Aerospace and energy have used this approach for years; it is increasingly practical on factory equipment as tooling matures.
The mistake to avoid is starting with the most sophisticated model. Start with anomaly detection on your ten most painful assets, build organizational trust in the alerts, and add failure-specific models only for the modes that the anomaly layer keeps surfacing.
| Model tier | Data needed | Output | Honest limitation |
|---|---|---|---|
| Anomaly detection (unsupervised) | Weeks of normal operation | Deviation score per asset | Tells you something is wrong, not what or when |
| Supervised failure prediction | Labelled failure history per mode | Failure probability or remaining useful life | Rare failures starve the training set |
| Physics-informed hybrid | Sensor data plus machine models | Earlier, more specific warnings | Highest engineering cost per asset class |
| Threshold alarms (baseline) | None — vendor limits | Binary trip | Late and noisy, but nearly free |
📊OEE context: where the money actually is
Overall Equipment Effectiveness — availability times performance times quality — is the frame that turns predictive maintenance from a maintenance win into a plant win. Unplanned downtime hits availability directly, but the subtler gains are in performance (machines running below rated speed because a degrading component is being nursed along) and quality (worn tooling producing scrap before it produces an alarm).
This framing matters because it sets the value ceiling. If a line already runs at high availability with rare breakdowns, the predictive maintenance business case is thin no matter how good the model is. If unplanned stops are your largest availability loss — and for many discrete manufacturers they are — even a partial reduction is worth real money. Use your own downtime records, priced at your own contribution margin per hour, not an industry-average figure from a vendor slide.
One honest caveat: published industry figures on downtime cost vary wildly by sector and methodology, and as of writing you should treat any single number — including ones in analyst reports — as directional. The only downtime cost that matters in a business case is the one computed from your own OEE data and your own margins.
🔧CMMS integration: the loop that decides success
A prediction that does not become a work order is trivia. The single strongest predictor of program success we observe is whether alerts flow into the CMMS the planners already live in — creating a prioritized, parts-checked, scheduled work order — rather than into a separate dashboard with its own login.
The integration is more than an API call. The alert needs severity, confidence, recommended action, and the lead time the model estimates. Planners need to be able to mark predictions as correct, wrong, or early, and that feedback needs to flow back into model evaluation. Without the feedback loop you cannot tell a degrading model from a degrading machine, and the program slowly loses credibility.
Also plan for the awkward middle period where the model and the preventive maintenance schedule coexist. A good pattern is to let the model re-prioritize the existing PM calendar first — "skip this one, advance that one" — before letting it generate net-new work. That builds trust on decisions the crew already understands, instead of asking them to act on unfamiliar alerts from day one.
Measure the program on work orders completed from model alerts and failures caught early, not on model accuracy. Accuracy is a data-science metric; catch rate is the business metric.
🖥️Edge vs cloud inference
The split is dictated by physics and economics, not fashion. High-frequency vibration analysis belongs at the edge: streaming raw waveforms from hundreds of sensors to the cloud is bandwidth-expensive and latency-pointless when an industrial gateway can compute features locally and send only summaries and anomalies upstream.
Cloud inference wins for fleet-level models that pool data across machines and sites, for retraining, and for anything that needs to join with context data that already lives in enterprise systems. It also wins on operations: updating a model on one cloud endpoint is trivial compared to pushing updates to two hundred gateways across four plants.
The pragmatic architecture most plants land on is a hybrid: feature extraction and urgent detection at the edge, heavier models and fleet analytics in the cloud, and a store-and-forward buffer so a network outage never becomes a blind spot. Design for the plant network you actually have — including the ones with no reliable internet egress — rather than the reference architecture in a cloud vendor whitepaper.
| Concern | Edge inference | Cloud inference |
|---|---|---|
| Latency | Milliseconds, on-machine | Seconds plus network variance |
| Bandwidth | Sends features and alerts only | Raw streams get expensive fast |
| Model updates | Fleet of devices to manage | Deploy once, centrally |
| Fleet learning | Limited to local view | Pools across machines and sites |
| Connectivity outage | Keeps working | Blind unless buffered |
| Typical home | High-frequency condition monitoring | RUL models, cross-plant analytics, retraining |
💰Honest ROI: ranges, not promises
Here is the framing we use with clients, stated as labelled market ranges rather than promises. A focused pilot — one line, ten to twenty critical assets, anomaly detection plus CMMS integration — typically runs $80,000 to $250,000 all-in including instrumentation, platform, and integration work as of writing. A plant-wide rollout across several lines scales into the low-to-mid six figures per site depending on retrofit complexity, and multi-site fleet programs go higher still.
On the return side, published case studies across the industry commonly report reductions in unplanned downtime in the range of roughly a third to a half, and maintenance cost reductions in the range of a tenth to a quarter — but treat these as observed ranges from vendor and analyst material, not guaranteed outcomes, and verify against your own baselines. Payback periods we see modeled credibly land between twelve and thirty months; anything promising payback in a quarter is selling, not forecasting.
The ROI drivers worth modeling line by line: avoided downtime hours priced at your margin, reduced expedited parts shipping, reduced overtime for emergency call-outs, deferred capital from longer asset life, and scrap avoided from in-tolerance tooling. If the model only works when you assume the top of every range, the program is not ready.
🚀Pilot to fleet: the rollout order that survives
The rollout pattern that works is boring and sequential. Pick the line whose downtime hurts most and whose maintenance lead actually wants the program — not the line with the cleanest data. Instrument it, run anomaly detection in listen-only mode for four to eight weeks, and have the reliability engineer review every alert against what the crew found. This shadow period calibrates both the model and the humans.
Then go live into the CMMS for that line only, with a named owner and a weekly review. Run for a full maintenance cycle — typically a quarter — and compute catch rate and false-alarm burden honestly. Only then template the setup: sensor kit, gateway config, data schema, model baseline, and work-order mapping, so the second line costs a fraction of the first.
Fleet scale is where programs usually stall, and the cause is almost never technical. It is the absence of a reliability engineer with authority over the program, or a budget structure where each plant must individually justify what should be a shared platform. Solve the governance before the third site, because retrofitting governance onto a stalled multi-site program is much harder than building it in.
If you want a scoping conversation grounded in your actual equipment list and downtime records, our manufacturing practice does exactly that — we have delivered 500+ projects since 2018 and will tell you plainly if run-to-failure or better preventive scheduling beats a predictive program for your mix.
See how we approach manufacturing software and industrial AIEnterprise AI: pilot to production cost