Predictive Maintenance in Manufacturing: From Vibration Data to RUL

Industrial predictive maintenance stops being a dashboard promise when the plant uses it to decide when to stop a machine, which spare part to order and which shift takes the intervention. This guide documents how Captia Technology builds it in real operations: which signals to measure, which architecture carries the business case, which models hold up on messy industrial data and how to measure ROI without fooling yourself.

Why industrial predictive maintenance fails so often

Most predictive maintenance projects do not fail because of the model. They fail for three quiet reasons: data that does not represent the real failure, a business promise nobody signed off, and weak integration with the technician's workflow. Fix only one of the three and the pilot shines for six weeks, then fades the moment line conditions change.

In industrial environments, data is always scarce where it matters most: close to the failure. Well-run plants log thousands of hours of normal operation for every hour of anomaly. If the data team learns only from the majority class, it ends up building a routine detector, not a breakdown predictor. Accepting that from day one changes which data gets prioritised, how it gets labelled and which models count as valid.

There is a fourth reason that surfaces late: the imbalance between what a false positive costs and what a false negative costs. An unjustified alert burns two hours of a technician's time and some credibility. An undetected failure can cost a full production shift. That ratio, different for every asset, is what should set the alert thresholds. When nobody calculates it, thresholds get tuned by eye and the system swings between silence and noise.

From vibration to Remaining Useful Life

The most cited signal in predictive maintenance is vibration. There is a decades-old tradition (ISO 10816, ISO 20816) that translates vibration amplitude into mechanical condition. That tradition is the starting point, not the destination. A modern programme combines vibration with other signal families to stabilise the decision:

• Vibration: broadband acceleration plus envelope analysis to capture bearings; FFT synchronised with rpm to detect misalignment, unbalance and looseness.
• Temperature: infrared on the casing and thermocouples in the oil; useful for correlating thermal load with friction and loss of lubrication.
• Motor current (MCSA): detects asymmetries, broken rotor bars and bearing problems without additional mechanical instrumentation.
• Ultrasonic acoustics: compressed-air leaks, cavitation in pumps, partial discharges in electrical cabinets.
• Product quality: deviations in dimension, weight, colour or visual defects are often the first observable sign of a degrading process.
• Process variables: differential pressure, flow rate, specific consumption. A clogging filter or a fouling heat exchanger shows up in the process before it shows up in the mechanics.

The final decision is the Remaining Useful Life (RUL): how many hours or cycles the asset has left before crossing a safe operating threshold. RUL is not predicted directly with a naive regression. It is built by combining three layers:

1. A layer of physical features that respect the machine's dynamics (rpm harmonics, order tracking, envelope kurtosis, crest factor). Without this, the model learns noise.
2. A probabilistic model layer that returns a distribution over RUL, not a single number. Maintenance technicians operate under uncertainty: giving them an interval is more useful and more honest than giving them a point estimate.
3. An operational decision layer that turns the distribution into action: schedule an inspection at the next shift stop, order a spare with lead time X, escalate to engineering when the left tail of the interval crosses the critical threshold.

Between the signal and the RUL there is an intermediate step worth naming: the health indicator. It is a synthetic variable between 0 and 1 that summarises the asset's condition and degrades monotonically as the failure progresses. Building a good health indicator, validated against the plant's own breakdown history, usually adds more value than switching model architecture. And it has a political advantage: the maintenance manager understands it without translation.

A reference architecture in four planes

The architectures that survive years on the shop floor share a shape. The useful mental model is four planes, each with its own latency and criticality.

Edge

The edge is where high-frequency sampling lives: 10-50 kHz for vibration, 1 kHz for current, raw time series for process variables. This plane windows the data, runs pre-processing (windows, FFTs, RMS) and publishes to the next plane over industrial protocols (OPC UA, MQTT with Sparkplug B). The edge also runs lightweight models when the decision has to be taken in milliseconds (stopping the line, tripping a safety alarm).

Brokers and the unified namespace

All signals arrive at an MQTT broker with a unified namespace. That namespace is the contract: every topic is identical across plants, every payload conforms to a versioned schema. Without a data contract, every new asset needs re-engineering. With one, adding a line is configuration. Captia Connect targets exactly this plane.

Storage and features

The data plane needs two stores: a raw one (unaltered time series, long retention, low cost) and a feature store (windowed aggregations, spectral transforms, failure labels validated by maintenance staff). Models always train from the feature store, never from the raw base; that way reproductions are exact months later.

Modelling and serving

The model plane covers training, versioning, evaluation and deployment. The guiding principle is glass-box first: before proposing deep learning, document the physical baseline. If a baseline built on ISO thresholds, order rules and envelope kurtosis delivers 70% of the value, it gets frozen as an unassailable reference. Any new model has to beat it on a metric the business cares about, not just on AUC.

Which models work on real industrial data

There is no single winning model. There is a family of techniques that survives contact with reality:

• Unsupervised anomaly detection (isolation forests, autoencoders, reconstruction-based methods) when labels are scarce or non-existent. Broad coverage, low precision unless combined with physical rules.
• Supervised classification (gradient boosting, random forests) on aggregated features, for failure modes with a labelled history. Reliable, interpretable, productisable.
• Survival models (Cox, AFT, DeepSurv) to estimate RUL while respecting that the data is censored: many machines are serviced before they fail, and that is valid data, not a gap.
• Temporal networks (LSTMs, temporal convolutional networks, lightweight transformers) when there are millions of operating hours and the client accepts a less interpretable model. Useful for turbines, large compressors and presses with dense instrumentation.

This progression, from the physical baseline up to temporal networks, is what Captia AI packages as advanced AI models: the client does not pick a technique, they pick a level of ambition, and each technique has to justify itself against the baseline at every step. Moving up a step only makes sense once the previous one has been squeezed dry and the available data allows it.

Captia AI's operating rule is simple: every model that reaches production declares its validity window (the operating conditions it was trained under), its acceptance metric (for example, a false positive rate < 5% under start-up conditions) and the channel through which a human takes over when needed. Without those three elements, no model gets promoted.

From alert to decision: designing the channel

An excellent model with a badly designed alert channel produces the same result as a bad model: nobody acts. The channel deserves as much design as the model. Three decisions define it:

• Who receives what. The shift technician needs an actionable instruction (inspect the coupling-side bearing on pump P-204 at the next stop). The maintenance manager needs the weekly trend. Leadership needs the monthly aggregate in pounds and euros. Sending all three messages to the same inbox kills the channel within a month.
• With how much lead time. An alert arriving two hours before the failure lets you mitigate; one arriving two weeks before lets you plan the spare, the shift and the stoppage. The value of predictive maintenance lives in the second, and that shapes which features and which prediction horizon get chosen.
• With what noise budget. Agreeing with the plant on a maximum number of weekly alerts per asset forces precision to be prioritised and builds trust. A system that respects its noise budget for six months earns the right to interrupt a shift.

This channel design, with role-based routing, agreed thresholds and traceability of every alert through to closure, is what Captia AI deploys as prediction and alerts. The technical piece is the same in every plant; what changes is the threshold negotiation with the people who live with the consequences.

Everything above is methodology. If what you need is the specific capability that executes it inside the platform, which signals and events it consumes, what it returns and what it takes to switch it on, that is described in the Captia.ai predictive maintenance module.

Industrial MLOps: what no course teaches you

A model in production is the beginning, not the end. Three routines separate a serious programme from one that fades away:

1. Drift monitoring. If the process changes (different raw material, a new setpoint, asset ageing), the input features shift. The system detects drift before the quality metric drops and triggers controlled retraining.
2. Human-in-the-loop. Every alert the technician closes as false positive, true positive or routine inspection goes back into the training set. Six months later the model is better tuned to that plant than any generic model.
3. Model governance. Who can train, who can promote, which records are kept, how a misbehaving model gets rolled back. This is the invisible work that separates a pretty pilot from a company asset.

Each of these routines has its own discipline: how data drift is measured against concept drift, how confidence thresholds are set and when it is better to retire a model rather than retrain it. We cover it in depth in the industrial MLOps guide, the natural continuation of this pillar once the first model is in production.

Real ROI: how to measure it and how to audit it

A predictive programme is justified by three savings vectors, in this order of impact:

• Avoided cost of unplanned downtime: production hours saved multiplied by contribution margin per hour. This is the number executives understand and the one marketing tends to inflate. Measuring it properly means comparing the stoppage rate before and after the programme on an instrumented asset, holding everything else equal. If you cannot compare, it is not ROI: it is storytelling.
• Optimised spare-parts cost: fewer parts replaced as a precaution, less capital tied up in stock and better-timed purchasing. Typically between 15% and 30% of the total saving.
• Safety and quality: fewer safety incidents and fewer defective batches. Harder to monetise but, at times, the real reason the CEO signs.

OEE (Overall Equipment Effectiveness) is the classic KPI. The programme must demonstrate improvement in availability and in performance; quality improves indirectly once the asset stops running degraded. Without a dashboard separating the three, there is no honest conversation with operations.

Worked example: a centrifugal process pump

A generic but complete case lands better than ten principles. Take a centrifugal process pump running continuously, with a 75 kW motor and direct coupling, whose dominant failure mode according to the FMEA is degradation of the coupling-side bearing.

1. Instrumentation: two accelerometers (radial and axial) on the bearing housing, current measurement at the drive and casing temperature. Nothing more. The remaining variables (flow rate, discharge pressure) already exist in the control system and are retrieved over OPC UA.
2. Physical baseline: vibration velocity thresholds for the machine class under ISO 20816 and tracking of the energy in the bearing's characteristic frequency band (computable from its geometry and the rpm). This baseline runs in shadow mode for four weeks to learn the normal variability.
3. Model: on the spectral features aggregated by hour, a supervised classifier is trained using the CMMS intervention history as weak labels. The output is not "failure yes or no" but a health indicator and a RUL estimate with an interval.
4. Decision: if the lower bound of the RUL exceeds three weeks, do nothing. Below three weeks, a work order is raised in the CMMS with the spare part reserved. Below seventy-two hours, it escalates to the shift supervisor to schedule the stop in the next available window.
5. Closing the loop: after the intervention, the technician records the actual condition of the bearing. That label, the system's only ground truth, feeds back into the model and adjusts the thresholds.

What is notable about the example is what does not appear: no deep learning, no mandatory cloud, no hundreds of sensors. There is an FMEA that picked a failure mode, physics that defined the features and a decision flow a maintenance shift can execute without changing how it works. That is the shape of the first winning case; the sophistication comes later, built on this foundation.

Common mistakes that kill PdM programmes

• Installing sensors before agreeing failure modes. Without a prioritised FMEA (Failure Mode and Effects Analysis), you end up with a glut of data and no hypothesis.
• Not keeping raw data. If only aggregates are stored, tomorrow's model cannot recompute features.
• Confusing an alert with a recommendation. A system generating 40 alerts a day is a broken system. The key metric is precision under real plant conditions.
• Ignoring the technician's workflow. If the alert does not land in the CMMS the team already uses, nobody reads it.
• Not planning the handover. A programme that depends on one expert dies when they leave. Documenting, automating and training the second ring is mandatory from month one.
• Validating the model with random splits. In industrial time series, mixing past and future in the test set inflates the metrics. Honest validation always runs forward in time and, with multiple assets, holds entire assets out of training.

How it fits into the wider Captia system

A predictive maintenance programme does not stand in a vacuum. In the Captia architecture it leans on three more units:

• Captia Consulting defines the scope, identifies critical assets, anchors the business case and audits it every quarter.
• Captia Connect makes sure the data arrives stable and governed: OPC UA, MQTT, unified namespace and versioned data contracts.
• Captia Service connects the model's decisions to the ERP (Odoo), maintenance (CMMS) and the team's real operational workflows.

The unit that takes centre stage is Captia AI: the system that interprets, predicts and turns data into an actionable recommendation. Without the rest of the system, the best model is left with no hands and no channel.

A six-step adoption roadmap

1. Weeks 1-4: operational diagnosis, prioritised FMEA, definition of pilot assets and success metric.
2. Weeks 5-10: pilot instrumentation, data contracts, physical baseline running in shadow mode.
3. Weeks 11-16: first ML model beating the baseline, CMMS integration, technician feedback routine.
4. Weeks 17-20: first quarterly impact audit, threshold and rule tuning.
5. Months 6-9: scale-out to a second line, reuse of features and architecture, training of the second ring.
6. Months 9-12: programme in steady state, monthly KPIs, model governance and an annual replanning cycle.

Standards and regulations worth knowing

A solid programme rests on recognised standards; that is not cosmetic, it is a shared language with auditors, insurers and suppliers. The most relevant for industrial predictive maintenance:

• ISO 10816 / ISO 20816: vibration severity classification by machine type and mounting. Still the reference for initial thresholds.
• ISO 13374 and ISO 17359: condition monitoring process architecture (data acquisition, manipulation, detection, diagnostics, prognostics).
• ISO 55000 / ISO 55001: asset management. Places predictive maintenance within the wider decision process over the equipment's life cycle.
• IEC 62443: industrial cybersecurity. Any OT/IT integration that carries data out of the plant has to meet the security levels the client demands.
• NIS2: the European directive that, for essential sectors, turns practices that used to be recommendations into obligations.

A twelve-line ROI business case template

To discuss a concrete case with an industrial leadership team, a twelve-line template is enough. Any missing number is a clue about what needs measuring before going further:

1. Selected critical asset and primary failure mode.
2. Unplanned downtime rate over the last 24 months.
3. Mean time to repair (MTTR) for that failure mode.
4. Contribution margin per hour of lost production.
5. Gross annual saving if 40% of those stoppages are avoided.
6. Programme cost: instrumentation, integration, model, support.
7. Technician hours freed up if alerts are precise.
8. Estimated reduction in safety stock.
9. Residual risk of a false negative (safety, quality).
10. ROI margin after payback (months, not years).
11. Internal programme owner and executive sponsor.
12. Agreed audit window (next date, metric to be shown).

Frequently asked questions

Conclusion

Industrial predictive maintenance is not solved by buying a sensor or training an autoencoder. It is solved by designing a decision system: what gets measured, how it is stored, what the model contributes, which technician acts and how much money is saved. Once that system exists, the ML model is the most interesting piece, but not the most fragile one. At Captia Technology we build it by combining the four units (Consulting, Connect, AI and Service) into a single operational plan, with quarterly audits and KPIs that stand up in front of an industrial director and a CFO.

If you want to discuss a concrete case for your plant, at Captia AI we can land a diagnosis in weeks rather than quarters: a pilot asset, a priority failure mode and an ROI template built on your numbers.