Telematics for electric vehicles: which data your fleet actually needs

Telematics collects vehicle data and transfers it to a connected system for further use. In an electric fleet, this can make mileage, state of charge and information about assignments available, for example. Which values your fleet actually receives depends on the vehicle, technical connection, permissions and agreed data scope.

Start with an operational question: which decision should vehicle data make more reliable? Only then define which information is required and how frequently. This article helps you describe your data requirements and test an integration in daily operations.

Assign a concrete task to each data field

A regular mileage reading can support maintenance planning. A timely state-of-charge value may be needed to release a vehicle for an upcoming assignment. A complete location history is not automatically necessary for either task.

The government telematics guide for fleets describes mileage, state of charge and energy information among the possible data elements. This overview supports possible use cases; it does not mean that every vehicle and every integration supplies every field.

Create a requirements list with four columns: decision, data field, required freshness and responsible role. Define freshness from the workflow. A value used for month-end close has different requirements from a status checked immediately before departure.

Check the data journey from vehicle to display

Document where the value originates and which systems pass it on. For every required field, ask about its unit, meaning and data timestamp. A field called “battery” can be misleading without an additional definition.

Distinguish between the time of capture in the vehicle, receipt by the data connection and display in your fleet software. After an interruption, an older message may arrive later. Its new receipt time does not make the original measurement current.

Also record what happens when the vehicle is switched off or parked for an extended period. Are further values transmitted? Are there identifiable data gaps? What feedback does your team receive when the connection is disrupted? The answers belong in the description of your fleet software integrations.

Explicitly agree how to handle data gaps and fallback processes

Operational decisions require a rule for handling missing values. An unreported mileage reading does not mean the vehicle was stationary. An old state-of-charge value does not confirm the current energy reserve.

At a minimum, mark data as available, outdated or missing. Add a specialist review when values are implausible. Set the threshold for “outdated” to suit the intended use. A single time limit for every data field is rarely easy to justify.

Also define a fallback process. This might be a confirmed report from the vehicle, saved with its time and source. Manual entries must remain identifiable. Once automatic data starts arriving again, check for possible overlaps and contradictions.

Example: a limited test with twelve vehicles

Illustrative test scenario: A fleet wants to see state of charge and mileage for twelve electric vehicles before morning dispatch. The test covers five typical operating days and one day with a longer period parked. The timeframe and sample are illustrative choices, not a general recommendation.

On the third day, ten vehicles supply the intended values. Two vehicles have no current reports. The result is therefore not “integration successful”, but ten fully checked data paths and two outstanding cases with documented conditions.

The team investigates whether the gap is caused by vehicle access, an interruption or processing. The agreed fallback process is tested for both vehicles. Only once the result and remaining limitations are known is a decision made about use in normal operations.

Use an acceptance checklist with real operating situations

Test a normal working day, a longer period parked, a missed message and an organisational vehicle change. Check both the display and the later analysis.

The following list can serve as a test record:

• Required fields are available for the exact vehicle specification.

• Units, meanings and capture times are documented.

• Missing and old values are visibly marked.

• A manual fallback report has an identifiable source.

• Access rights match the agreed tasks.

• Exported data retains the vehicle ID and time reference.

• Responsibility and contact routes for disruptions are established.

Before ongoing use, also clarify the purposes, access and retention of personal data with the responsible teams. The article on data privacy in fleet software helps prepare these questions.

You can discuss your fleet requirements with StromNow to explore how vehicle data and charging organisation should work together. Describe the intended decision and your existing data sources. Whether a specific telematics integration is supported belongs in this concrete review.