Predictive vehicle maintenance: where the forecast breaks down
An unscheduled failure of a component in a fleet is almost always recorded after the fact: the vehicle stops on route, then a tow truck, downtime instead of revenue, and urgent unscheduled repairs.
Worse, until that moment everything was formally in order — scheduled maintenance was performed, fault diagnostics were empty, and the component's condition was considered operational.
The reason lies in the logic of the schedule: intervals are set by operating hours and mileage, not by the actual condition of a specific vehicle. Two units with the same mileage wear differently — highway mode, warm-up, load, driver style.
An averaged standard either replaces a serviceable component too early or misses degradation that has already begun. Fleet diagnostics based on reported issues is limited by the same boundary: until the driver reports a symptom, the vehicle does not enter the sample.
Predictive vehicle maintenance rebuilds this around data. Vehicle telemetry continuously provides temperatures, pressures, vibrations, currents, and operating modes of components; from these series, trends and remaining useful life estimates are calculated.
Then the forecast works: the model identifies which vehicles have consumed enough life that a failure will fall within the planning horizon, and issues this as a work order to the shop — indicating the component and the remaining window.
The key here is not the model itself, but the combination: completeness and frequency of signals, operating modes as context, trigger thresholds, and feedback on actual repairs, without which the forecast quickly diverges from reality.
Therefore, we break down how this is addressed: from defining the task for a component and collecting telemetry to validating forecast quality on failure history.
What failure prediction delivers in daily fleet operations
The transition to condition-based maintenance changes not the reporting, but the work queue itself.
Instead of an “every N kilometers” schedule, components with confirmed degradation come first: the model estimates remaining life from a combination of signals — temperature, vibration, onboard network parameters, and the history of a specific vehicle.
The first measurable effect is a reduction in unscheduled downtime. A failure that develops over hundreds of kilometers falls into the diagnostic window, and the vehicle goes to service not on a tow truck but in the nearest planned slot.
In fleets with dense telemetry, the share of unscheduled stoppages decreases severalfold, and downtime per incident drops from days to hours.
The second effect is predictable service load. The forecast arrives with a horizon of several weeks, so the load on bays and warehouse can be leveled: peaks are smoothed, urgent parts purchases become planned, and workshops do not sit idle between waves of failures.
The third is the class of failures eliminated. Wear-out failures with a pronounced degradation trend are covered: hub bearings, brake pads, drive belts, starter batteries, sensors.
Instantaneous electronics failures are not caught by the forecast — they are assigned to a separate loop, and this is honestly recorded in the model's reporting.
Methodologically, we rely on ISO 13374: data acquisition, processing, condition assessment, prognosis, and action recommendation. This separation of layers simplifies validation and allows individual components to be replaced without rebuilding the entire system.
Approaches to building a forecast: from thresholds to models
The choice of forecasting method is dictated not by the fashion for models, but by how much data the fleet has and how often failures occur.
For a single vehicle with a rare breakdown, statistics are only enough for a hard rule; for a fleet of hundreds of vehicles with a stream of telemetry, a machine learning model already pays off.
The mistake is to start with the most complex: a model trained on three cases produces confident and incorrect forecasts.
| Option | When it fits | Limitations |
|---|---|---|
| Threshold diagnostics | Manufacturer setpoints and a clear signal exist — pressure, temperature, level | Catches failure at the very boundary, false alarms under seasonal and operating fluctuations |
| Rules by operating hours | Scheduled maintenance, predictable component wear, homogeneous fleet | Does not account for driving style and operating conditions — life is consumed unevenly |
| Machine learning model | Several hundred vehicles, failure and repair history, stream of onboard data | Requires labeling, retrained when fleet or routes change, drift monitoring needed |
| Hybrid approach | Heterogeneous fleet: some vehicles are new, some have history, some have no sensors | More complex maintenance: rules, features, and model must be synchronized |
The practical logic is this: rules by operating hours and thresholds remain a safety net and work where data physically does not exist, while the model takes on components with accumulated history.
This combination reduces the share of missed failures and does not grow in maintenance cost when the fleet expands with vehicles without telemetry.
Condition-based maintenance: implementation stages
Implementation begins not with the model, but with an inventory of what fleet telematics already collects. In practice, half of projects run into data: the necessary signals either do not exist or are recorded with gaps and without binding to a specific vehicle.
Therefore, the sequence of work is arranged so that each next step relies on the previous one being verified.
Sequence of work
- Fleet data audit. We look at which channels are already recorded: mileage, fault codes, temperatures, pressure, operating modes of components. We assess history depth, recording frequency, share of gaps, and discrepancies between vehicles of the same model.
- Sensor and source scheme. We identify which signals are missing and whether they can be obtained as standard or with a separate sensor. We consolidate everything into a single scheme: source, frequency, format, storage location.
- Setting up rules and the model. First threshold rules based on fault codes and parameters leaving the corridor, then a model for estimating the component's remaining life. Rules deliver quick results, while the model provides early signs of an incipient failure.
- Validation on past failures. We run the system over repair history: how many failures it would have predicted, how long before the event, and how many false alarms it produced. The trigger threshold is selected based on this validation, not on general recommendations.
- Observation on a live fleet. For some time, warnings go to the dispatcher as a hint rather than into the work plan. This shows where the model errs under specific operating conditions.
- System handover. Regulations for actions upon triggering, responsibility matrix, access rights, documentation on signals and model applicability boundaries, training for the operations service.
Acceptance criteria are fixed before the start: share of confirmed warnings, lead time before failure, and volume of false alarms per fleet. After that, the system lives as a regulation — with periodic retuning of thresholds based on new data.
Models, regulations, and schemes: what we hand over to the team
We hand over not a “model and a set of scripts,” but a working loop with areas of responsibility. The key acceptance check is that the customer's engineer can change a threshold with their own hands, investigate a false alarm, and understand what data the model was trained on.
- Trained model and trigger rules. Thresholds for each component and unit, averaging windows, minimum operating hours before forecast starts, a list of features with explanations — what is calculated from a sensor and what from maintenance history.
- Integration scheme. Where telemetry comes from and at what frequency, in what format, how the forecast reaches the dispatch center and fleet management system, and what happens if the channel breaks.
- Access rights. Roles of dispatcher, service engineer, analyst, and administrator, the boundaries of each, who changes thresholds, who closes a warning, and who sees vehicle history.
- Warning response regulations. Gradation by criticality, notification timelines and channel, the responsible person at each level, and the procedure for a false alarm and for a confirmed risk.
- Warning log. Time, component, feature value at the moment of triggering, confirmation status, and repair outcome — the basis for incident review and subsequent training cycles.
- System documentation. Architecture, feature dictionary, operating instructions, model update procedure, and rollback to the previous version.
A separate item is the retraining procedure: period, data requirements, quality metrics, and acceptance procedure for a new version. We hand everything over in repositories with versioning and train your engineers — so the system can be developed without us.
Service network case study: how unscheduled failures were reduced
A network of service centers maintains a fleet of several thousand vehicles operating on intercity routes. Before the project, diagnostics followed a mileage schedule, and a malfunction was often learned about from the driver — already en route, with downtime and towing.
The share of failures on route held at about 3% of trips, and more than a third of component replacements were done prematurely, “just in case.”
What was changed
We collected telemetry from onboard gateways (Wialon and partner network trackers), brought signals into a unified scheme, and trained a model on the remaining life of components — turbocharger, brake system, fuel equipment.
The trigger threshold was selected not by abstract model quality, but by the cost of two errors: a missed failure and a false service call.
What was achieved
Failures on route — from 3.2% to 1.1% of trips. Warning accuracy increased from 78% to 91%, and the false alarm rate fell from one in six warnings to one in twenty.
The share of repairs moved into a planned window — from 38% to 74%, meaning the vehicle arrives at the lift instead of the roadside.
Implementation took 11 weeks: three — for collecting and labeling historical trips, five — for the model and its validation on data from previous periods, three — for embedding signals into the work of the dispatch center and service centers.
What to do if some of the fleet lacks sensors
Short answer: a full set of sensors is not mandatory. The forecast is built on what actually comes from the fleet, and missing channels are replaced with derived features and by limiting the model's scope — to components and modes where the error remains acceptable.
Incomplete data means gaps in records, lost channels on some vehicles, and different data collection formats.
We do not fill gaps with synthetic data: we mark them with a mask and train a model robust to the absence of some inputs, and at output we calculate forecast confidence for each vehicle.
Below the threshold — the system does not issue a recommendation but marks the vehicle for a planned inspection.
Different telemetry frequencies are addressed by bringing data to a common observation window: fast signals are aggregated into per-shift characteristics, slow ones are transferred to window boundaries.
Thus vehicles with frequent and infrequent transmission fall into the same feature space and become comparable to each other.
Where there are no direct measurements of a component, indirect features work: relative consumption, thermal regime, duration of downtime, acceleration pattern, intervals between refueling.
Their joint shift is noticed long before failure — the model records not a specific breakdown, but a deviation from the vehicle's own norm.
Phased fleet coverage removes the risk of a disruptive rollout: first the model is trained on a group with dense telemetry and validated on confirmed cases, then the features are transferred to the remaining vehicles. Sensors are added with justification — where the forecast is unstable without a direct channel.
Common technical doubts about failure prediction
Doubts about failure prediction are usually not about the model, but about data and integration with the management system. Four objections that engineers raise first, and how we address them.
Telemetry comes with gaps — will the model train?
Gaps in sensors are normal. We calculate a channel quality profile: share of gaps, zero drift, stuck values, timestamp desynchronization. Channels below the threshold are excluded rather than filled with averages — otherwise the model gains false confidence.
Where does labeling come from if repair logs are manual?
We consolidate repair requests, component replacements from the warehouse, and error codes into a single failure event with a time window, cleaning duplicates and technical closures.
Where there is no exact date, we label by operating hours and mileage: accuracy is lower, but the first version of the model can already be trained.
How to reduce false alarms?
We choose the threshold by the cost of error, not by accuracy: a stream of false alarms kills trust in the system. We issue the signal as a risk level with a horizon, and only a rise in risk across several consecutive windows goes into work. Completeness and false alarm rate are calculated on a holdout sample.
How is the forecast linked to the management system?
The forecast arrives as a separate request or a flag in the card, and source data are not overwritten. We write only to our own fields and log changes, so the integration can be disabled, and the management system will continue to operate as before.
Let's discuss the task: failure prediction for your fleet
To come back with a timeline estimate and work plan, we need not a prepared report but raw fleet data — in whatever form it exists.
The earlier real telemetry and the repair log are visible, the more accurate the estimate: for some models the forecast reaches working metrics quickly, for others a longer observation period is needed.
What we will need from you in the first conversation:
- fleet composition: makes, models, vehicle age, types of power units, distribution by divisions;
- telemetry: which sensors are already recorded, at what frequency, and over what period history is stored;
- failure and repair log: work orders, fault codes, dates, and mileage at the time of failure;
- operating conditions: routes, seasonality, average load, operating mode;
- IT landscape: where the forecast should go — to dispatch, maintenance management system, or driver app;
- maintenance process: how work is currently planned and who decides to take a vehicle out of service;
- contacts: who is responsible for data and who is responsible for accepting the result.
Then the discussion procedure is simple: we break down the task, look at the export, determine which failures are even predictable on your data, and come back with a stage-by-stage work plan and timeline estimate for your volume.
Describe the task and send what you have. Even a partial export provides enough to assess the feasibility of the forecast and start.
