Fleet electrification creates a data integration problem that most fleet managers don't anticipate until they're deep into deployment planning. The telematics platform — whether that's a commercial product or a custom solution — has rich vehicle-level data: state of charge, planned routes, departure windows, driver assignments. The depot charging infrastructure has its own data domain: OCPP session state, power availability, charger hardware status, site-level load limits. These two systems almost never talk to each other natively. The result is charging that happens in whatever order vehicles plug in, not in the order the fleet actually needs.
This guide covers the integration architecture for connecting fleet management software to depot chargers. It's written for the integration engineers and fleet technology leads who are responsible for making the two systems coordinate — not just communicate, but actually enforce vehicle priority rules at the charger level.
The Core Data Problem: Two Systems, Two Timelines
Fleet management systems operate on a route-and-schedule timeline. The system knows that Vehicle 14 is dispatched at 06:30 tomorrow, needs 180 km of range, and is currently at 32% state of charge. That's the data the fleet manager cares about.
Depot charging systems operate on a session timeline. The OCPP gateway knows that Charger 7 at Bay C-4 is currently serving a session at 50 kW, that the session started at 22:14, and that the vehicle has accepted a charging profile capped at 48 kW per a load management rule. The charger doesn't know which vehicle is plugged in unless you tell it.
These timelines intersect at plug-in time, but without an integration layer, the intersection is silent — the fleet system logs a plug-in event, the charger starts a session, and no priority information flows between them. You get charging, but not optimized charging.
Integration Architecture Options
There are three broad approaches to connecting fleet management to depot chargers, each with different complexity and capability profiles.
Option 1: Schedule-Push via Charging Profiles
The simplest approach: the fleet management system (or an integration middleware layer) pushes OCPP charging profiles to chargers in advance of shifts, based on departure schedules. At shift start, the middleware calculates which vehicles need to be at what state of charge by what time, generates per-charger charging profiles using SetChargingProfile, and distributes them to the relevant charge points.
This works well when vehicle-to-bay assignments are deterministic — the same vehicle goes to the same bay every night. It breaks down when drivers plug into any available bay, because the charging profile was set for the vehicle the system expected at that bay, not the one that actually arrived.
Option 2: Session-Triggered Dynamic Profile Assignment
A more capable approach requires the integration layer to monitor OCPP StartTransaction events in real time. When a session starts on a charger, the integration layer queries the vehicle identity — either from OCPP's idTag field (if the driver authenticated with an RFID or app linked to a vehicle ID in the fleet system) or from a VIN-to-bay mapping the fleet system maintains. With vehicle identity confirmed, the integration layer looks up that vehicle's charging priority from the fleet system and issues a SetChargingProfile command that reflects its actual departure window and required energy.
Consider a concrete case: a regional logistics operator running 60 electric vans from a depot in the US Southeast. The depot has 40 Level 2 chargers (7.2 kW each) and 8 DC fast chargers (50 kW each). Peak overnight demand from simultaneous charging would exceed the site's 350 kW electrical service. Without coordination, the first 40 vehicles to plug in draw maximum power, the last 20 get nothing, and by 06:00 the early-departure vehicles may be under-charged. With session-triggered dynamic profile assignment, the integration layer knows that 12 vehicles have 05:30 departures and assigns them to fast chargers with high-priority profiles. The remaining 48 vehicles share L2 capacity proportionally based on their departure windows, ensuring all vehicles meet minimum state-of-charge requirements by departure time.
Option 3: Bidirectional API Integration
Full bidirectional integration means the fleet management system and the CPMS exchange data continuously in both directions: fleet → charger for priority rules and departure windows; charger → fleet for real-time session status, energy delivered, and estimated completion time. This allows the fleet system to update charging plans dynamically — if a driver's route changes and their departure window shifts, the charging profile updates automatically.
This requires both the fleet management platform and the CPMS to expose usable APIs. Major telematics platforms (Geotab, Samsara, and others) expose REST APIs for vehicle telemetry and assignment data. The CPMS side needs to both receive charging priority rules and push session telemetry back. If your CPMS doesn't support incoming priority rules via API — only via manual profile configuration in a UI — you're limited to Option 1.
OCPP Identity: The Link Between Fleet Vehicle and Charger Session
A critical and frequently underestimated piece of the integration is vehicle identity at session start. OCPP's idTag field is the mechanism the protocol provides for identifying who started a session. In a fleet context, this is typically a vehicle-assigned RFID tag, a driver card linked to a vehicle assignment, or (for OCPP 2.0.1 deployments) an ISO 15118 certificate provisioned to the vehicle.
If your chargers are configured to accept any idTag without validation (common in depot contexts where access control is handled physically), the session starts but carries no identity the integration layer can use to look up fleet priority. The fix is either to require authenticated sessions via OCPP's authorization flow or to use a physical bay-assignment mapping maintained by the integration layer. Both approaches have operational tradeoffs — authenticated sessions require driver discipline around card/app use, bay mapping requires consistent parking discipline.
We're not saying RFID card discipline is the only answer here. The alternative — bay-based vehicle mapping, where the fleet system knows vehicle assignments by planned bay — is simpler operationally but requires that drivers actually park where the system expects them to. For depots with structured parking assignments (common in bus and last-mile delivery fleets), this is workable. For unstructured depot environments, authentication at plug-in is the more reliable path.
Load Management at the Site Level
Depot charging integration isn't only about individual vehicle priority — it's also about staying within the site's contracted electrical capacity. Most depot sites have a demand charge structure where the peak 15-minute demand in a billing period drives a significant portion of the monthly electricity cost. Uncoordinated charging, where vehicles charge at maximum available rate the moment they plug in, tends to produce demand spikes that sit well above the load the site actually needs to manage.
The integration architecture needs to include a site-level power budget that the charging profile assignment logic respects. This is typically implemented as a maximum site power limit (e.g., 300 kW for a 350 kW service, with 50 kW headroom) that the CPMS enforces via composite charging profiles. As each new session starts, the profile assignment logic recalculates the available power budget and distributes it across active sessions according to priority rules. Sessions for high-priority vehicles (early departures, full route cycles) get more of the available power; sessions for vehicles that won't leave until late afternoon can charge slower.
What to Validate Before Go-Live
Before declaring a fleet charging integration production-ready, the scenarios that most often surface problems in testing are: simultaneous plug-in of multiple vehicles (does the priority logic execute fast enough to avoid all sessions defaulting to maximum power before profiles are applied?), VIN or idTag failures (what does the system do when a session starts without a recognized identity?), charger offline events during an active session (does the fleet system update its state-of-charge projection?), and mid-session priority recalculation (if a new high-priority vehicle plugs in and the power budget is tight, does the logic correctly reduce power to lower-priority sessions?)
The OCPP command response time for SetChargingProfile also matters more than many integrators expect. In a depot with 40+ chargers, simultaneous profile updates at plug-in time can create a burst of OCPP commands. If the CPMS or the charger firmware introduces latency in processing SetChargingProfile commands, there's a window where chargers run at their default maximum rate before the priority profile kicks in. For most L2 deployments, this is a minor issue. For DC fast charging, even a 60-second window at full power before the profile applies can represent a meaningful demand peak.
Fleet depot charging integration is one of the more technically demanding integration projects in the EV infrastructure space. The protocols exist; the telematics APIs exist. The challenge is in the middle layer that has to translate fleet priorities into OCPP commands in real time, handle the failure modes gracefully, and keep both systems' state in sync across a shift cycle that runs 24 hours a day, 7 days a week.