When you are evaluating charger hardware for a new depot, the salespeople will tell you the charger is "OCPP-compliant." That phrase comes up a lot. It sounds like a checkbox, not a detail worth digging into. In practice, the OCPP version, the specific feature set implemented, and how a charger vendor interprets "compliant" can make a significant difference in whether your fleet management software can actually control your chargers the way you need it to.
This is a primer on what OCPP is, what it does, and the questions you should ask before committing to charger hardware for a multi-vehicle depot deployment.
What OCPP is and what problem it solves
OCPP stands for Open Charge Point Protocol. It is a communication standard developed and maintained by the Open Charge Alliance (OCA) that defines how a charging station (called a Charge Point in the protocol) communicates with a Charge Point Management System (CPMS) or central management software.
Before OCPP became widespread, every charger manufacturer had a proprietary API. If you bought chargers from manufacturer A and later wanted to use fleet management software from vendor B, you were stuck: the software could not talk to the hardware without custom integration work, which was expensive and fragile. OCPP was designed to break that lock-in by providing a standard protocol that any software could implement and any charger could speak.
In practical terms, OCPP lets software tell a charger when to start a charging session, when to stop, at what power level to operate, and how to report back energy consumption and fault states. That bidirectional communication is what makes remote scheduling, smart charging, and load management possible.
OCPP 1.6 versus OCPP 2.0.1: what the version difference means
The two versions you will encounter in the market today are OCPP 1.6 and OCPP 2.0.1. Most chargers installed over the past several years run OCPP 1.6. OCPP 2.0.1 is the current specification with expanded capability, particularly around security, smart charging profiles, and ISO 15118 Plug & Charge vehicle communication.
For fleet management and depot charging optimization, the most relevant capability difference is in smart charging. OCPP 1.6 includes a Smart Charging feature profile that allows a management system to set a charging profile on a specific connector, defining a schedule of maximum power values over time. This is the core of what you need for demand peak management: the software sends a charging profile to charger 4, telling it to limit to 4 kW from 5:00 PM to 8:00 PM and then run at full rate after 9:00 PM.
OCPP 2.0.1 expands on this with more granular power control, better support for absolute versus relative power limits, device management improvements, and enhanced security. For a depot that wants to grow its smart charging capability over time, OCPP 2.0.1 hardware will be more future-proof. For depots deploying today and focusing on the OCPP 1.6 Smart Charging feature set, the version gap matters less in the short term.
The catch: a charger can claim OCPP 1.6 compliance while implementing only a subset of the feature profiles. OCPP 1.6 defines several profiles including Core, Firmware Management, Local Auth List, Reservation, Smart Charging, and Remote Trigger. "OCPP 1.6 compliant" does not automatically mean Smart Charging is implemented. Always confirm specifically that the Smart Charging profile is supported, including the SetChargingProfile message and both ChargingProfileKind "Absolute" and "Relative" scheduling.
The questions to ask charger vendors before you buy
When evaluating charger hardware for a fleet depot, these are the specific OCPP questions worth asking:
Which OCPP version is supported, and is it configurable to both 1.6 and 2.0.1 via firmware update? Some newer chargers ship supporting both and can be configured depending on the CPMS you connect to.
Is the Smart Charging feature profile fully implemented? Can you demonstrate SetChargingProfile working with an Absolute schedule? Can power limits be set at both the charger level and the individual connector level?
How does the charger handle a CPMS connection loss? If your network goes down for 30 minutes, does the charger continue following the last received charging profile, fall back to unrestricted charging, or stop entirely? For an overnight fleet, the answer matters: an uncontrolled fallback to maximum power during a CPMS outage could spike your demand charge unexpectedly.
Does the charger support OCPP authorization (StartTransaction with IdTag) or can it be configured for free-vend mode? For private depot charging where vehicles are pre-assigned, you typically want free-vend or a simple vehicle-ID authorization rather than requiring RFID cards at every plug-in.
What is the meter data reporting interval, and can it be configured? For accurate real-time SOC estimation and demand monitoring, meter value messages at 1-minute or 5-minute intervals are more useful than the default 15-minute interval some chargers ship with.
Where OCPP compliance gaps show up in practice
We have worked through OCPP integration with charger hardware across multiple vendor implementations. The common friction points are not usually in the basic Core profile, which covers start/stop session and energy metering. They tend to appear in the Smart Charging profile behavior.
One issue we have seen: a charger that implements SetChargingProfile correctly but does not respect TxDefaultChargingProfile settings for sessions initiated locally (by plugging in) rather than remotely (by a RemoteStartTransaction message from the CPMS). The charger applies the smart charging limit when the session was started by software but ignores it when the driver plugs in directly. That asymmetry breaks demand management in exactly the scenario it matters most: when a driver returns and plugs in without a dispatcher initiating the session.
Another gap: chargers that accept a ChargingProfile with a stack level override but do not reliably clear the profile when a new one is sent with conflicting parameters. Sessions end up following an old schedule rather than the updated one, which produces unexpected charging behavior without clear error signals.
These are not disqualifying issues for most charger brands, but they require testing and in some cases firmware updates from the vendor. Building a test day into your depot charger procurement process, where you verify smart charging behavior before finalizing the order, is time well spent if you are deploying 10 or more chargers at a single site.
What OCPP integration means for scheduling software
From the scheduling software side, OCPP is the mechanism by which the charging schedule becomes real. When Fleetvolts computes an optimal charging sequence for the night, it converts that sequence into a series of OCPP ChargingProfile messages sent to each charger. Charger 3 gets a profile saying: hold at 0 kW until 8:30 PM, then charge at 7.2 kW until full. Charger 7 gets a profile saying: start at 6.6 kW now, drop to 3.3 kW at 6:00 PM when facility load peaks, then resume full rate at 9:00 PM.
The schedule is only as good as the protocol implementation beneath it. If a charger does not reliably respect the profile, or if it drops its CPMS connection intermittently and falls back to uncontrolled charging, the scheduling computation becomes disconnected from physical reality. OCPP reliability is not glamorous, but it is the layer that determines whether your cost optimization runs on paper or actually shows up on the electricity bill.