Predictive maintenance: why failures catch you off guard
Scheduled inspection once a quarter, checklist completed, equipment running — and a couple of weeks later the line stops: a unit fails that was normal during inspection.
Formally, maintenance was performed, but a failure between scheduled inspections would not have surprised anyone if someone looked at signs of wear in units and assemblies, rather than the date in the scheduled maintenance log.
The root of the problem is in the very logic of a calendar-based schedule. Wear develops according to operating time and mode: starts under load, overloads, seasonal temperature fluctuations, lubricant condition, drive power quality.
A unit can be within tolerance at the moment of inspection and enter the failure zone after several shifts, and between checks no one sees how its behavior changes.
Then the most expensive scenario kicks in. Post-failure diagnostics means teardown, root cause search, urgent spare parts search, and repair on a stopped line, when each shift of downtime entails lost output, shipment delays, and defects due to unstable operation after restart.
Unplanned equipment downtime costs many times more than work that could have been planned a week before the failure. Moreover, some assemblies irreversibly lose service life after failure — it is not the part that is replaced, but the entire unit.
Key point: wear signals are almost always already in the data. Vibration, bearing temperature, drive current consumption, hydraulic pressure, cycle time deviation — individually it is noise, together it is a trend that shows the approaching failure long before shutdown.
The question is not whether data exists, but who reads it and how. Next we analyze how this is addressed: which signs we take as a basis, how we separate real wear from mode fluctuations, and what the system must do so that repair starts based on signs, not failure.
What changes after implementation: effects in measurable values
We calculate the effect on the same units: we take the baseline period before implementation and the period after, on the same telemetry and same load modes. The three metrics below show that predictive maintenance works, rather than just adding charts to the control room.
Share of unplanned stops
Some emergency stops become planned: the unit is taken out when the remaining useful life forecast approaches the threshold, not when it has already stopped.
The share of unplanned stops falls multiple-fold, while the total number of repairs does not grow — only their type changes. This is the reduction in failure rate that is noticeable on the shop floor, not in a report.
Time from first sign to taking out for repair
Previously, deviation was noticed by noise, vibration, or product quality drop — that is, almost before failure.
The model captures deviation from the norm while the unit is still within tolerance: the reaction window expands from hours to weeks, and downtime reduction comes from taking it out in an already scheduled window, not an emergency one.
Condition-based work instead of schedule
Some scheduled replacements are canceled: the unit's service life is not exhausted, and any teardown adds risk. The share of condition-based work grows from single-digit percentages to half and above; predictive repair planning moves them into agreed windows.
Every model update goes through a version registry (MLflow): forecast metrics and rollback to the previous version are available, so quality degradation is visible before it reaches production.
Predictive maintenance modes: from thresholds to predictive models
The mode is chosen not by the "sophistication" of the method, but by what the sensors provide and how well the failure physics is known.
Processing levels from ISO 13374 — condition detection, health assessment, prognosis — set the same boundary: the further the mode, the more accumulated history and labels are needed. Applicability conditions are more important here than model accuracy.
Threshold monitoring works as long as the failure develops according to a stable sign — rising vibration or bearing temperature. A statistical model compares the current profile with the norm and does not trigger on every acceleration under variable load.
A predictive failure model with remaining useful life estimation is needed when decisions about scheduled replacement, not shutdown, are made based on it.
| Option | When suitable | Limitations |
|---|---|---|
| Threshold monitoring | one or two signs, established failure physics, quick response needed | does not distinguish mode change from degradation, threshold selected manually |
| Statistical deviation model | variable load, many sensors, few failures | requires norm sample and retraining when mode changes |
| Remaining useful life prediction | history of runtimes to failure, decision on scheduled replacement | horizon limited, sensitive to drift and changing conditions |
| Hybrid scheme | critical units: both protection and planning needed | more expensive to set up, requires coordination of loops |
A hybrid scheme is used when a missed failure costs more than an unnecessary replacement: thresholds provide insurance, the model plans, and the discrepancy between them shows that the labels are outdated.
The limitation of forecasting is always the same — it is valid within the observed modes; when the load or schedule changes, the model is retrained.
Implementation stages: from data audit to handover to operation
The order of work here is set not by schedule convenience but by physics: first we prove that the failure signal is present in the data at all, and only then build a model on it.
Each stage ends with a verifiable artifact — a list of sources, a diagram, a labeled event set, a backtest report — and the next does not start until the previous one is confirmed.
- Data source audit. We inventory process control system archives, inspection and repair logs: which parameters are recorded, at what frequency, what the storage depth is, where there are gaps and recording breaks. The output is a data map with an honest assessment of which unit signals are missing.
- Solution design. We fix the list of monitored units, the warning horizon, the set of features, and the location where computation is performed. We separately describe how the result reaches the dispatcher and what they do when it triggers.
- Collection and event labeling setup. We connect the telemetry stream, align timestamps to a single scale, and link trends with failure and repair records. False stops and starts after scheduled work are marked separately — otherwise the model learns on noise.
- Validation on historical failures. We run the model over the past with a sliding window: at each step, only data up to the current moment is available to it. We calculate the share of caught failures, the number of false alarms, and the lead time of triggering for each unit.
- Pilot operation. The model runs in parallel with the standard schedule and does not affect anything: its warnings are compared with the service's actual decisions and thresholds are refined.
- Handover to operation. We provide the response procedure for alerts, documentation, and trained specialists, and assign responsible persons. Then we provide support: equipment modes change, so drift monitoring and retraining on new events are performed on schedule.
Handover of results: configurations, models, procedures, access
A predictive maintenance system cannot be accepted on faith: if after launch the customer is left with only dashboards, then any sensor replacement or change in equipment operating mode turns into downtime until the contractor arrives.
Therefore handover is a separate stage with a fixed list of artifacts, and each is checked at acceptance.
- Collection configurations: list of tags, polling rates, rules for outlier rejection and aggregation — with justification for why this particular sampling interval was chosen.
- Descriptions of models and feature sets: which signals are involved, how the observation window is built, which states are considered target, and where the model's applicability boundaries are.
- Data flow diagrams: from sensor to storage and from storage to the warning service — with failure points and recovery procedure after communication loss.
- Access policies and roles: who sees raw data, who changes thresholds, who closes a false trigger; all actions are logged.
- Alert response procedure: criticality levels, response times, escalation procedure, and feedback labeling rules — false and missed events are returned for retraining.
- Operational documentation: instructions for retraining, scheduled maintenance, rollback to the previous version, and performance checks after a failure.
Acceptance is based on test scenarios: the customer's engineer independently brings up the system instance on a test bench, makes a change to the configuration, and confirms a warning. If this is possible without us — the handover is complete.
Case study: failure prediction for a pump fleet in production
The customer is a continuous-cycle production facility, where a pump fleet of several dozen units supplies water and reagents to the main line.
Before the implementation case, failure was noticed by pressure drop or bearing assembly noise — minutes before the accident, when repair was already emergency and involved line downtime.
What was before
Vibration sensors were installed on three units; the rest lived by schedule: bearings were replaced "by operating time," and half of replacements went to healthy units.
Per quarter, there were 11 unplanned pump stops, each one a line downtime and a disruption of the shipment schedule.
What was changed
Vibration and temperature of bearing assemblies were collected from the entire fleet and consolidated into a unified history for each unit. The model issues an early failure warning based on vibration spectrum change and temperature trend 5–12 days before unit failure.
The Severmash site spent the first months calibrating thresholds against actual repairs — that is how false alarms were eliminated.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Unplanned pump stops per quarter | 11 | 3 |
| Share of failures caught in advance | ~15 % | 87 % |
| Time from warning to taking out for repair | none | 5–12 days |
| Replacement of bearings without defect | every second | every sixth |
The reduction in emergency stops delivered the main thing — repairs became planned: the unit is taken out during a window when the line is already down for changeover. Over a year of observations, not a single caught defect reached shaft seizure.
What to do if data from equipment is already being collected?
The most expensive part of the work is already done: signals from equipment are collected, historical data archives are accumulated, and the monitoring system is running.
The problem is not the volume, but that the archive and repair history exist separately from each other — that is why forecasts are not built.
The model learns on failure facts, not on signals by themselves. If repairs live in work orders or another accounting system, there is no answer to what should be considered a failure and how the unit's behavior changed before it.
The first step is to consolidate archives with the repair log and obtain labels for the target event. Then inventory the channels: different polling rates, communication gaps, zero drift, data duplication with multiple gateways and manual exports.
Integration with an existing system is done as an add-on, not a replacement: if a monitoring system already exists, we read its archives, add a feature calculation layer, and return the forecast to the same place where the operator is used to working.
Reuse of existing work speeds this up noticeably — equipment reference data, the unit tree, and emergency setpoint boundaries are already described, and most features are assembled from them.
A separate reason forecasts do not reach the operations service: the result lives in a report or on a separate panel, not in the procedure.
The warning should come to the same channel where work orders are issued, indicating the unit, lead time horizon, and confidence — otherwise the shift learns about the problem at the same time as the failure.
Bottom line: collection usually does not need to be redone. We need to link archives with repairs, assemble features from existing reference data, and embed the model output into the operations loop.
Questions on data, model accuracy, and integration with accounting systems
Forecast accuracy is determined by data quality and how the model signal is embedded in the repair process, not by the choice of algorithm.
Before starting, we calculate the lower bound: how many failures are in the facility's history and what share of misses can be sacrificed for early warning.
There is little data on the object and some sensors are missing — what to do?
We start with operation logs, operating time, and repair work orders — this is enough for a baseline model. Vibration sensors, unit temperature, and drive current are added in stages: they provide the main accuracy gain, but we install them where it pays off.
How do you reduce the number of false alarms?
We set thresholds not by the "raw" model output, but by a matrix of "cost of a miss versus cost of an unnecessary callout," agreed with your services. For the first weeks — observation mode: signals go only to the engineer, without callouts.
What happens when communication with the object is lost?
The gateway on site buffers data and sends it after the channel is restored.
If there is no data longer than the threshold, the system marks the state as "no connection" and does not build a forecast — this is a separate signal, and it cannot be read as "equipment is normal."
Who is responsible for the model after handover?
We hand over the model, feature map, thresholds, and retraining procedure. We fix metrics on a holdout set that the model did not see during training. The warranty support period is included in the project: if it falls below the agreed boundary — we investigate and retrain.
Let's discuss the task: what we will clarify and how we will estimate the scope of work
For the scope estimate to be substantive rather than a "random range," we need baseline data on the fleet and on how maintenance is currently organized.
Below is what we clarify at the first meeting; based on its results, we return with an estimate and a phased implementation plan.
- Fleet composition: types of units and assemblies, number of units, criticality of each for the production cycle.
- What data is already collected: sensors and controllers, failure and repair logs, depth of observation history.
- Where this data is stored and how often it is updated: archives, manual logs, exports from accounting systems.
- Which failures need to be predicted first and how far in advance a signal is needed.
- Who and how reacts to a warning: maintenance procedure, duty shift, control room.
- Constraints: data access, facility operating mode, requirements for deploying the solution on the customer's side.
- What we consider the result: share of failures caught, reduction in unplanned downtime, alarm accuracy.
Then our steps: we verify the data, show which signals are objectively missing for the model, and fix the phasing — from a pilot on one unit to rollout across the entire fleet.
Describe the task and send what already exists on the equipment and failure history — we will return with a scope estimate and an implementation plan.
