OCPP charger control

What OCPP standardises between a chargepoint and its management system, and what buyers must check beyond an OCPP label.

OCPP (Open Charge Point Protocol) defines messages between a charging station and a charging-station management system. That back-end can authorise users, record sessions, monitor faults, set charging limits and issue remote commands.

OCPP addresses this charger-to-management-system link. It is not the vehicle-to-charger protocol, an electrical safety standard or a guarantee that a particular tariff will control the unit.

What an OCPP connection can carry

Depending on the version and implemented functions, a charging station can report:

whether it is available, charging or faulted
user authorisation and transaction events
meter values and session energy
connector and device status
diagnostic and security events
firmware-update progress

The management system can send commands such as starting or stopping a session, changing configuration and applying charging profiles. These are defined messages, which is what allows equipment and back-ends from different suppliers to be integrated without inventing a new private protocol for every pairing.

That does not mean every implementation supports every optional function. A charger may handle core transactions but omit smart-charging, advanced security or ISO 15118-related profiles.

Versions matter

As at 22 July 2026, the Open Charge Alliance publishes OCPP 1.6, OCPP 2.0.1 and OCPP 2.1.

OCPP 1.6 remains an established implementation and includes core charging operations plus optional smart-charging and security capabilities. A claim of 1.6 support should say whether JSON over WebSocket is supported and which certification profiles or security whitepaper functions are implemented.

OCPP 2.0.1 introduced a fuller device model, improved transactions, security, smart charging and support for ISO 15118 use cases. It is not protocol-compatible with OCPP 1.6. Its third edition was approved as IEC 63584 in 2024.

OCPP 2.1 builds on 2.0.1 and adds functions for ISO 15118-20 bidirectional charging, distributed-energy-resource control and further transaction and payment use cases. Those messages enable integration; they do not make the vehicle or charger power stage bidirectional.

OCA issues editions and errata within these named versions. An implementation is identified by its exact version, edition, profiles and security configuration; “OCPP compatible” does not supply that information.

Certification is more specific than a logo

The Open Charge Alliance operates independent certification for defined OCPP implementations. Certificates apply to the tested product and software version and can include mandatory and optional profiles.

For example, smart charging is an optional charging-station profile in OCPP 1.6 certification, while OCPP 2.0.1 certification has a mandatory core profile and optional profiles. A certificate therefore needs to be read for its product version and scope.

Vendor self-declaration can still describe a working implementation, but it carries less interoperability evidence than a matching certificate. In either case, test the charger against the intended back-end before a large deployment.

Open protocol does not always mean an open charger

A charger can implement OCPP yet still be difficult to move between management providers. Migration may depend on:

installer or manufacturer access to the OCPP settings
permission to change the back-end address
charger-side credentials and client certificates
ownership of the SIM or data connection
a vendor proxy or gateway remaining in the path
licence or service terms
release of transaction data and administrator accounts

Endpoint and credential control determine whether the owner can appoint another management provider if the original supplier stops its service. OCPP capability without configuration access may offer little practical independence.

Local control and loss of communications

OCPP commonly operates over an IP network, so the management system may be local or remote. A home energy controller can use OCPP for solar charging or site limits only if the charger exposes the required functions and accepts that controller as its back-end.

Network-loss behaviour includes:

continued charging for an already authorised user
a safe local current limit
local transaction buffering and later upload
any local override of a remote schedule
whether load protection uses OCPP or a separate local controller
recovery after certificates or credentials expire

The Great Britain smart-charge-point regulations require continued charging capability when communications are unavailable for products within scope. They do not require manufacturers to use OCPP, and OCPP support alone does not prove compliance with the rest of those regulations.

OCPP, ISO 15118 and Modbus

These protocols serve different links:

OCPP connects the charging station to its management system
ISO 15118 connects the vehicle and charging equipment for supported high-level functions
Modbus is often used locally between meters, inverters, batteries and energy controllers

A home energy system may use all three. Support for one says nothing automatic about the others. Even where a charger exposes OCPP smart charging, fast local supply protection may be handled by a direct meter or CT link rather than by cloud messages.

Implementation record

exact OCPP version, edition and transport
charging-station and back-end interoperability evidence
certified profiles and software version, where certified
smart-charging, security and firmware functions actually enabled
owner access to endpoint, credentials and certificates
local behaviour during internet and back-end failure
data export and account transfer at handover
support period and process for security updates
the tested tariff or aggregator integration, where applicable