In E-Mobility Fleets, Analytics Starts With Usable Data
Electric fleets are now a meaningful share of urban transit electrification plans, with maritime electrification advancing in parallel. Lower operating costs, reduced emissions, and improved rider or operator experience all support the case. The economic equation, however, depends on something less visible than the vehicle or vessel itself: the battery, and the data it produces over the asset’s working life.
That data has a long path to travel before it can be analyzed. It leaves the asset over the air, lands at a telematics provider, and then moves into an operator’s fleet management or analytics environment. Each hop introduces variability in what arrives, how complete it is, and how often.
Layered on top of that physical trajectory is a commercial one. Some OEMs share full battery data with their customers. Some share partial data. And some share none at all. Two operators running the same vehicle from the same manufacturer can sit under very different data agreements, and the analytics that are possible for one may not be possible for the other.
The result is that any battery analytics program serving an e-mobility fleet has to start with data and not the algorithm first. Output quality is bounded by input quality, and input quality in fleets is bounded by what the OEM, the telematics layer, and the data agreement allow.
1. The Three Paths to Battery Data in an E-Mobility Fleet
Battery data can reach an analytics environment along three common paths. Each trades completeness, latency, and operator control differently. The descriptions below are framed in road-transit terms, where the standards are most mature; maritime and rail e-mobility operate under their own protocol families.
Path 1: OEM-Embedded Telematics
The vehicle manufacturer collects sensor data, including battery data, to a central manufacturer portal. The operator retrieves what is exposed through an API or similar interface. The OEM’s data agreement determines scope and access.
Path 2: Third-Party Telematics
An aftermarket telematics module taps the vehicle’s interfaces (typically the Controller Area Network bus on road vehicles) and routes data to a sorting backend that makes it available to the operator. Signal coverage depends on what the asset exposes on its interfaces and how the module is configured.
Path 3: Direct Retrieval Through a Fleet-Side On-Board Unit
The fleet operator’s own on-board unit, integrated with its Intermodal Transport Control System (ITCS) or equivalent platform, pulls battery data directly from the vehicle interfaces and forwards it to the operator’s server. The operator controls the data path end to end, at the cost of carrying more of the integration work themselves.
Across all three paths, prefer open standards over proprietary integrations. They keep the analytics ecosystem competitive and reduce the cost of switching. In road transit, the Telediagnostic for Intelligent Garage in Real-time (TiGR) protocol, supported by the ITxPT association, is one such standard. Operators specifying new procurements can reasonably ask OEMs to support whichever framework applies to their domain.
2. Specifying What Data the Analytics Actually Need
Underspecified data requirements drive back-and-forth with the OEM or telematics provider that can stretch over months, and incomplete payloads quietly degrade analytics output. The load-bearing parameters for battery analytics are:
Pack-level current (I), voltage (U), and temperature (T), including minimum and maximum pack temperature, time-synchronized at a granularity appropriate to the discharge and charge profiles of the duty cycle. The min/max temperature readings expose thermal dispersion and the early signatures of cooling or sensor issues.
Cell-level minimum and maximum voltages, which expose dispersion across the pack and allow detection of imbalance-related anomalies that pack-level voltage hides.
State-of-Charge (SoC) as reported by the Battery Management System (BMS), with timestamps of any BMS recalibrations where available.
With these parameters, advanced analytics can detect early-stage deviations such as cell imbalance while the condition remains potentially reversible. Without them, the analytics layer is reduced to confirming what the BMS already shows on the dashboard.
3. Data Cleansing and Processing: From Raw Telemetry to a Usable Dataset
Even when the feed is complete and the parameters are correct, the data is not yet ready for analysis. Three challenges sit between raw telemetry and insight: volume (a large time series from each asset, multiplied across the fleet), BMS measurement reliability (sensor errors that algorithms must not mistake for battery issues), and communication gaps (dropped packets, out-of-coverage assets, telematics provider outages).