Fleet charging optimization at the dispatch level — the kind that adjusts which vehicle charges at what rate in which minute based on current grid prices and each vehicle's state of charge — requires two real-time data streams to converge. One comes from the grid side: the current and upcoming tariff rate periods, demand charge exposure, and any real-time price signals. The other comes from the vehicle side: each vehicle's current SOC, estimated energy requirement to reach target SOC, and expected departure time.
Neither stream alone is sufficient. A system with perfect tariff data but no vehicle SOC telemetry can't calculate feasibility horizons and has to fall back on conservative fixed schedules. A system with perfect SOC data but stale tariff information may schedule charging during periods that are actually more expensive than the system believes. The optimization problem is only as tractable as the joint quality of both inputs.
This article covers the engineering architecture for integrating these two streams — the data formats, the API conventions, the latency requirements, and the failure modes that matter in production.
The Tariff Data Layer
On the grid side, the primary data requirement is the tariff rate calendar for the current billing period: a structured representation of which rate period (on-peak, off-peak, partial-peak, etc.) applies at each hour of each day, along with the corresponding energy charge ($/kWh) and the demand charge structure.
Tariff rate calendars have low intrinsic update frequency — a TOU schedule for a given billing month is defined by the utility's filed tariff and doesn't change within the month except for CPP event overlays. This means the primary tariff data pipeline can operate on a daily polling cadence rather than requiring sub-minute refresh. The data format at the consumer end is typically a time-indexed array of rate period identifiers, resolved against a rate schedule lookup table.
A minimal tariff data structure for a single billing period looks something like this:
{
"utility": "pge",
"account": "XXXX-XXXXX",
"schedule": "schedule_32",
"season": "non_summer",
"billing_period": {
"start": "2026-01-01",
"end": "2026-01-31"
},
"rate_periods": [
{
"period_id": "on_peak",
"energy_charge_kwh": 0.0872,
"demand_charge_kw": 14.20
},
{
"period_id": "off_peak",
"energy_charge_kwh": 0.0421,
"demand_charge_kw": 0.0
}
],
"calendar": [
{
"date": "2026-01-05",
"day_type": "weekday",
"intervals": [
{"hour": 0, "period": "off_peak"},
...
{"hour": 7, "period": "on_peak"},
...
{"hour": 22, "period": "off_peak"}
]
}
]
}The rate values in this structure should come from validated sources — the utility's filed tariff or a curated tariff database — and not from API responses alone. As discussed in our article on utility tariff feed integration, automated API sources for commercial rate schedule data are limited and require validation against PUC tariff filings.
The CPP overlay is a distinct layer. When a utility dispatches a CPP event, a notification arrives through a separate channel (email, utility API push, SEPA-based signal), and the scheduling system must inject a temporary rate override for the affected hours. This requires the tariff data layer to support runtime rate period overrides with explicit start time, end time, and rate values — not a static monthly calendar.
The Telematics Layer
Vehicle telematics provides the scheduling system's view of the fleet: which vehicles are at depot (vs. in service), their current SOC, their connection status to a charger, and their scheduled departure time.
Fleet telematics systems — products like Samsara, Geotab, Motive, or OEM-provided telematics platforms — expose vehicle data through REST or WebSocket APIs. The data model varies by platform but generally includes a vehicle endpoint that returns current SOC, odometer, location, and ignition/connection state on polling or push intervals ranging from 1 to 5 minutes.
For charge scheduling purposes, the key latency requirement is the SOC refresh rate. The feasibility horizon calculation described in our piece on load shifting and morning dispatch depends on current SOC. A 5-minute stale SOC is generally acceptable — the scheduling algorithm should add a buffer to its feasibility calculations that accounts for the maximum SOC change within the telematics polling interval. A 30-minute stale SOC in a dynamic overnight charging scenario can produce materially incorrect priority decisions.
The other critical telematics input is plug state. Most telematics systems report vehicle connection to a charger through OBD-II or CAN bus signals, but the reliability of this signal varies by vehicle make and model. An alternative or supplementary source is EVSE-side session data via OCPP: when a vehicle connects to a charger, the OCPP StartTransaction message provides a plug-in timestamp and initial meter value. Using OCPP session events as the primary plug-state signal, with telematics as a cross-check, is more reliable than relying on telematics alone for connection detection.
OCPP as the Control Layer
Once the tariff and telematics data are combined into a scheduling decision, the command layer is OCPP (Open Charge Point Protocol). OCPP 1.6 and OCPP 2.0 are the two versions in active deployment across commercial fleet chargers.
OCPP 1.6 supports smart charging through the SetChargingProfile command, which allows a central management system (CSMS) to set a charging schedule for a specific connector. The schedule specifies a power limit (in watts or amperes) over a time window, with up to two active profiles per connector at different priority levels. The EVSE hardware is responsible for enforcing the limits, subject to its own BMS constraints and safety interlocks.
OCPP 2.0 (and its maintenance release 2.0.1) expands smart charging capabilities significantly: it supports absolute and relative charging schedules, multiple concurrent profiles at different stack levels, bidirectional power control for V2G-capable hardware, and more detailed status reporting. For new EVSE deployments, OCPP 2.0 is the preferred target. The challenge is that OCPP 1.6 remains widespread in deployed hardware, and a CSMS managing a fleet with mixed OCPP versions needs to maintain separate command paths for each version.
A practical note on OCPP implementation quality: the OCPP specification defines a protocol, but hardware manufacturers implement it with varying degrees of fidelity. A common issue is partial support for SetChargingProfile — the charger acknowledges the command but doesn't enforce the power limit correctly at all current levels, or silently reverts to its default behavior after a firmware update. Testing smart charging profile enforcement on specific hardware models before full deployment is not optional; it is a required integration step.
The Integration Loop
With these three layers defined — tariff data, telematics, and OCPP control — the integration loop runs as follows:
- Tariff state update (daily + on CPP event): Load the current rate period calendar for each depot's utility account. Flag if tariff data is stale or if a CPP event has been dispatched.
- Vehicle state polling (every 2–5 minutes): For each vehicle at depot, update SOC, plug state, and estimated departure time from route schedule.
- Feasibility horizon calculation (per SOC update): For each plugged-in vehicle, calculate the latest charge start time that satisfies target SOC at departure, given current SOC and charge rate.
- Dispatch decision (per scheduling cycle, e.g., every 15 minutes): Given current tariff period, facility demand headroom, and per-vehicle feasibility horizons, determine which vehicles should be charging at what rate in the next interval.
- OCPP command dispatch: Send
SetChargingProfilecommands to active sessions where power level needs to change. For sessions that should not yet start, useReserveNowor keep the connector unavailable through profile management. - Demand monitoring (continuous from EVSE metering): Track aggregate facility demand against the monthly running peak. Alert if approaching a new demand peak that would exceed the current monthly high.
Failure Modes and Resilience
The failure modes that matter in production are mostly about data unavailability rather than incorrect data. Telematics APIs go offline. EVSE hardware drops its OCPP connection during firmware updates. Tariff data validation fails because a rate change wasn't propagated.
The scheduling system's behavior under degraded inputs should be defined explicitly. The conservative fallback in most cases: when telematics SOC is unavailable, assume vehicles have low SOC and prioritize charging (favoring operational readiness over cost optimization). When OCPP connectivity is lost, log the failure and alert; the charger will continue at its default rate, which may not be cost-optimal but is operationally acceptable. When tariff data is stale beyond a defined threshold, alert and optionally fall back to a conservative schedule that avoids peak-period charging even if the exact peak window can't be confirmed.
We're not saying the optimization should halt when any input degrades — a fleet can't stop charging because a telematics API went down. What should happen is that the system degrades gracefully, prioritizes operational safety, and makes the degradation visible to the fleet manager so it can be resolved promptly.
Integration Development Realities
Building this integration for the first depot is the hardest. The OCPP library, the telematics API client, the tariff data pipeline, and the scheduling engine all need to be functional and tested before the first vehicle plugs in. The integration work for a second depot in the same utility territory with the same EVSE hardware and telematics platform is significantly faster — most of the components are reused, with new configuration for the tariff account and EVSE endpoint addresses.
Heterogeneous environments — different EVSE hardware at different depots, multiple telematics platforms across fleet vehicle types, different utilities — multiply the integration surface area. Standardizing on a single EVSE hardware vendor and a single telematics platform is the simplest path if procurement decisions are still open. For existing fleets with mixed hardware and telematics, the integration layer needs to abstract these differences behind a uniform internal data model — a vehicle state object and a charger control interface that the scheduling engine consumes without needing to know whether it's talking to OCPP 1.6 or 2.0, or whether the SOC came from Samsara or Geotab.
That abstraction layer is not glamorous engineering, but it is where the operational reliability of the system lives.