When the Fleet Is Also the Battery
Fleet electrification procurement decisions routinely frame battery degradation as a vehicle-level concern: when will vehicle X need a battery replacement, and what does that do to total cost of ownership? That's a reasonable first-order question. But for operators running medium and heavy-duty EV fleets at a shared depot — where 30–150 vehicles are parked overnight in a coordinated charging window — there's a second, higher-level question that's being underexplored: what does this depot look like as a distributed energy asset?
A 60-vehicle depot with 100 kWh usable batteries per vehicle is 6 MWh of mobile storage connected to the grid for 8–12 hours every night. That's a BESS asset — a distributed one with unusual characteristics, but a BESS asset nonetheless. Fleet operators who are signing demand response agreements or vehicle-to-grid (V2G) contracts with their utilities need battery health data at a different granularity than what a standard fleet telematics system provides. SoH at the vehicle level is necessary but not sufficient; you need SoH distribution across the fleet, aging trajectory projections by vehicle age and usage cohort, and a protocol-level data pipeline that can feed a depot energy management system in real time.
The OCPP Data Layer and Its Limitations for Health Analytics
Open Charge Point Protocol (OCPP) — currently OCPP 2.0.1 is the active version, with OCPP 1.6 still widely deployed — defines the communication interface between charging station (EVSE) and a central management system (CSMS). OCPP covers session management, tariff control, smart charging power limits, firmware update, and diagnostics. It's the right layer for coordinating when and how fast each vehicle charges. It's not designed as a battery health analytics data source.
The data OCPP exposes at the charger level is session-centric: start time, stop time, energy delivered (kWh), meter values at defined intervals (voltage, current, SoC at start and end). This is enough to run smart charging schedules. It's not enough to compute ICA-based SoH trajectories, identify anomalous cell behavior, or build a per-vehicle aging model. For that, you need data from the vehicle's BMS — which flows through the vehicle's own communication path, typically CAN bus accessible via the OBD-II port or the EVSE's ISO 15118 Plug and Charge communication stack.
ISO 15118 — the vehicle-to-grid communication protocol for AC and DC charging — includes provisions for health state data exchange in its -2 and -20 editions, but manufacturer implementations vary significantly. Some OEMs expose SoH via the charging session protocol. Many don't, or expose it at low resolution (integer %) insufficient for trend analysis. Fleet operators who assumed that OCPP + ISO 15118 would give them full battery health visibility have frequently discovered a data gap at this layer.
Calendar Aging in Idle Fleet Vehicles: The Problem That Doesn't Show Up in Cycle Count
EV fleet battery degradation analysis typically anchors on miles driven and equivalent full cycles. These are the metrics OEM warranty agreements are structured around. But depot-operated fleets have a charging pattern that creates disproportionate calendar aging exposure relative to cycle count:
Consider a 40-vehicle urban delivery fleet with typical routes of 80–120 km per day. Average DoD per duty cycle is roughly 40–55%. Vehicles return to depot at 45–60% SoC and charge to 90–95% SoC overnight for the next day's dispatch. After charging completes — often by 2:00–4:00 AM for a 22 kW AC charging setup — vehicles sit at high SoC (90–95%) until departure at 7:00–8:00 AM. That's 3–6 hours of calendar aging at high SoC, every day, for every vehicle.
The Arrhenius relationship means this isn't a minor issue. NMC cells at 95% SoC experience elevated cathode oxidative stress — the high lithium chemical potential drives side reactions at the cathode surface. At 25°C, these reactions are slow. In a depot in a warm climate, with ambient temperatures of 28–35°C overnight, they're materially faster. The cycle count over a year for this fleet might be 220–250 EFCs per vehicle. The calendar aging exposure — calculated from the daily high-SoC dwell hours × Arrhenius-corrected rate — can contribute degradation equivalent to an additional 40–80 EFCs beyond what the OEM warranty model accounts for.
Fleet operators running vehicles in warm-climate depots with overnight top-of-charge parking are accumulating warranty exposure that cycle count tracking alone won't detect — and OEM warranty claims that appear premature by cycle count may be entirely justified by calendar aging attribution.
Warranty Disputes with OEMs: The Data You Need
EV fleet battery warranty disputes are different from stationary BESS warranty disputes in one important respect: there are more parties. The vehicle OEM holds the battery warranty. The charging infrastructure operator may hold service agreements. The fleet operator is caught between them when a vehicle shows premature capacity fade.
The OEM's default position is to inspect the vehicle's BMS logs and determine whether operating conditions fall within warranty parameters: temperature range, charge current limits, maximum SoC, minimum SoC. If all parameters fall within spec, the warranty proceeds normally. The problem is that OEM BMS logs are usually coarse — they may flag exceedances of hard limits but don't provide the continuous temperature and SoC dwell-time history needed to demonstrate cumulative calendar aging exposure.
An independent fleet battery health monitoring system that logs — per vehicle, per day — the temperature-weighted high-SoC dwell time and computes the Arrhenius-integrated aging exposure provides the factual record needed to support a warranty claim based on calendar aging rather than cycling. Without that record, the dispute defaults to cycle count, and the fleet operator is arguing without data against an OEM that has the BMS logs.
A practical scenario: a 50-vehicle NMC-battery fleet, operating in a southeastern depot, hits the warranty trigger (80% capacity on 15 vehicles) at 28 months into a 60-month warranty. OEM cycle count logs show 210 EFCs — within spec for 28 months. But independent SoH monitoring logged an average of 4.8 hours/day at SoC >88% in an ambient of 31°C. The Arrhenius-corrected calendar aging model attributes approximately 35% of the observed capacity loss to thermal calendar aging beyond the reference condition. That attribution changes the warranty conversation from "you're within cycle spec" to "your reference condition is materially different from our operating environment, and here is the continuous measurement record that quantifies it."
Multi-Chemistry Complexity at Mixed-Fleet Depots
Growing numbers of fleet operators are running mixed-chemistry fleets — LFP-chemistry vehicles from one procurement cohort alongside NMC vehicles from another, sometimes with different manufacturers and different model years sharing the same depot infrastructure. This creates monitoring complexity because the health indicators, the acceptable operating windows, and the aging behavior are different across chemistries.
LFP vehicles are more temperature-tolerant at high SoC (less cathode oxidative stress than NMC at top-of-charge), but they're more susceptible to lithium plating at low temperatures and high charge rates — particularly relevant for depot fast-charging scenarios in winter. LFP SoH determination is also harder: the flat OCV-SoC curve means that a pure OCV-based SoH test has poor resolution in the middle SoC range. Reliable LFP SoH requires either a full capacity test or a dV/dQ analysis on controlled charge/discharge data.
A single monitoring framework that treats all vehicles as equivalent regardless of chemistry will produce systematically biased health scores for one cohort or the other. The monitoring layer needs to know which vehicle is which chemistry and apply the appropriate cell model for state estimation and aging projection.
Integrating Fleet Health Data into Depot EMS
The full value proposition of fleet battery health monitoring isn't just warranty protection and OEM dispute data — it's operational dispatch optimization at the depot level. A depot energy management system (EMS) that incorporates per-vehicle SoH data can make smarter decisions about which vehicles to prioritize for V2G discharge events, which vehicles to restrict from deep DoD overnight (protecting vehicles with elevated aging indicators), and how to sequence charging to minimize demand charges while respecting the health state of the fleet.
This requires the health monitoring system to expose SoH and aging trajectory data via an API that the depot EMS can query. OCPP 2.0.1 includes smart charging profiles that can be driven by external input — a CSMS receiving SoH flags from a health monitoring system can modify charging schedules accordingly. The integration architecture is feasible today; the gap is usually in the health monitoring system having sufficient SoH resolution to generate meaningful dispatch-relevant signals, rather than a binary "healthy/degraded" flag.
What We're Not Saying
We're not saying that every EV fleet operator needs a purpose-built battery health analytics platform from day one. For small fleets of 10–15 vehicles, OEM telematics and standard CSMS monitoring covers most operational needs. The economics of a dedicated SoH monitoring layer become compelling when the fleet exceeds 30–40 vehicles, when warranty durations extend beyond 3 years on NMC chemistry in warm climates, and when the operator is entering V2G or demand response agreements where battery health directly affects the reliability commitment.
We're also not saying that OCPP is a bad protocol or that it should be replaced for fleet analytics. OCPP does its job well. The point is that OCPP is a charging management protocol, not a battery health protocol, and fleet operators who expect health analytics from their CSMS alone will be disappointed. Battery health data flows from the BMS upward, and getting it into an analytics layer requires either OEM cooperation through the vehicle data channel or direct BMS data access where available. Both paths are technically achievable; both require deliberate engineering rather than passive data collection.