GPS Fleet Tracking and Telematics

Fleet tracking is one of the easiest technology purchases in an asset-heavy organisation to get approved and one of the easiest to under-use. The business case writes itself in a sentence, the hardware is cheap relative to the vehicles it sits in, and within a fortnight of installation somebody in the operations office has a live map with moving icons on it. That map is genuinely satisfying to look at. It is also, in my experience across CMMS, EAM and fleet-adjacent implementations, the least valuable thing the system produces. The valuable output is quieter: a reliable, automatic, tamper-resistant feed of odometer and engine-hours readings, plus fault codes, arriving in the system that plans your maintenance. Most fleets buy telematics for the map and never connect the part that would have paid for it.

The message up front: telematics produces three distinct products from one box, and they are not equally valuable. Location answers operational questions. Vehicle data from the engine bus is what drives maintenance and is the highest-return output by a wide margin. Driver behaviour inference is the most heavily marketed and the most fragile, because it is a management tool dressed as a measurement. Buy for all three if you like, but scope the project around the second one and wire it into your maintenance system, or you will have spent the budget on a map.

1. What telematics actually is, and the three things it produces

Strip away the branding and a telematics unit is a small computer with three capabilities: it knows where it is, it can listen to the vehicle's own electronics, and it has a way to send both of those somewhere over a cellular network. Everything a platform shows you is derived from those inputs. Understanding which of the three a given feature depends on is the single most useful mental model you can carry into a vendor demo, because it tells you immediately whether a claimed capability is a measurement or an inference.

• Location and movement. A satellite positioning fix, sampled at some interval, giving latitude, longitude, speed over ground, heading and a timestamp. From this the platform derives trip histories, route replays, idle time, stop durations, mileage by road segment and geofence crossings. This is the layer everybody buys and the layer that answers dispatch and utilisation questions.
• Vehicle data from the engine bus. Readings the vehicle itself already computes and publishes internally: odometer, engine hours, engine speed, coolant temperature, fuel level, battery voltage, diagnostic trouble codes. This is not inferred from movement, it is read from the vehicle. It is the layer that makes maintenance scheduling automatic and the layer most often left switched off or unmapped because nobody downstream asked for it.
• Driver behaviour inference. Accelerometer and positioning data interpreted into events: harsh braking, rapid acceleration, cornering force, speeding against a posted or configured limit, seatbelt use where the bus exposes it. Note the word inference. The unit measures forces and speeds; the platform decides, using thresholds somebody chose, that a given pattern of forces constitutes bad driving.

Of the three, the one that creates durable value for a maintenance function is the second. Location tells you where a vehicle was. Behaviour scoring tells you a contestable story about how it was driven. Engine hours and odometer, arriving automatically and without a technician writing a number on a clipboard, tells your planning system when the vehicle is due, which is the thing your maintenance programme has probably been guessing at. If you want the broader context of how usage counters drive schedules rather than calendars, that mechanism is covered properly in meter-based and usage-based PM in a CMMS, and I will not restate it here.

2. The hardware options compared honestly

There are four realistic hardware routes and they are not interchangeable. Choosing badly is the most common early mistake, usually because a pilot was run on plug-in devices and then rolled out across a mixed fleet where plug-in devices were the wrong answer for two thirds of the assets. Decide the hardware per asset class, not per fleet.

The pattern I would recommend for a mixed fleet is unapologetically mixed hardware: hardwired units on owned heavy vehicles and anything with body equipment worth monitoring, plug-in devices on short-lease light vehicles where the install cost cannot be recovered over the holding period, the manufacturer's own feed where the fleet is single-make and the programme is genuinely open, and low-cost asset trackers on the unpowered plant that currently goes missing. Insisting on one device type across the whole fleet for tidiness costs more than the untidiness saves.

3. What CAN bus and J1939 give you that GPS alone cannot

A positioning fix can tell you a vehicle moved from one place to another and therefore approximately how far it travelled. It cannot tell you what the odometer says, how many hours the engine ran while stationary, whether the coolant is running hot, or that the engine management system has logged a fault. All of that comes off the vehicle's internal network, and this is where the maintenance value lives.

Two families of standards matter in practice. Light vehicles expose a standardised diagnostic interface that carries a common set of parameters, which is what plug-in devices read. Heavy vehicles, buses and off-highway plant typically use the heavy-duty standards maintained by SAE International , commonly referred to by the J1939 family, which carry a far richer set of parameters and a structured fault-code scheme. The practical consequence is that a heavy fleet with hardwired units on the heavy-duty bus can get genuinely detailed vehicle health data, while a light fleet on plug-in devices gets a thinner and less consistent set that varies by manufacturer.

The three parameters worth fighting for, in priority order:

• Odometer. The real, vehicle-reported value, not a distance total the platform accumulated from positioning fixes. Accumulated distance drifts, loses trips when signal is lost, and will not match the number on the dashboard, which means the first time a technician compares the two, trust in the feed evaporates. If a device cannot read true odometer on a given vehicle, know that before you build a schedule on it.
• Engine hours. For anything that spends significant time running while stationary, hours are a better proxy for wear than distance. A refuse vehicle, a generator on a site, an aerial platform, a vehicle idling in heat with the air conditioning loaded: distance travelled understates the work done. Hours capture it.
• Diagnostic trouble codes. Fault codes raised by the vehicle's own control units, delivered as they occur rather than discovered at the next service. Useful, with one important qualification I come to below.

The honest position on fault codes: they are a triage input, not a work order. Fleets that pipe every code straight into an alert queue quickly learn that a large share are transient, environmental, or already known, and the queue gets ignored. The pattern that works is to select a small set of codes that genuinely indicate an actionable developing fault for your vehicle types, route those into the maintenance workflow, and log the rest for later analysis rather than pushing them at a human. Start narrow and widen as you learn which codes on your fleet actually mean something.

4. Driver behaviour scoring, and its honest limits

Driver scoring is the feature most likely to be demonstrated enthusiastically and least likely to survive contact with a workforce. The mechanism is straightforward: the device measures acceleration in three axes and speed over ground, the platform applies thresholds, and events above those thresholds become harsh braking, harsh acceleration, harsh cornering or speeding. Events are weighted, aggregated per driver, and turned into a score and a league table.

There are real limits to how much that score tells you, and a buyer should hear them before the rollout rather than after:

• Thresholds are chosen, not discovered. A default harsh-braking threshold set for a saloon car will fire constantly in a loaded tipper and rarely in a bus. Until the thresholds are calibrated per vehicle class, the league table mostly ranks vehicle types, not drivers.
• Context is invisible. Hard braking to avoid a collision is good driving and scores as bad driving. A driver working congested urban routes will accumulate more events than one on open highway regardless of skill. Comparing drivers across different route profiles is comparing route profiles.
• Mounting and device quality affect readings. A poorly secured unit registers vibration as events. Two different device models on the same fleet will not produce comparable scores.
• Speeding detection depends on a limit source. Matching position to a posted speed limit requires an accurate, current map layer. Where that layer is wrong, and in fast-developing road networks it often is, the violations are wrong too.
• The link to actual safety outcomes is a correlation, not a measurement. Event rates and incident rates are related, and there is reasonable evidence that coaching on them helps. That is not the same as a score being a reliable measure of how safe an individual driver is.

5. Dashcams and video telematics

Video is the fastest-growing part of this market and the one where the case for and against is most sharply drawn. A forward-facing camera that captures a short clip around a harsh event solves a real and expensive problem: liability disputes after a collision, where the fleet's version of events is otherwise one driver's word against another's. For fleets carrying significant third-party risk, that alone can justify the deployment, and it is the one telematics feature where drivers themselves frequently support it once they understand it protects them from false claims.

Inward-facing cameras are a different conversation. A camera pointed at the driver, particularly one running continuously or using automated detection of distraction or fatigue, is workplace surveillance of an individual during their working day. It may be entirely defensible in a given operation, and in some regulated transport contexts it is expected. But it is not the same decision as a forward-facing camera, it should not be waved through as part of the same purchase, and the questions it raises are covered in section eight rather than brushed past here.

The practical considerations that get overlooked: video consumes data and storage at a different order of magnitude from telemetry, so event-triggered upload with local storage for everything else is the norm rather than continuous streaming. Retention periods need a deliberate decision rather than a default. Who can request and view a clip, and on what grounds, needs to be written down. And the review workload is real: a fleet that enables automated event clips without assigning someone to triage them ends up with a video archive nobody watches, which is cost without benefit.

6. Geofencing: what it is genuinely good for

A geofence is a boundary drawn on a map with rules attached to crossing it. It is the most mundane telematics feature and quietly one of the more useful, provided it is applied to processes rather than to people.

The applications that earn their keep in my experience:

• Automatic arrival and departure timestamps at customer sites, depots or facilities, removing a manual step from job records and settling disputes about attendance times without anyone being accused of anything.
• Site-based utilisation. Time on site versus time in transit, aggregated across a month, is a planning input that is hard to get any other way and does not require watching an individual.
• Out-of-hours movement alerts for vehicles and plant that should be stationary overnight. This is a straightforward theft and unauthorised-use control, and it is one of the few alerting uses where a same-minute notification genuinely matters.
• Restricted or hazardous area rules where entry needs to be logged, or where a vehicle class should not go.
• Triggering follow-on process such as a first-notification to a site contact, or closing out a scheduled visit automatically.

Where geofencing disappoints is as a general-purpose alerting mechanism. Fleets that build fifty fences with notifications on all of them generate a stream that gets muted within a week. The discipline is the same as any alarm design: a fence should either drive an automated process step or notify a human who will act immediately. Everything else should be a report, not an alert.

7. Fuel monitoring, and why theft detection is oversold

Fuel is usually near the top of a fleet's controllable cost, so fuel monitoring is a natural selling point and it does deliver value. It just delivers it somewhere other than where the pitch points.

What works well: fuel consumption analysis over time, per vehicle and per route. Where fuel level and distance are both available from the vehicle, consumption per vehicle becomes a trend, and a deteriorating trend on one vehicle against its own history is a maintenance signal worth chasing. Excessive idling, quantified rather than suspected, is a real and addressable cost. Comparing consumption across identical vehicles on similar duties finds the outlier that needs attention.

What is oversold: automated fuel theft detection. The pitch is a fuel-level drop while the vehicle is stationary, flagged as a siphoning event. In practice fuel-level sensing on many vehicles is coarse and non-linear, readings swing with tank slosh, gradient and temperature, and refuelling events, tank swaps and sensor faults generate the same signature as theft. The result on most fleets is a high false-positive rate on an accusation nobody wants to make wrongly. Reconciliation is the honest method: fuel card and bulk-tank transactions matched against vehicle-reported distance and hours, reviewed as a periodic exception report. That finds sustained discrepancies reliably. Chasing individual tank-level drops usually finds arguments.

8. Privacy, consent and data protection: take this seriously

Telematics collects continuous location data about a vehicle, and where an identifiable person drives that vehicle, it collects continuous location data about a person at work. Video goes further. This is not a footnote to the project, and it is not something to discover after installation.

I am a systems practitioner, not a lawyer, and nothing here is legal advice. What I can say plainly is this: the rules governing employee monitoring, location tracking and video recording in the workplace vary substantially between jurisdictions, and sometimes between sectors or between employment arrangements within the same jurisdiction. What is routine in one country may require specific notice, documented justification, workforce consultation, or a formal assessment in another, and personal-vehicle or take-home-vehicle arrangements frequently sit under different rules from pure commercial use. Cross-border operations may face more than one regime at once. You must have the specific rules for your locations, your vehicle arrangements and your workforce checked locally before deployment, by someone qualified to advise on them. Do not assume a vendor's default configuration, or the practice of a fleet in another country, tells you what applies to you.

Independent of the legal position, there are questions a well-run project answers in writing before the first device is fitted. They are good practice anywhere and they are what a workforce will ask:

• What exactly is collected, at what frequency, and is it collected outside working hours or when a take-home vehicle is in personal use?
• What is the stated purpose of each data type, and is the collection proportionate to that purpose? Collecting a stream because the device can produce it is not a purpose.
• Who can see it, at what level of detail, and is individual-level data restricted to those with a defined need?
• How long is it retained, and is video retained on a shorter clock than telemetry?
• Can a driver see their own data, and is there a route to contest an event or a score?
• What will it explicitly not be used for, and is that commitment written down rather than verbal?
• Is there a privacy or personal-use mode, and if so, who can enable it and is its use itself logged?

9. Integration to maintenance: the highest-value link, usually missing

Here is the gap that costs fleets the most. Telematics is procured by operations, for operational reasons, and configured by an operations administrator. Maintenance scheduling lives in a different system, owned by a different function, and is fed by meter readings that somebody currently types in, or that arrive on a service sheet from a workshop, or that are estimated. The two are rarely joined, because joining them was nobody's line item.

The connection worth building is narrow and unglamorous. A scheduled push of vehicle-reported odometer and engine hours into the asset record in your maintenance system, on a defined cadence, so that usage-based schedules fire on actual usage. Optionally, a selected subset of fault codes creating a work request against the correct asset. That is the whole scope. It does not require the platforms to share a user interface, it does not require real-time streaming, and it replaces a manual data-entry step that is chronically late and unreliable.

What it changes: services fall due when the vehicle has actually done the distance or the hours rather than when a calendar says so or when someone remembers to read the meter. Warranty and lifecycle decisions rest on a defensible usage figure. The vehicle history in the maintenance record reconciles with the dashboard. And the effort saved on chasing meter readings is real, recurring and immediately visible to the people doing it.

The practical mechanics: most credible platforms expose an API, so the integration is a scheduled job that reads current meters per vehicle and writes them against the matching asset. The hard part is almost never the API. It is asset identity. Your maintenance system knows the vehicle by a fleet number; the telematics platform knows it by a device serial, a registration, or a chassis number entered by whoever did the install. Establishing and maintaining a single reliable mapping key, and a process for keeping it correct when devices are swapped between vehicles, is the actual work. Get that wrong and you will write one vehicle's mileage onto another's record, which is worse than no integration at all.

For the wider mechanics of connecting this class of device data into a maintenance system of record, see IoT and fleet management integration and IoT integration with a CMMS. How the receiving system should then plan and execute the work belongs to fleet maintenance software and systems and CMMS for fleet and vehicle maintenance, and if the maintenance system itself is not yet settled, start with the CMMS buyer's introduction before you specify any feed into it.

10. Selecting a platform: what to actually test

Feature lists across the mainstream telematics market have converged, so comparing them line by line tells you very little. Category-level selection questions, the ones about whether you need a fleet platform at all and how it sits beside your other systems, belong to the fleet management software buyer's guide. What follows is specific to the tracking and telematics layer, and it is mostly about verifying that the data is good enough to build on.

• Vehicle coverage against your actual fleet list. Not "supports heavy vehicles" but a per-make, per-model, per-year statement of which parameters are available. Give the vendor your real fleet list and ask them to mark odometer and engine hours as available or not for each row.
• API access, documented and included. Confirm you can read meters and events programmatically, what the rate limits are, whether it costs extra, and whether an API user licence is required. A platform whose data you cannot get out on your own terms should be disqualified, because the maintenance integration is the point.
• Asset identity fields. Can you store your own fleet number and asset identifier against each device, and retrieve it through the API? If not, your mapping table becomes a spreadsheet, and spreadsheets drift.
• Data ownership and exit. Who owns the historical data, in what format can you extract all of it, and what happens to it at contract end. Ask this before signing, not at renewal.
• Device swap and decommission handling. What happens to the history when a unit moves to another vehicle. Fleets churn vehicles constantly and this is where records get corrupted.
• Threshold configurability per vehicle class for any behaviour scoring you intend to use.
• Coverage and reporting behaviour where your vehicles actually go, including areas with weak cellular coverage, and how the device buffers and back-fills when it reconnects.

11. The pilot: a data-quality test, not a demo

Run a pilot on a small mixed sample that includes at least one of each hardware type and vehicle class you intend to deploy, for long enough to see a full operating cycle, which usually means six to eight weeks rather than two. The purpose is not to confirm the map works. It is to establish whether the data you plan to build on is trustworthy. A checklist you can lift:

• Odometer reconciliation. Physically read the dashboard odometer on every pilot vehicle at the start and at the end. Compare with the platform's reported value. Record the discrepancy per vehicle. Any vehicle where this does not reconcile cannot carry a distance-based schedule.
• Engine hours reconciliation against the vehicle's own hour meter where one exists, on the same basis.
• Gap audit. Pick a week and account for every hour. How many reporting gaps, how long, and did the device back-fill after reconnecting or lose the data.
• Fault code review. Collect every code raised during the pilot and have a workshop technician mark each one actionable, known, or noise. That review is what defines your production alert set.
• Behaviour event sanity check. Take the twenty highest-severity events and review the context on each. If a meaningful share are defensible driving, your thresholds need calibrating before any score is published.
• API pull test. Actually write the script that reads meters for the pilot vehicles and lands them somewhere. Do not accept documentation as proof. This is also where you discover the identity-mapping problem early, which is the point.
• Battery and electrical check on hardwired installs, particularly on vehicles that stand idle for several days.
• Driver debrief. Ask the pilot drivers what they were told, what they believe the data is used for, and what concerns them. Their answers predict how the full rollout will go more accurately than any technical result.

A pilot that produces a table of reconciliation discrepancies, a gap count, a triaged fault-code list and a working API pull has earned its cost several times over, because it tells you exactly what you can and cannot build on. A pilot that produces a positive impression of the user interface has told you nothing you could not have got from a demo.

The idea to walk away with

One box on a vehicle produces three products, and the market sells you the least valuable one hardest. The live map is useful for dispatch and satisfying to watch, and it is not where the return is. Driver behaviour scoring is a coaching aid with contestable thresholds that can do real damage to trust if it is treated as an instrument or used punitively. The output that quietly pays for the whole programme is the automatic, vehicle-reported odometer and engine-hours feed, plus a curated set of fault codes, delivered into the system that plans your maintenance.

Which means the decision that determines whether this investment succeeds is made at scoping time, not at vendor selection. If the integration to maintenance is in the scope, with an owner, an identity-mapping design and a place in the pilot, the programme delivers. If it is on the wish list for phase two, it will still be on the wish list in three years, and the fleet will have paid for a map.

Final thoughts

If you have been told to put trackers on the vehicles, the useful reframing is to ask what decisions the data is meant to change. Dispatch decisions need position. Utilisation and site-time decisions need trips and geofences. Liability decisions need video, with the consent and retention questions answered properly first. Maintenance decisions, which is where the recurring money is, need meters and fault codes wired into the maintenance system of record. Write down which decisions you are buying for, and let that drive the hardware choice, the parameter list and the integration scope.

And handle the workforce dimension with the same seriousness as the technical one. Verify the rules that apply in your jurisdiction with qualified local advice, state the purpose of each data type, restrict access to those who need it, commit in writing to what the data will not be used for, and give drivers visibility of their own data and a route to contest an event. A deployment the workforce accepts produces clean data for years. One the workforce resents produces disputes, workarounds, and eventually a feed nobody trusts, and then none of the rest of this matters. For the positioning and satellite fundamentals underneath all of it, the public reference material from the United States government GPS programme is a better starting point than any vendor explainer, and for the standards landscape around vehicle data and road-transport telematics, ISO is the canonical source.

Related reading: Fleet management software: a buyer's guide, Fleet maintenance software and systems, CMMS for fleet and vehicle maintenance, Meter-based and usage-based PM in a CMMS, Preventive maintenance for fleets and trucks, IoT and fleet management integration, IoT integration with a CMMS, What is a CMMS: a complete buyer's introduction.