Telemetry and IoT · Logistics

Vehicle telemetry joined to maintenance and fuel, so cost per kilometre became a measured number

Live tracking, route optimisation and a driver app on one platform, with IoT telemetry ingested at event grain so that cost per kilometre is calculated rather than estimated.

Client: National logistics operator, under NDA
Market: Brazil
Duration: 7 months
Year: 2024
Delivered by: The group's Brazilian engineering practice, in 2024, before Vigiles AI Ltd was incorporated.

Telemetry retained: Event grain; Sensor data kept at source grain so a specific journey remains investigable.
Cost per kilometre: Measured; Calculated from consumption, fuel and maintenance rather than apportioned.
Maintenance model: Preventive; Scheduled on odometer or hours of use instead of triggered by failure in service.
End to end: 7 months; Discovery, ingestion, portal, driver app, pilot acceptance and rollout.

The operator ran on spreadsheets and disconnected third-party trackers, with no single live view of the fleet and no dependable cost figure. One platform was built ingesting embedded IoT telemetry at event grain, joined to fuel and maintenance records, so that consumption, driving behaviour and cost per kilometre became measured rather than estimated.

On arrival

The operation ran on spreadsheets and third-party trackers that did not talk to each other, with no single real-time view of where vehicles were or what state they were in.
Routing was done by hand, which produced inefficient routes, excess mileage and late deliveries.
Maintenance was reactive. Vehicles failed in service because there was no preventive schedule driven by odometer reading or hours of use.
Driving behaviour was invisible. Speeding, harsh braking and idling with the engine running inflated both fuel cost and risk, and none of it was measured.
Telemetry from the embedded IoT equipment was not joined to the management system, which made any report on consumption or cost per kilometre an estimate rather than a measurement.

Approach

Operational discovery and route mappingReal routes, delivery windows and vehicle constraints were mapped first, because optimising a route model that does not match the operation produces plans drivers ignore.
Telemetry and geolocation ingestionEmbedded sensor and position data were ingested at event grain and retained, rather than aggregated on arrival, so that a specific journey can still be investigated later.
Web portal and the live mapPosition, route, speed and status per vehicle on one live map, replacing the third-party trackers that each held part of the picture.
Driver mobile applicationDeparture checklist, route navigation, incident logging and proof of delivery, so the record is created where the work happens rather than retyped afterwards.
Route optimisation and alertingStop sequencing against delivery windows, capacity and traffic, with automatic alerts on route deviation, speeding, harsh braking, idling and overdue maintenance.
Pilot fleet acceptance, then rolloutProven on a pilot fleet against the operation before wider rollout, which is where routing assumptions meet the drivers who have to follow them.

Solution

What was built

The operator did not lack data. It lacked data in one place at a grain that could answer a question. Position came from third-party trackers, fuel from receipts, maintenance from a spreadsheet, and nothing joined, so every cost figure was an estimate defended in a meeting rather than a number anyone could trace.
Telemetry was therefore ingested at event grain and kept there. Aggregating sensor data on arrival saves storage and destroys the ability to investigate the specific journey somebody will eventually ask about, which in a logistics operation is the question that actually matters.
With position, consumption, driving behaviour, fuel and maintenance on one base, the derived numbers became measurements. Cost per kilometre is calculated from what was consumed and spent on a vehicle rather than apportioned. Preventive maintenance is scheduled against odometer or hours of use, which is what moves a fleet off failing in service.
The driver app mattered more than it looks. A departure checklist, navigation, incident logging and proof of delivery mean the operational record is created at the point of work rather than reconstructed from paper later. Records reconstructed later are the ones that disagree.
Routing and alerting then ran on top: stop sequencing against delivery windows, capacity and traffic, with alerts on deviation, speeding, harsh braking, idling and overdue maintenance. It was proven on a pilot fleet first, because a routing model that drivers find unrealistic is quietly ignored and the data stops reflecting the operation.

What mattered

What made the difference

Live GPS tracking

Position, route, speed and status for every vehicle on one map.

Route optimisation

Stop sequencing against delivery windows, capacity and traffic conditions.

Preventive and corrective maintenance

Schedules driven by mileage or hours of use, generating work orders automatically.

IoT telemetry at event grain

Embedded sensor data for consumption, driving behaviour and diagnostics, retained rather than aggregated away.

Driver mobile application

Departure checklist, navigation, incident logging and proof of delivery.

Automatic alerting

Route deviation, speeding, harsh braking, idling and overdue maintenance.

Cost per kilometre reporting

Consumption, fuel and maintenance consolidated into measured efficiency indicators.

Driver and document management

Driver records, licence validity, hours and performance per driver.

Questions

Common questions

Because aggregation is irreversible and the question that matters is usually specific. Summarising sensor data on arrival saves storage and removes the ability to investigate the one journey, vehicle or driver somebody asks about later. In a fleet operation that is the question you get asked.

By joining consumption, fuel and maintenance to the vehicle and the journey on one base, at a grain that supports the division. An estimate apportions a total across vehicles; a measurement traces what a given vehicle actually consumed and cost. Only one of those survives a challenge.

It matters more than it looks. Checklists, incidents and proof of delivery captured at the point of work produce a record that agrees with what happened. Reconstructed later from paper, the same record disagrees, and then the reporting built on it is argued over rather than used.

Because routing is where the model meets the drivers. A sequence that is theoretically optimal and practically unrealistic gets ignored, and once drivers work around the system the data stops describing the operation. The pilot is what surfaces that before rollout rather than after.

Next step

Arrange a technical review

A 45-minute working session with an engineer rather than a sales call. You describe the problem; we set out what we would build, in what order, and what it is likely to cost.

Book a technical review Get a written estimate

Answered within one working day, by the engineer who would do the work