Definition
OCPP (Open Charge Point Protocol) is an open communication protocol for charging stations, enabling interconnection between charging stations and management platforms, supporting remote start/stop, billing, status reporting, and more.
Protocol Versions and Features
OCPP is maintained by OCA (Open Charge Alliance). The current mainstream versions are OCPP 1.6 and 2.0.1. The protocol is based on JSON or SOAP and uses WebSocket or HTTP for communication. Core functions include: charging station registration and heartbeat, charging session start and stop, real-time meter data reporting, remote configuration and diagnostics, reservation and authentication, firmware upgrades, etc. It supports interconnection among multiple charging stations and operators, avoiding proprietary protocol binding between the platform and the stations.
Role of communication modules
EV charging stations are mostly deployed in parking lots, highway service areas, and other locations where wired network coverage is limited, so 4G/LTE Cat.1 modules have become the mainstream connectivity solution. The module is responsible for establishing a TCP/WebSocket connection between the EV charging station and the OCPP platform to transmit OCPP messages. It is necessary to ensure stable long connections, reconnection after network outages, and offline caching to guarantee that charging session data is not lost. Some EV charging stations also report battery-related data such as SOC and SOH through the module, in coordination with BMS.
Application Value
Standardizing OCPP reduces the integration cost between platforms and EV charging stations, allowing operators to access multiple brands of EV charging stations; charging users can use a unified app to locate, start, stop, and pay; the platform can achieve centralized monitoring, operation, maintenance, and billing. With the popularization of new energy vehicles, the number of EV charging stations has surged, and OCPP together with cellular modules supports the large-scale operation of the charging network.
Engineering Practice Supplement
Integrate "OCPP" with the full lifecycle of modules: during the EVT phase, verify the reference design and antenna scheme; during the DVT phase, conduct conducted/radiated testing and thermal imaging; during the PVT phase, finalize calibration and test scripts. Before certification, check the target country's regulations and operator registration requirements to avoid missing frequency bands or SAR items. The production line retains golden sample comparison and spot check rules; after-sales can trace software versions, calibration parameters, and key component batches according to serial numbers. If the customer requires remote operation and maintenance, it is necessary to design security upgrades, rollback, and emergency shutdown strategies at the same time.
Charge-Session State and Metering Sample Points
OCPP treats the charger as an endpoint of the central system. The charger first registers with a boot message, then proves it is still online with heartbeats. A charge is a transaction with a start and an end. The transaction carries a connector id, an identity, meter readings, and a stop reason. In 1.6 the usual pattern is a long-lived connection with the charger as client and the platform as server. In 2.0.1 the device model is split into components and variables, so a remote configuration change is no longer a flat list of keys. The cellular module's job here is to keep that connection up and, when the air interface drops, to store transactions that have not yet been acknowledged. It does not calculate the energy charge in place of the charger.
The metering message is often under-read. If the platform receives only a start reading and an end reading, an outage in between cannot show whether charging really stopped or a sample was lost. Periodic meter values need a charger-side timestamp and a monotonically increasing transaction sequence. A jumped module clock, a wrong time zone, or no time sync can make the same kilowatt-hour appear twice in the daily close, or not at all. The practical conditions are: a protocol version the target platform actually supports, a security profile (cleartext WebSocket belongs on a lab network), and a stated rule for whether the charger may start from a local allow-list while offline.
What Keeps the Charger-to-Cloud Connection Up
Uplink at car parks and highway service areas is often unstable, and middleboxes reclaim WebSocket connections as a matter of course. If the heartbeat interval is shorter than the cellular idle reclaim time, the connection can stay up. If the platform's heartbeat timeout is shorter than the module's reconnect, the monitor marks the charger offline while the connector is still delivering energy. The offline cache has to separate "energy was delivered to the user and the platform does not know" from "the platform sent a remote stop and the charger never received it." Retransmitting the start and not the stop leaves the session hanging, and the next vehicle cannot start.
When a firmware upgrade and a charging session share one cellular link, the usual damage is an interrupted transaction, or a failed flash write that stops on a version which can no longer register. The upgrade should state whether it may run during a charge, and a failure must be able to return to the previous version and register again. Another common mistake is to mix battery telemetry and the billing meter reading in one field, so the platform settles in the wrong unit. For link jitter, connectivity diagnostics can show whether the handshake is slow or the session is reset mid-way. If charging control must take priority over log upload, the bearer has to separate those priorities; see QoS and service flows.
The charger also needs a rule for what the connector may do while the platform cannot see it. Energy started from a local allow-list must, once the link returns, be completed under the original transaction id with the start reading, the end reading, and the stop reason. Opening a new transaction counts that energy twice. A lost heartbeat and a lost meter-bus reading are not the same alarm: the first is the path from charger to platform, the second is the bus from charger to meter. One offline flag sends maintenance to the module while the meter has already stopped updating. The upgrade download should yield bandwidth to metering messages, and a failed flash write must still be able to register on the old version. If the clock steps backward, sample times inside the transaction should stay monotonic. The daily close should follow the settlement window the platform received, not a rewound charger clock that books one kilowatt-hour into two days. A sample whose time moved backward should be dropped or marked invalid, and must not enter the energy total.