Definition
Predictive Maintenance (Predictive Maintenance) is based on device Telemetry and RUL remaining useful life prediction models, arranging maintenance before failures occur to reduce unplanned downtime. Compared with Preventive Maintenance (scheduled maintenance), it is more precise and cost-effective.
Data Foundation and Models
Predictive maintenance relies on device telemetry data in the Time Series DB time series database, combined with outputs from models such as RUL remaining useful life and Device Health Score. Models can be trained using machine data such as vibration, temperature, and current, using machine learning (LSTM, Transformer) or physical models. The Device Management Platform should provide capabilities for data pipelines, model deployment, predictive task scheduling, and result storage, supporting batch predictions and real-time inference.
Integration with DMP
The platform links RUL and health score prediction results with Maintenance Schedule and Work Order. Low RUL or declining health scores can automatically trigger maintenance work orders and alerts; it supports optimizing Maintenance Window scheduling based on prediction results. When combined with Preventive Maintenance, it can form a hybrid maintenance strategy of 'fixed interval + early as needed,' ensuring availability while reducing over-maintenance costs.
Use Cases
It is suitable for lifetime management of key components such as bearings, motors, and batteries, as well as scenarios with high availability requirements like wind power, rail transit, and industrial production lines. Predictive maintenance is a core capability of Industry 4.0 and intelligent operations, significantly reducing unplanned downtime and maintenance costs.
How a life estimate differs from a threshold alarm
Predictive maintenance offers an estimate of the form "at the present rate of wear, how long until this leaves the usable range," and a time for maintenance that follows from it. It depends on a continuous stretch of measurements, a model that says how those measurements reflect wear, and a rule that turns the model output into a maintenance action. A threshold alarm only answers whether something has crossed a line now. A life estimate tries to give a time before that crossing. The estimate always carries conditions of use. Outside the load, temperature, and installation the training set has seen, the output should not be treated as equally trustworthy. Besides remaining time or a health trend, the result should show which model was used, whether the inputs were complete, and when this estimate was produced. When measurements are missing, "unknown" is more honest than a number of days that looks precise. It does not replace handling a fault that has already happened. If the device has already stopped, diagnosis and repair apply. Do not wait for another prediction cycle. Fault diagnosis explains a symptom that has appeared. Prediction discusses wear that has not happened yet. Do not write the two records as one alarm.
When an estimate may drive a work order
Before a maintenance task is created automatically, the input measurements should be continuous, in stable units, and aligned in time, and the conditions on site should be close to the range agreed when the model was built. The model needs a version, so replaying an old device history with the old version can reproduce the result. The output should be compared by hand for a while, until the lead time and the false alarms are acceptable on site, and only then should automatic work orders be allowed. The order that is opened should state the estimate and the model version that triggered it. After the work is done, write back what was actually found, and use that to decide whether the next model version should narrow its range. When the estimate is missing or the input quality is poor, fall back to the existing periodic service. Do not stop all maintenance. Spares and the shutdown window are still arranged by people. The model only suggests the timing. Joined to an event stream, one "maintenance suggested" event can carry this estimate. Do not create a new event on every small swing of the score. A loop that never writes the actual result back only repeats the same unchecked suggestion.
When training conditions and the field have drifted
A model trained on a constant load on a lab bench, while the site starts and stops often, shifts the remaining time with no consistent direction. A sensor that was replaced or moved, still read by the old model, has changed what the input means, and the output is still treated as the same indicator. Missing values filled with zero make the model read "no reading" as "in excellent shape" or as "already failed." Training only on a short stretch just before failure makes ordinary variation look like imminent failure. Work orders multiply, and the site starts to ignore them. Automatic orders with no cool-down open one order a day for the same device. A model update with no version mark leaves a historical trend in the report unable to explain why remaining time for the same device suddenly grew. Writing the estimated days directly as a promised failure-free period leaves no room to review the rule itself when the unit fails earlier. Calculating from old features when the input arrives late means the device state has already changed, and the order still goes out on expired features. Combining estimates for several components into one device score, and then working backward to which component it was, leaves the site unable to stock the spare.