Predictive maintenance for fleets: start with the data you already have

The standard pitch for fleet predictive maintenance starts with hardware: instrument every vehicle, stream vibration and temperature data, then let machine learning find failures before they happen. For most fleets that is the wrong first step. The workshop history, odometer readings, diagnostic trouble codes and telematics feeds a fleet already collects contain enough signal to predict a useful share of failures today, at a fraction of the cost. This article covers what that existing data can do, where to start, when heavier ML is justified, and the pitfalls that make pilots look better than production.

The sensor-first assumption, and why it delays everything

Predictive maintenance vendors tend to open the conversation with new instrumentation: accelerometers on axles, oil-quality sensors, acoustic monitoring, a dedicated IoT platform to carry it all. The proposal is technically sound and commercially convenient, and it postpones any actual prediction by twelve to eighteen months. Hardware has to be selected, installed across hundreds of vehicles, and left running long enough to accumulate failure examples. Only then does modelling begin, on a dataset that starts from zero.

Meanwhile the fleet has been generating maintenance-relevant data for years. Every work order, every inspection, every odometer reading, every diagnostic code pulled at the workshop is a record of how these specific vehicles fail, under these specific duty cycles, maintained by these specific workshops. That history is the single most valuable asset for failure prediction, and no new sensor produces it retroactively.

The practical sequencing is the reverse of the vendor pitch: build the first predictive capability on the data already in house, learn which failure modes it does and does not catch, and only then decide whether additional instrumentation closes a gap worth its cost. Sensors answer questions. The existing data tells you which questions are worth asking.

The four sources most fleets already have

Workshop and work order history. The maintenance management system, or in smaller fleets the invoicing system, records what was repaired, on which vehicle, at what date and mileage, at what cost. This is where failure labels come from: the ground truth of which component failed when. It is also the messiest of the four sources, which the pitfalls section returns to.

Odometer and engine-hour readings. Usage is the strongest single predictor of wear-driven failure. Readings captured at each workshop visit, fuelling or telematics ping turn a static vehicle list into usage trajectories: which trucks accumulate kilometres fastest, which sit idle, which pattern of short urban cycles is grinding through brake components.

Diagnostic trouble codes. Every vehicle built in the last two decades continuously self-reports through OBD or the J1939 bus on heavy vehicles. Fault codes are noisy, many are transient or trivial, but their patterns carry signal: a code that recurs across three consecutive weeks, a cluster of codes from related subsystems, a code that historically preceded a specific repair by a predictable interval. Most fleets log these codes somewhere and analyse them nowhere.

Telematics. Fleets that run telematics for routing and driver behaviour are sitting on GPS traces, speed profiles, idling time, harsh braking and acceleration events, and often engine parameters like coolant temperature and battery voltage. Collected for operations, this data doubles as a duty-cycle description per vehicle: two identical tractors on identical mileage can have very different failure profiles if one runs motorway line-haul and the other urban distribution.

None of these sources was designed for prediction. Together they describe usage, condition signals and failure outcomes, which is exactly the triad a predictive model needs.

Where to start: one failure mode, one question

The common way to stall is to frame the project as "predict all failures on all vehicles". The workable framing is narrower: pick one or two failure modes that are frequent enough to model and expensive enough to matter, typically the ones behind the most roadside breakdowns or the largest unplanned downtime. Batteries, starters, alternators, brake components, EGR and aftertreatment systems are frequent first candidates on commercial fleets.

Then phrase a question the data can answer. Two formulations cover most cases:

• Time to event: given this vehicle's age, usage trajectory and repair history, what is the expected remaining life of this component? Survival analysis, the same family of methods used for decades in reliability engineering, handles this well and produces interpretable outputs like a hazard curve per component.
• Near-term risk: given the last 30 days of fault codes, usage and telematics signals, what is the probability of a breakdown in the next 14 days? This is a standard classification problem, and a gradient-boosted model on tabular features is a strong, boring baseline.

Both formulations run on the four data sources above. Neither requires new hardware.

What a simple model already catches

There is a wide band of value between a fixed service schedule and deep learning on sensor streams, and most fleets have claimed none of it.

A fixed schedule services every vehicle at the same interval regardless of duty cycle, which means some vehicles are over-maintained and others fail between services. The first improvement is not machine learning at all: usage-based scheduling, driven by actual odometer and engine-hour trajectories instead of calendar time, already reallocates maintenance effort toward the vehicles consuming their components fastest.

The next step up, and still a modest one, is pattern rules over fault codes: recurring-code alerts, known precursor codes for specific failures, cross-checks between coolant temperature trends and cooling-system repairs. These rules are transparent, cheap to run, and workshop teams trust them because they can read them.

A first statistical model then builds on the same foundation. Survival curves per component fitted on the fleet's own work order history answer questions a schedule cannot: which specific vehicles are in the highest-risk decile for battery failure this quarter, and should be prioritised when they next pass through the workshop. In fleet reliability work, this level routinely surfaces a double-digit share of the failures that previously arrived as roadside surprises, and it does so with methods a single analyst can own.

The pattern mirrors what we see in MLOps generally: the constraint is rarely model sophistication. It is getting any model connected to real maintenance decisions, reliably, with someone accountable for it.

When heavier ML is justified

Sophisticated approaches earn their place when specific conditions hold, and are wasted before then.

High-frequency sensor models, vibration analysis, acoustic monitoring and their deep learning toolchain make sense when the failure mode is expensive and gives little warning in existing data. Bearing and driveline failures on high-utilisation heavy vehicles are the textbook case: by the time a fault code appears, the damage is done, and only vibration signatures move early enough. That is a targeted instrumentation decision for a known gap, made after the simple models have shown where their ceiling is.

Fleet-wide learned models over telematics streams justify themselves at scale: several hundred vehicles or more, consistent data collection, and an operations team that will actually act on per-vehicle risk scores. Below that scale, the model may be trainable, and the organisational machinery to use it is usually the missing piece.

The honest test for any escalation is incremental: what does this addition catch that the current level does not, and does that difference pay for the added infrastructure and the added operational burden? A model that is 4% better and twice as opaque is frequently a worse system, because workshop planners stop trusting what they cannot interrogate.

The pitfalls that flatter pilots and ruin production

Hand-entered workshop data. Work orders are written by mechanics under time pressure, and it shows: free-text repair descriptions where the same failure is recorded ten different ways, repairs booked days after they happened, odometer fields typed with a digit missing or left at zero. Since work orders are the source of training labels, this noise goes straight into the model's ground truth. Budget real effort for label construction: mapping free text to a component taxonomy, cross-validating dates against telematics, flagging impossible odometer sequences. This is unglamorous data quality work, and it determines the ceiling of everything built on top.

Target leakage. The classic failed pilot trains on a snapshot of the maintenance database and reports excellent accuracy, because features leaked information from the future: a fault code logged during the breakdown itself, a work order opened before the failure being predicted, a "days since last repair" feature computed with knowledge of the repair that followed. The model has learned to recognise breakdowns that already happened. Every training example must be built point-in-time: only information available before the prediction date, with the outcome window strictly after it. This is the same discipline feature stores enforce with point-in-time joins, and doing it by hand demands care.

Thresholds never recalibrated. A risk model outputs scores; someone chooses the threshold that turns scores into workshop alerts. That threshold gets tuned once at launch, and then the world moves: the fleet ages, new vehicle generations arrive with different failure profiles, routes shift, workshops change behaviour in response to the alerts themselves. Two years later the system fires so many false alarms that planners ignore it, or has gone quiet while failures return. Alert precision and failure recall are operational metrics to review on a schedule, with retraining and threshold recalibration as routine activities. A predictive maintenance model is a living system with an owner, with the same monitoring and drift discipline as any production model.

A realistic first project

Scoped this way, a first predictive maintenance capability is a data engineering project with a modest modelling layer: consolidate work orders, odometer history, fault codes and telematics into one analytical base per vehicle; construct clean failure labels for one or two component groups; fit survival baselines and a near-term risk classifier; wire the output into the existing maintenance planning routine, as a ranked worklist rather than a new tool nobody opens. A quarter of focused work gets a fleet from a fixed schedule to usage-informed, risk-ranked maintenance, and produces the evidence needed to decide whether sensors deserve the next investment.

How DNA Solutions helps

DNA Solutions builds data platforms and predictive analytics for European fleet and transport operators, from consolidating workshop and telematics data into a reliable analytical base to putting risk models into production with the monitoring and recalibration they need to stay trusted. We start from the data a fleet already has, and we size the modelling to the decisions it will actually drive. If your maintenance is still running on a fixed schedule while your systems fill up with unused history, talk to us.