AI fleet management: where control over vehicles is lost
Typical picture of an average fleet: fleet telemetry is written into one service, repair requests live in an accounting system, and the maintenance plan is kept by the mechanic in a spreadsheet.
Trip data diverges from actual vehicle mileage because the trip sheet is closed upon return, not according to sensor readings. Control is lost at this junction: neither the dispatcher nor the mechanic has a complete picture of a specific vehicle.
Fragmented trip data accumulates error. Loading is planned by the log, mileage is taken from what a person entered, and no one cross-checks engine hours and fuel consumption against each other.
After a few weeks, the discrepancy becomes so large that none of the systems is suitable as a source of truth.
Manual maintenance planning finishes off the picture. Maintenance is scheduled by the calendar or by round mileage figures, not by actual load: one vehicle operates in the city with frequent stops, another runs on the highway.
Component life is consumed differently, and there is no way to predict a failure in advance — it happens during a trip.
Hence vehicle downtime. A vehicle goes out of service not in a planned window but when it breaks down: the trip is disrupted, the cargo is shifted to available transport, and at that moment there is none.
Downtime is counted after the fact, not forecast, and each such case means lost fleet hours and broken agreements with customers.
We break down how this is closed: a single data loop for each vehicle, maintenance forecasting by actual load, and alerts before a component fails.
What changes after implementation: effects by measurable metrics
We calculate the effect by telemetry, not by the dispatcher's feelings: mileage and engine hours, coordinates and time, consumption via the standard sensor, acceleration and braking events.
From this data, maintenance forecasting moves from a calendar schedule to the remaining component life — separately for each vehicle.
| Metric | How we calculate | What changes |
|---|---|---|
| Unplanned failures | share of trips with a breakdown | repair moves into a planned window |
| Vehicle downtime | from event to line release | service request is sent automatically |
| Consumption deviation | actual vs. route norm | drains and excess idling become visible |
| Driving style | trip scores: braking, acceleration, speeding | shift review based on data, not complaints |
| Incident response time | from event to alert | the on-duty operator learns about a failure within minutes |
We consolidate metrics into a single data layer and calculate them the same way for the fleet and for a specific vehicle — this is the basis for reports and alerts.
We assemble this in Wialon and our own analytics services: driving style is tied to the driver, not to the vehicle, so when the crew changes, scores do not get mixed up.
We separately maintain fuel consumption control: the norm is recalculated for the route, load, and season, otherwise the deviation shows the weather rather than a drain.
Maintenance forecasting accounts for the fact that on short city legs, component life is consumed differently than on intercity routes — by engine hours and the number of braking events, not only by mileage.
Implementation formats: cloud, on-premises, hybrid
The deployment format determines launch time, requirements for your own infrastructure, and how easy it is to change the configuration later.
We deploy a cloud fleet solution in a matter of weeks: telemetry ingestion, distribution of maintenance requests, and reporting work without purchasing servers or maintaining your own support team. On-premises deployment is chosen when data must not leave the customer's perimeter.
A hybrid integration scheme takes the best of both options: routes and driver data remain inside, while model retraining and heavy computations run in the external environment. Below is a comparison by timelines, requirements, and limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud | Fast launch is needed, no own infrastructure | Data outside the perimeter, dependence on the communication channel |
| On-premises | Strict data storage requirements, own engineers available | Longer launch, model updates follow an agreed procedure |
| Hybrid | Part of the data is closed, part may be moved outside | More complex scheme, control needed at the junction of environments |
Connecting accounting systems does not depend on the deployment format: we build exchange through standard interfaces and regular exports, reconciliation runs on a schedule, and discrepancies are handled individually — records do not diverge from the actual state of the fleet.
We separately check reversibility: a migration plan between environments with export of data and settings is prepared in advance.
Implementation stages: from data audit to handover to operation
We start with a fleet data audit: telematics, fuel cards, trip sheets, service records, and the dispatch system. We calculate the frequency of record arrival, the share of gaps and outliers, and check how vehicle, driver, and trip are matched.
This determines which tasks are solvable with the current data and which require additional equipment.
- Source survey. We reconcile vehicle, driver, and trailer reference data and analyze discrepancies between systems. The result is a list of sources with a suitability assessment and a list of gaps that we close before training.
- Data flow scheme. We design the path of a record from the vehicle to the data marts: frequency, format, enrichment with reference data, history depth. The scheme shows losses during communication outages, duplicate trips, and time desynchronization.
- Setting up rules and models. We define target events — fuel overconsumption, route deviation, downtime, wear risk — and trigger thresholds for the specific fleet. Versions are recorded: you can compare with past behavior and roll back.
- Testing on historical data. We run the logic on accumulated data: how many events are confirmed, how many turn out to be false. Thresholds are set before launch so the dispatcher does not drown in notifications.
- Pilot launch on part of the fleet. We connect a limited group of vehicles, reconcile with actual refuelings, repairs, and route sheets, and compare with a control group. This is where discrepancies invisible in history come to the surface.
- Result acceptance. We record the share of recognized trips, data latency, forecast accuracy, and the volume of processed events. We hand over documentation, train dispatchers, and leave a support procedure.
What remains with the customer: configurations, schemes, regulations
An AI fleet management system does not end the moment the service starts working: rules, roles, and trigger thresholds continue to live and change without us.
Therefore, we transfer the entire documentation set to the customer's repository — this way decisions are made within the team, not through correspondence with the contractor.
- Fleet maintenance regulation — which readings and what mileage trigger a repair request, who confirms it, and what the system does with a vehicle when maintenance is overdue.
- System integration scheme — a map of connections between telemetry, fuel cards, the accounting system, and the spare parts inventory: flow direction, behavior during a communication break, and the procedure for replaying missed data.
- Data access matrix — by role: who can see location and trip history, who works with driver personal data, and who sees only a fleet summary.
- Dispatcher instructions — handling the event queue, clearing a false positive, passing a repair to the mechanic, and recording the cause in the vehicle record.
- Mechanic instructions — accepting and closing a request from the system, what to write in the comment so the model learns from correct marks rather than noise.
- Configured thresholds and rules — current values by vehicle type with notes on which parameters change seasonally and who edits them.
- Update procedure — how to test a new version of rules on historical data, where to look when there is a discrepancy, and how to return to the previous configuration.
Each document is dated and assigned to an owner, so after handover there are no "settings that only the contractor knows about."
Case: urban delivery fleet — downtime and fuel consumption before and after
Urban delivery fleet: about two hundred vehicles on short routes, repair after breakdown, and fuel by norm.
Telemetry was written to a system but lived separately from service requests and the trip log — consumption discrepancies were identified at the end of the month, when the vehicle had already stood idle for extra shifts.
What was and what was changed
We assembled a fleet implementation case with a single data loop: telemetry from Wialon, service request history, and trips by route.
The model calculates two things — the risk of component failure based on accumulated load and the probability of consumption deviation on a specific route, taking into account load and season.
The assessment reaches the dispatcher before the vehicle goes on the line, but remains a recommendation.
Metrics before and after
The difference was made not by the model itself but by linking the forecast to the maintenance schedule and trip planning: risk enters the request in advance, and a consumption anomaly enters the shift review.
A false positive does not remove the vehicle from the schedule — the dispatcher sees the mark and checks it personally. Forecast rules are versioned; when seasonality changes, they are rebuilt on fresh data without rewriting the telematics exchange.
How telemetry-based forecasting differs from mileage reminders
A threshold rule is one number for the entire fleet: we change oil every N engine hours, mileage reminders arrive at a fixed odometer mark. The scheme works honestly as long as all vehicles drive the same way.
A long-haul tractor and a city van with equal mileage wear differently, so some vehicles are serviced ahead of schedule, while others run until failure.
Telemetry-based forecasting counts not the odometer but accumulated load: the share of time under full load, the number of cold starts, operating temperatures, route terrain, and driving style.
The model estimates the remaining component life and answers not "is it time or not" but "in how many days the parameter will cross the boundary."
Data is taken from what is already installed on the vehicle: telematics terminal, level and pressure sensors. We take the stream from telematics platforms (for example, Wialon) or directly, bring it to a single schema, and only then build the model.
We measure forecast accuracy by horizon: a warning arrives 7–14 days before the parameter crosses the boundary — this is enough to fit the repair into the schedule rather than pull the vehicle out of a trip.
The share of false positives drops several times over because the system reacts to a trend, not to a one-off sensor outlier.
Threshold rules are not discarded: they remain a safety loop for critical parameters — oil pressure, temperature — and take over control when telemetry disappears. The working scheme is a hybrid: hard cutoffs catch an accident, and the model plans maintenance.
Common technical doubts before starting the project
Doubts before starting are usually not about the value of the idea but about feasibility: whether it will be possible to assemble a reliable picture from vehicles of different makes and years, whether already installed equipment will have to be replaced, and who inside the company will see data for each trip.
Below are the four questions engineering teams ask most often.
We have vehicles with different trackers — will the equipment have to be replaced?
No. We build a normalization layer: telemetry from different manufacturers is brought to a single model — coordinates, mileage, consumption, vehicle events. Where a device does not provide the required fields, data is gathered from standard exports and the driver app. The fleet remains on the equipment already installed.
What happens if data arrives incomplete?
The system works with gaps rather than crashing on them. Confidence is calculated for each signal: if a tracker is silent or provides contradictory values, the segment is marked as unreliable rather than guessed by the model.
For fuel and usage calculations this is fundamental — an error there is more costly than an honest gap.
Who inside the company will get access to fleet data?
Access is granted by role: the dispatcher sees their trips, the department head sees summaries, and exporting raw data is a separate right. Data access is logged, and transfer and storage are encrypted. Deployment is possible in your environment, without moving telemetry outside.
Can the project be launched in stages?
Yes, and we recommend exactly that. The first stage is one group of vehicles and one scenario, for example route deviation control. Data quality and the effect are tested on a live fleet, then the remaining groups and scenarios are connected. The first result is visible before the entire fleet is pulled into the project.
Let's discuss the task and come back with an estimate and work plan
For the fleet project estimate to be substantive rather than a "rough range," at the input we need a minimum of context about the current environment: what data is already collected, where it comes from, and at what frequency.
Nothing needs to be specially prepared — exports, schemes, and screenshots of interfaces that are at hand are enough. We will clarify the rest with questions at the first meeting.
What to send and what we will review in the task discussion:
- List of data sources: telematics, fuel cards, trip sheets, repair records, spare parts inventory — and in what form records come from them.
- Scenarios that hurt the most: consumption control, wear forecasting, maintenance planning, distribution of vehicles across routes, downtime.
- Limitations: who has what rights to data, whether storage on your own servers is required, and how contractor access to the fleet is arranged.
- Regulations and standards: maintenance frequency, consumption norms, dispatcher priorities when requests conflict — these are exactly what turn into model rules.
- Who on the customer side accepts the result and by what metrics they will consider that things have improved.
Based on the conversation, we send an implementation plan: stages, what we do at each, what data we need from you, and when we expect feedback.
We assemble the technical specification from the same discussion — we record scenarios, sources, limitations, and acceptance criteria so they are not reopened in the middle of the work.
