Which vehicle data you need for predictive maintenance (and whether you need hardware)

Predictive maintenance is worth exactly as much as the data that feeds it. Before talking about algorithms, the concrete question for a fleet manager is twofold: which vehicle signals actually anticipate a failure, and where do I get them — do I have to install something, or does the vehicle already produce them? This article answers both, without inflating what’s needed.

It’s the technical deep-dive of the guide to predictive maintenance for fleets: the big picture there, the data detail here.

The signals that anticipate a failure

Not all parameters are equal: some leave a readable trace before the breakdown, others don’t. The six that really count on a vehicle:

• Diagnostic trouble codes (DTC) — the ECU generates a code the moment it detects an anomaly. It’s the most direct signal: a sensor out of range, irregular combustion, a system in protection mode. Read and translated, it anticipates the failure by days or weeks.
• Real mileage and engine hours — wear depends on actual work, not the calendar. Two identical vehicles with very different mileage shouldn’t be treated the same.
• Battery voltage and state — a weak start is one of the most common and most predictable breakdowns: the voltage trend drops before the vehicle won’t start at all.
• Driving style — harsh braking, acceleration and aggressive cornering are wear predictors for brakes, tyres and clutch. The same data that feeds eco-driving anticipates maintenance.
• Tyre pressure (TPMS) and temperatures — under-inflation and overheating precede the damage (and burn fuel in the meantime).
• Battery state of health (SoH) on electric vehicles — the key parameter of EV predictive maintenance.

The common thread: these are all signals a connected vehicle already produces. The challenge isn’t generating them, it’s reading them and turning them into an action.

Where the data comes from: three sources

The same signals can arrive via three different routes, with different depth and friction.

OBD (plug & play device). A device plugged into the OBD-II diagnostic port reads error codes and parameters on almost any vehicle, old or new. It requires an installed device, but it’s cheap and immediate — the right route especially for pre-2019 vehicles that lack native connectivity.

CAN bus (deep integration). Integrating on the CAN bus gives access to trade-specific telemetry: dedicated sensors, multi-point temperature for the cold chain, parameters specific to heavy vehicles. It’s the richest source, but it requires installation and makes sense where the deep data is genuinely needed.

Cloud OEM (no hardware). With Cloud OEM, the data arrives from the manufacturer via cloud — diagnostic codes, mileage, battery state, maintenance alerts — without installing anything, on post-2019 vehicles. It’s the same mode as fleet tracking without hardware: you activate a vehicle by adding the VIN. For Stellantis fleets (Fiat, Peugeot, Citroën…) the process runs through Mobilisights.

”Do you need to install hardware?” — the honest answer

It’s the question that matters most, and the answer isn’t a slogan: it depends on two things.

• The vehicle’s age. On post-2019 vehicles connected from the factory, standard maintenance diagnostics — error codes, battery, mileage, driving style — arrive via Cloud OEM without installing anything. On pre-2019 vehicles the native data is missing: there you need an OBD.
• The depth of data. For the ordinary predictive maintenance of a commercial fleet, the Cloud OEM data is enough. For trade-specific telemetry (multi-temperature, dedicated sensors on heavy vehicles) you need the CAN bus.

In practice, for most 2026 fleets — mostly post-2019 vehicles, standard maintenance needs — you don’t need to install hardware: the data is already there, it’s a matter of accessing it. OBD remains the right answer on the tail of older vehicles, often in a mix with Cloud OEM on the rest. The right to access this data is guaranteed by the EU Data Act.

From raw data to action: what’s needed beyond the data

Having the data isn’t yet doing predictive maintenance. Between the signal and the intervention there are four steps, and this is where raw data becomes value:

1. Reading and translation — a DTC code translated into a readable alert (“lambda sensor out of range”) instead of a warning light nobody understands.
2. Deviation monitoring — comparing the vehicle’s current behaviour with its own normal, to catch the anomaly before the critical threshold.
3. Component thresholds — defining when a value (battery voltage, pressure, temperature) becomes an alert to act on.
4. Connecting to the action — the alert that becomes a scheduled intervention, not a warning nobody reads.

This is exactly the level OptivoTrack sits at: it reads diagnostic codes, generates proactive alerts on thresholds, intelligently monitors deviations and manages service schedules on real usage data — via OBD, CAN or Cloud OEM. You choose the data source based on the fleet; the reading and the alerts are the added value. The same readings, incidentally, also feed the fuel-saving levers: an under-inflated tyre is both a maintenance risk and a fuel cost.

How much history you need (the limit worth stating)

An honest distinction that separates what works today from what’s marketing:

• Threshold and diagnostic approach (condition-based): works immediately, no history needed. You just read the data and set sensible rules on the components that strand you most.
• The model that predicts “the failure in X km” (RUL): requires a history of dated failures to train an algorithm on. On mid-sized, heterogeneous fleets that history often doesn’t exist yet — which is why you start from thresholds and diagnostics, and the pure predictive model is the direction, not the starting point.

Translation: to start you don’t need artificial intelligence, you need the right data source and a few sensible rules. The “real” predictive part you build over time, with the data you collect from today.

Frequently asked questions