Fleet Management: Optimizing Operations

Fleet operations generate more data than most engineering teams know what to do with. GPS pings every few seconds, fuel logs, driver behaviour events, maintenance records, route deviations — the volume is large and the signal-to-noise ratio is often poor. This post covers the architectural and operational decisions that actually matter when you're building or scaling a fleet management system.

What Does a Fleet Management System Actually Need to Do?

The core job is simple: know where every asset is, know its state, and act on that information quickly enough to matter. Everything else is downstream of those three things.

In practice, "state" means more than location. It means engine health via OBD-II or CAN bus data, fuel level, driver identity, cargo sensor readings if the vehicle is refrigerated or carrying sensitive goods, and compliance status (hours of service, inspection records). A system that only does GPS tracking is a telematics system. A fleet management system ties all of these together and surfaces actionable information.

The technical boundary that matters most is real-time versus near-real-time. Dispatching decisions need sub-second latency. Maintenance scheduling can tolerate a few minutes of lag. Route optimisation for tomorrow's runs can be a batch job. Designing one data pipeline to serve all three use cases is a common mistake. Use Apache Kafka or AWS Kinesis for the real-time stream, a time-series store like InfluxDB or TimescaleDB for telemetry history, and a standard relational database (PostgreSQL works fine) for operational records.

How Do You Handle Real-Time Vehicle Tracking at Scale?

At low fleet sizes — say, under 200 vehicles — almost anything works. The problems start around 500 to 1,000 active vehicles, when a naive polling architecture starts to show latency and cost issues.

The Protocol Choice Matters Early

Most telematics hardware speaks MQTT or a proprietary TCP protocol. MQTT is the right default: it's designed for unreliable networks, supports QoS levels 0, 1, and 2, and has mature broker implementations (Mosquitto, EMQX, HiveMQ). If your devices are in areas with intermittent connectivity, QoS 1 with persistent sessions handles reconnection gracefully.

The broker sits in front of your stream processor. A single EMQX node handles around 1 million concurrent connections; at fleet scale, you're unlikely to hit that ceiling unless you're also ingesting high-frequency sensor data per vehicle.

Geospatial Indexing

Storing raw lat/lon coordinates and running distance queries against them is expensive. Use PostGIS for geofencing and zone queries, or H3 (Uber's hexagonal grid system) for hierarchical spatial indexing. H3 is particularly good for aggregation: you can roll up vehicle density at resolution 7 (average hexagon area ~5.16 km²) for dashboards and drill down to resolution 11 (~0.0003 km²) for precise geofence triggers.

Route Optimisation: Where the Engineering Gets Interesting

Basic routing is a solved problem. Google Maps Platform, HERE Routing API, and OpenRouteService all give you good routes with real traffic data. The hard part is multi-stop vehicle routing with constraints — the Vehicle Routing Problem (VRP), specifically its constrained variants.

Commercial solvers like Google OR-Tools (open source, Apache 2.0) and Vroom handle most real-world VRP variants: time windows, capacity limits, driver break requirements, mixed fleets. OR-Tools with a guided local search metaheuristic finds solutions within 2-5% of optimal for problems with up to a few hundred stops in under a minute on a single core. Beyond that, you need to partition the problem or accept longer solve times.

The constraints that catch teams off guard are:

• Hours of service rules — in India, commercial vehicle driver limits are set by state motor vehicle acts and vary. In the EU, the AETR agreement caps driving at 9 hours per day (extendable to 10 hours twice a week). Your solver needs these rules encoded, not approximated.
• Vehicle-specific road restrictions — height, weight, and axle load limits that vary by road class and state.
• Dynamic re-optimisation — when a vehicle breaks down or a delivery fails, you need to re-solve a partial problem in near real-time without disrupting the rest of the route plan.

Dynamic re-optimisation is where most off-the-shelf tools struggle. A practical approach is to keep a warm solver instance per active dispatch run and re-solve only the affected cluster of stops rather than the full problem.

Predictive Maintenance: What's Actually Useful vs. What Sounds Good in a Pitch

Predictive maintenance is one of those areas where the gap between the demo and the production system is wide.

The useful signals are engine fault codes (SAE J1939 for heavy vehicles, OBD-II for light commercial), odometer-based service intervals, battery voltage trends, and tyre pressure from TPMS sensors. These are interpretable, have known failure modes, and can drive actionable alerts.

The less useful path is training a generic anomaly detection model on raw CAN bus data without domain-specific labelling. You'll surface a lot of noise. A diesel engine running a DPF regeneration cycle looks anomalous if your model hasn't seen it before.

A practical stack: ingest OBD/J1939 data into TimescaleDB, run rule-based alerts for known fault codes, and layer a simple gradient boosted model (XGBoost or LightGBM) trained on labelled historical breakdowns to score vehicles by failure risk. This beats a complex deep learning approach on fleet data because fleet datasets are small relative to the number of variables, and interpretability matters when a maintenance manager needs to explain why a truck is being pulled off a route.

Approach	Setup time	Interpretability	Data requirement
Rule-based (fault codes + intervals)	Days	High	Low
Gradient boosted model	Weeks	Medium	Medium (months of labelled history)
LSTM / deep learning	Months	Low	High (years of diverse data)

How Do You Integrate Fleet Data with ERP and Finance Systems?

Fleet doesn't exist in isolation. Fuel costs, maintenance spend, depreciation, driver pay, and route profitability all need to flow into financial reporting. The integration points are usually with SAP, Oracle, Microsoft Dynamics, or a mid-market ERP like Tally or Zoho Books.

The cleanest pattern is an event-driven integration layer. Fleet events (trip completed, fuel filled, maintenance job closed) publish to an internal event bus. ERP connectors subscribe and post the appropriate transactions. This decouples the fleet system from ERP version upgrades and makes it straightforward to swap out either side.

Avoid direct database integrations between fleet and ERP systems. They create tight coupling, break on schema changes, and make auditing difficult. REST or webhook-based integrations with idempotency keys are the baseline; for high-volume transactional data, a message queue like RabbitMQ or Kafka is worth the added complexity.

Conclusion

The architecture decisions that matter most in fleet management are the ones you make early: data pipeline design, protocol choice for device communication, and how tightly you couple the fleet system to adjacent business systems. Get those right and the feature layer above them is straightforward to build and maintain.

If you're scoping a fleet management build or evaluating what to rebuild in an existing system, start by mapping your actual latency and data volume requirements before choosing any infrastructure. The right answer at 100 vehicles is usually not the right answer at 5,000.

FAQ

What is the best protocol for vehicle telematics data? MQTT is the standard choice for most fleet deployments. It handles unreliable mobile networks well, supports three quality-of-service levels, and has mature open-source broker implementations. For high-frequency CAN bus data from vehicles on reliable connectivity, a raw TCP connection to a custom ingestion service can reduce overhead.

How accurate is GPS tracking for commercial vehicles? Standard GPS accuracy is 3 to 5 metres under open sky. In urban canyons or under dense tree cover, accuracy degrades to 10 to 50 metres. For most fleet use cases — ETA calculation, geofencing, proof of delivery — this is sufficient. Applications requiring lane-level accuracy need differential GPS or GNSS augmentation services.

When does predictive maintenance actually pay off? It pays off when your fleet is large enough to generate statistically meaningful failure history (typically 50 or more vehicles of a similar type) and when the cost of unplanned breakdowns significantly exceeds the cost of early maintenance. For small or highly varied fleets, rule-based maintenance scheduling often delivers better ROI with far less engineering effort.

Can fleet management systems comply with driver privacy regulations? Yes, but it requires deliberate design. In the EU, fleet telematics falls under GDPR. Driver location data is personal data and requires a lawful basis, usually legitimate interest or contractual necessity. Practically, this means data minimisation (not storing raw location history beyond what's needed), clear driver notification, and access controls that limit who can query individual trip data.

Is it better to buy a fleet management platform or build one? For standard requirements — tracking, basic route planning, maintenance alerts — buying is almost always faster and cheaper. Build when your operational constraints (unusual vehicle types, proprietary integrations, regulatory requirements specific to your market) mean existing platforms don't fit without significant customisation, or when fleet operations are core to your competitive differentiation.

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