Predictive maintenance for IoT: where the forecast breaks
IoT predictive maintenance breaks not on the model, but on the quality of the telemetry stream that feeds into it. ISO 13374 defines the condition monitoring data processing chain as a sequence: collection, transformation, condition assessment, prognosis, recommendation. In practice, the first two links break — collection and assessment, not prognosis.
Sensor degradation is slow and unnoticeable: zero drift, increasing noise, sticking at a single value. The channel is formally alive, timestamps arrive, so reports look clean — while the model computes on a biased signal and loses sensitivity to actual wear of the unit.
Explicit telemetry gaps look different: a communication break, buffering on the device, and after recovery — a batch of records with a delay.
If such windows are aggregated without quality flags, a sudden equipment failure will enter the statistics as a normal mode exactly when only hours remain until failure.
The flip side is false alarms. Threshold rules on a noisy signal raise an alarm out of nowhere, staff get used to ignoring them, and the real signal drowns in noise.
Manual inspection logs add desynchronization: a repair is recorded with a delay, the “normal” label is placed where there was overheating, and the training sample reinforces incorrect model behavior.
So we break down step by step exactly where the signal is lost, how to distinguish sensor degradation from unit wear, and how to label data so that false alarms are not reproduced in operation.
What changes after implementing predictive analytics
The fleet does not deliver an effect by itself — first, for each unit type, telemetry history is collected and a normal baseline is calculated: how a healthy unit behaves under a given load and operating mode.
Deviation from this baseline across several signals at once is the first sign of degradation, and from it the model estimates the remaining useful life of the unit rather than simply recording a setpoint exceedance.
The forecast horizon is usually 2–3 weeks — enough to turn an emergency callout into planned work: order a part, assign a task to the crew, choose a window without production loss.
Calendar-based replacements give way to condition-based replacements: a unit is replaced when it requires it, not according to a scheduled deadline.
Measurable effects look like this. The share of predicted failures is brought to 85–90% of the total number of incidents on the fleet; the rest is covered by protections and the inspection procedure.
Response time to a deviation is reduced from hours — until an operator reports the problem or the line stops — to minutes: the signal goes to the dispatcher immediately after going out of bounds.
The volume of emergency callouts drops by 2–3 times, and spare parts consumption by 20–30%, because the warehouse stops keeping a stock “just in case”.
Technically, the telemetry stream is consolidated into a time-series database: InfluxDB keeps history for each unit and serves it to the model without degradation as the fleet grows.
The model is retrained on confirmed failure cases, so accuracy does not degrade when units are replaced or the operating mode changes.
Options for building forecasting for a fleet of IoT devices
The choice of approach is determined not by the “level of analytics”, but by what is already available: how many sensor signals have been accumulated, whether failures are labeled, and how costly a false alarm is.
Threshold rules are configured from setpoints in one day, but they trigger when degradation has already begun. A machine learning model provides lead time for response, but requires stable failure labeling and regular recalibration when the fleet changes.
In practice, the approaches do not compete: a setpoint covers fast failures, while a model covers slow degradation of a unit.
Below are the applicability conditions for each option, so you can choose a starting point and avoid building a forecast where there is not yet data for it.
| Approach | When it fits | Limitations |
|---|---|---|
| Threshold rules | A fleet of several hundred devices, failures are binary, key parameters are collected | False alarms on seasonal fluctuations, rules are rewritten for each equipment model, no lead time |
| Deviation from a reference profile | There is a reference curve of a healthy device, no failure labels | Does not distinguish an operating mode change from degradation, the baseline requires recalculation after maintenance |
| Failure classification on history | A volume of historical data has been accumulated, failure labels are confirmed by the service department | Rare failure classes have to be supplemented with synthetic data, the model is sensitive to shifts in fleet composition |
| Remaining useful life forecast | Replacement needs to be planned in advance: wearing units, vibration, temperature, pressure | Accuracy drops on devices that were not in training, regular recalibration is required |
If there are few failure labels, we start with setpoints and detailed logging: the system immediately catches failures, while data accumulates for the next stage.
We connect the model for each unit class when a sufficient volume of historical data is accumulated — the transition to remaining useful life forecasting happens without reworking the entire collection scheme.
Implementation stages: from data audit to operation
The order of work here is strict: if you swap alert configuration and historical validation, the system will start waking up the on-call operator for every vibration spike, and trust in it will burn out in the first week.
That is why we first sort out the data — a forecast on unverified telemetry is indistinguishable from random numbers.
- Telemetry audit. Which units provide a stream, at what frequency, how many gaps and duplicates, where the sensor is silent after a restart. The output is a data map and a list of areas to exclude.
- Data flow scheme. The path from device to storage: buffering during communication breaks, aggregation at the edge, a single time across all units. Otherwise features are calculated from different clocks.
- Forecast assembly. From raw signals we create features, set the forecast horizon and the trigger threshold. We fix the quality metric before training, rather than fitting it to the result.
- Alert configuration. We distribute triggers by priority and routes, suppress chatter. The on-call operator receives a handful of messages — the ones that actually require a callout.
- Validation on historical data. A run over past periods in “as if today” mode: the share of failures caught in advance and the number of false alarms.
- Pilot operation. The system runs in parallel with planned maintenance: we compare forecasts with fact, refine thresholds, and analyze discrepancies together with operations.
- Handover to the customer’s team. Regulations, labeling, the retraining procedure, and model drift monitoring — support remains within the customer’s team.
What we hand over: configurations, schemes, regulations
A predictive maintenance system lives longer than its first launch: the device fleet grows, sensors change, thresholds have to be revised.
Therefore, everything that describes the system’s behavior we hand over to your repositories and accounts — without being tied to our infrastructure. Below is what remains with the customer’s team and allows developing the solution on its own.
- Model configurations: training parameters, feature set, aggregation windows, and version weights — with a note on what data the model was calibrated on and under what shifts it requires retraining.
- Integration schemes: the telemetry path from device to storage and forecasting service, connection points, message formats, and rules for handling communication breaks.
- Access policies: roles of engineers, analysts, and contractors, rights to read telemetry, change thresholds, and export failure history.
- Rules for calculating remaining useful life and alarm thresholds: which deviations are considered precursors to failure and which are normal equipment variation.
- Alarm response regulation: who receives the notification, within what time they confirm it, what work they perform, and how they record the result in the log.
- System documentation: architecture diagram, model description and its limitations, deployment and recovery instructions after a failure.
- Rollback procedure and change log: how to return the previous model version if forecast quality drops on new data.
We review each artifact with your engineers during handover, so that support does not turn into correspondence with us.
Case study: transitioning a pumping equipment fleet to forecasting
A fleet of 140 pump units across four sites was maintained according to a schedule — by operating hours and calendar.
Between planned works, some pumps still failed: first bearing assembly vibration increased, then a seal leak appeared, and only after that did the protection trip. Each such case meant an emergency crew callout, line downtime, and unit replacement at “any cost”.
Metrics before and after
| Indicator | Before implementation | After |
|---|---|---|
| Failures caught by an early signal | not tracked | 21 of 24 |
| Signal lead time before failure | — | 8–14 days |
| Time from signal to shift decision | about 3 days | 4–6 hours |
| Emergency callouts per quarter | 26 | 4 |
| Unplanned pump shutdowns | 11 | 2 |
Telemetry was collected from vibration sensors on three axes, bearing and winding thermocouples, pressure and drive current sensors; the stream was consolidated into a single loop, and the on-duty shift saw the condition of the units in Grafana.
Features were calculated in the frequency and time domain and tied to the pump’s operating mode, so that vibration growth at operating frequency was not confused with startup modes.
The model was trained on a repair archive — labels for confirmed failures were provided by mechanics from the logs.
Result: unplanned shutdowns were reduced fivefold, and most failures moved into a planned window — the crew replaces the unit on a convenient shift, without line downtime.
The decisive factor was not the forecast itself, but the response regulation: who receives the signal, how many days in advance, and with what threshold.
How does rule-based forecasting differ from a machine learning model?
A rule is a threshold on one or two signals with an explicit physical cause: unit temperature above the setpoint for longer than a given window, vibration going out of bounds under load. It is verifiable, explained in one phrase, and does not require accumulated failure history.
That is why the first loop on any fleet is almost always built on rules — they can be enabled the day after telemetry is connected.
The main reason the model is not placed first is imbalance: there are millions of healthy observations and only a handful of failures. On such a sample, the model confidently learns the anomaly of a planned shutdown rather than degradation.
This is treated with labeling by degradation windows, residual features such as the time a signal has stayed above normal, and transfer between similar units.
In practice, a hybrid works: the rule is responsible for detection and for a clear explanation, the model for multidimensional deviations that are not visible from a single sensor.
The engineer receives an alert indicating which signal went out of bounds and by how much and what contribution the forecast made — otherwise a site visit will not be approved.
The implementation order is simple: enable rules, keep a log of triggers, assemble a sample from confirmed cases, and only then connect the model as a second layer.
Technical doubts: we answer substantively
Objections when choosing a contractor concern not algorithms but operations: whether there will be enough data, whether telemetry will leak outside the perimeter, whether the model will coexist with existing dispatch systems, and who is responsible for it after launch.
There are few failures in history — the model has nothing to learn from?
Data quality is determined not by the number of accidents but by the feature set: we label raw time series by operating modes and operating hours, not only by failure facts.
We detect deviations without labels, and calibrate the trigger threshold in the first weeks so that the service does not drown in false calls.
How is telemetry protected during transmission?
The gateway is located on the site side and maintains only an outbound connection — inbound ports are not published externally. The stream is encrypted, raw series remain in your environment, and only aggregates and features go outside; access is role-based, with an action log.
Will dispatch systems have to be changed?
We integrate into the existing system: the forecast arrives as an event with priority, a work order is created by the standard process, and statuses are synchronized in both directions.
If communication is unavailable, a backup channel works — exporting the work list and notifying the responsible person.
How quickly do we reach operating mode and what happens after launch?
We bring up the first loop on one equipment group: data collection and cleaning, features, signals for explicit deviations. After launch, we monitor model drift, perform scheduled retraining, analyze false alarms, and train your operations service.
Let’s discuss the task: what is needed to start work
To come back with an estimate rather than general wording, we need to settle several inputs on the call.
Below is what is worth preparing for the conversation: with this data, the scope of work, the phased implementation plan, and the solution scheme are assembled immediately, without repeated clarifications.
- Device fleet and signals. Which units are in the area of interest, what parameters are collected from them, at what frequency, and through which communication channel they reach storage.
- Access to historical data. A telemetry export for a past period together with the failure and repair log — this is the basis for training the model and, more importantly, material for an honest validation of its quality.
- Target event. What we consider a failure, what we consider degradation, and what lead time is actually useful: within an hour an emergency crew can arrive, while within a day planned repair can be organized.
- Pilot area. One line, workshop, or group of similar devices where we will run the cycle before scaling to the entire fleet.
- Integrations and response. Where the signal goes — to dispatch, a repair request system, or an engineer notification — and who is required by regulation to respond to it.
- Roles and access. Who on the customer side confirms failure labeling and accepts the result by metrics, how access to data is arranged, and whether there are restrictions on taking it outside.
- Site limitations. Channel bandwidth, security policy, isolated network segments — this affects the collection scheme and where computations are located.
After the call, we will come back with an estimate, work scheme, and phased implementation plan: we will separately describe what is covered at the pilot area and what at the transition to the entire fleet.
Describe the task — specify the industry, equipment type, and what is already being collected in telemetry. That is enough to propose a concrete next step.
