Vehicle Telematics: Improving Fleet Management

Modern fleets generate more data per kilometre than most engineering teams know what to do with. This post breaks down how vehicle telematics systems are built, what the data actually tells you, and where the real implementation challenges sit.

What Does a Vehicle Telematics System Actually Consist Of?

At its core, a telematics system is a combination of hardware on the vehicle and software in the cloud. The hardware side is usually an OBD-II dongle or a hardwired ECU-connected device that reads CAN bus data, captures GPS co-ordinates via GNSS (typically combining GPS, GLONASS, and sometimes Galileo for better accuracy), and transmits over cellular, usually LTE-M or NB-IoT for low-power deployments, or standard 4G LTE where bandwidth matters.

The data stream from a single vehicle running at full telemetry can push anywhere from 1 KB/s to 10 KB/s depending on the polling rate and the number of sensors active. Multiply that across a fleet of 500 vehicles and you are looking at sustained ingestion loads that need proper pipeline architecture, not a single Postgres instance.

What Lives on the Vehicle

The on-device firmware handles local buffering when connectivity drops, trip segmentation, and sometimes edge-level anomaly detection. Devices running on RTOS environments like FreeRTOS or Zephyr can process rudimentary driver behaviour scoring locally, which reduces the amount of raw data you need to transmit. This matters in geographies with patchy network coverage or where SIM data costs are high.

What Lives in the Cloud

The backend is where most of the interesting engineering happens. A typical stack involves:

• An MQTT broker (Mosquitto or EMQ X) or a managed service like AWS IoT Core for device connectivity
• A time-series database, InfluxDB or TimescaleDB being the most common choices, for storing sensor readings
• A stream processing layer, Apache Kafka with Flink or Kafka Streams, for real-time event detection
• A geospatial layer, PostGIS or BigQuery's geography functions, for route analysis and geofencing

The choice between TimescaleDB and InfluxDB is worth pausing on. TimescaleDB runs on top of Postgres, which means your existing team can operate it and you can join telemetry data with your business data in standard SQL. InfluxDB's Flux query language is more expressive for pure time-series work but introduces a learning curve and a separate operational boundary. For most fleet management products, TimescaleDB wins on total cost of ownership.

How Do You Turn Raw Telemetry Into Actionable Fleet Insights?

Raw CAN bus data is not human-readable. A vehicle might expose 2,000 or more PIDs (Parameter IDs), and only a subset are relevant to fleet operations. The practical work is in building a normalisation layer that maps device-specific data into a canonical schema, then feeding that into derived metrics.

The derived metrics that actually drive fleet decisions are:

• Fuel consumption per route segment, not per trip, because aggregate trip data hides the sections where a driver is idling or accelerating hard
• Harsh event counts: hard braking (typically defined as deceleration exceeding 0.4g), harsh acceleration, and sharp cornering above a defined lateral g threshold
• Engine fault codes (DTCs) surfaced in near-real-time so maintenance teams can act before a fault escalates
• Driver fatigue indicators derived from trip duration, time-of-day, and erratic steering patterns, though these are probabilistic and should not be the sole basis for intervention

Fuel and maintenance cost reduction is where telematics ROI is most legible. Studies across fleet operators in the logistics sector consistently show 10–15% fuel savings after implementing telematics-informed driver coaching programmes. Maintenance cost reductions of 10–25% are achievable when DTC alerts are acted on early rather than at scheduled service intervals.

What Are the Real Engineering Challenges Nobody Talks About?

Device heterogeneity is the main one. A mixed fleet running vehicles from multiple OEMs, model years spanning a decade, and devices from two or three different hardware vendors means your normalisation layer has to handle protocol differences, firmware version inconsistencies, and gaps in PID support. This is not a one-time mapping exercise. It is ongoing maintenance work.

Clock drift is underappreciated. GPS timestamps are reliable, but when a device loses satellite lock and falls back to its onboard RTC, you can get time skew of several seconds. In a stream processing pipeline where you are joining events from multiple sensors within the same vehicle, a 3-second skew can corrupt event sequencing. You need watermarking strategies in your Flink or Kafka Streams jobs to handle late and out-of-order events correctly.

Data privacy is the other area where teams underestimate complexity. In the EU, vehicle location data is personal data under GDPR if it can be linked to an identifiable driver. That means you need a legal basis for processing, defined retention periods, and the ability to respond to subject access requests. If you are building a telematics platform for a European market, these requirements need to be in the architecture from the start, not retrofitted later.

Predictive Maintenance: Where Telematics Gets Genuinely Useful

Reactive maintenance costs more than predictive maintenance. That is well established. The engineering challenge is building models that are accurate enough to be trusted.

The most reliable approach starts with rule-based alerts on known thresholds: coolant temperature above 105°C, battery voltage below 11.8V at rest, oil pressure outside spec. These are deterministic and immediately actionable. Overlay statistical models on top, trained on your fleet's historical fault-to-failure sequences, and you can start to predict which vehicles are likely to require intervention in the next 7 or 14 days.

The models that work best in production are gradient boosted trees (XGBoost, LightGBM) trained on tabular telemetry features, not deep learning models. The interpretability matters when a maintenance manager needs to explain to a driver why their vehicle is being taken off-road. A feature importance plot from XGBoost is a usable conversation tool. A neural network's internal weights are not.

Model retraining cadence is something teams often set and forget. Vehicle populations change, seasonal patterns shift fuel consumption baselines, and driver turnover affects behaviour distributions. A monthly retraining schedule with automated performance monitoring against a holdout set is a reasonable starting point.

Route Optimisation and Geofencing

Route optimisation is often conflated with telematics, but they are separate concerns. Telematics tells you what happened. Route optimisation tells you what should happen. The integration point is using historical speed and dwell time data from telemetry to build more accurate travel time models for your optimisation solver.

Geofencing is simpler to implement but frequently overengineered. A circular geofence calculated server-side using the Haversine formula is sufficient for most use cases. Polygon geofences using PostGIS's ST_Contains function are appropriate for complex site boundaries. Event-driven architectures work well here: a Kafka topic per geofence event type, consumed by downstream services that handle notifications, billing triggers, or compliance logging.

Conclusion

If you are building a fleet telematics platform, start with the data pipeline. Get ingestion, normalisation, and storage right before you build dashboards or models. The analytics layer is only as good as the data underneath it.

The next concrete step is to audit your device data against a canonical schema. If you cannot map 80% of your fleet's PID output to a consistent schema today, your reporting and your ML features will be inconsistent. Fix the foundation first.

---

FAQ

What connectivity protocol should I use for vehicle telematics devices? LTE-M is the right default for most fleet applications. It offers lower power consumption than standard 4G LTE, adequate bandwidth for telemetry payloads, and better building penetration. NB-IoT works for low-frequency, low-bandwidth data but is too constrained if you need near-real-time DTC alerts or sub-minute GPS polling.

How often should telemetry data be polled from a vehicle? It depends on the use case. Driver behaviour scoring typically needs GPS and accelerometer data at 1 Hz or higher. Fuel level and engine temperature can be polled every 30 to 60 seconds without meaningful loss of fidelity. Polling everything at 1 Hz across a large fleet creates unnecessary data volume and cost.

Is OBD-II access sufficient for a production telematics deployment? For light commercial vehicles and passenger cars, OBD-II gives you enough to build a useful product. For heavy vehicles running J1939 over CAN, you need a device that speaks the J1939 protocol directly. OBD-II dongles plugged into a J1939 truck adapter often miss a significant portion of the available data.

What is the biggest mistake teams make when building fleet analytics? Building dashboards before validating data quality. It is common to launch a fuel efficiency dashboard only to discover that odometer readings from different device firmware versions are being parsed differently, making the underlying metric unreliable. Invest in data quality checks at ingestion time.

When does it make sense to process data on the device versus in the cloud? Edge processing makes sense when connectivity is intermittent, when you need immediate local action (like an in-cab alert on a harsh braking event), or when the cost of transmitting raw data is prohibitive. Cloud processing makes sense for anything requiring historical context, cross-vehicle analysis, or model inference that is too computationally heavy for the device's MCU.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.