OCPP charging: from protocol claim to backend acceptance
A procurement guide to OCPP versions, certificate scope, charging management and the tests to agree before a commercial rollout.
On this page 5 sections
OCPP is the communication protocol between a charging station and its management system. A buyer should specify the required version, functions, security configuration and target backend, then verify them on the actual equipment. A catalogue statement alone does not establish that every operational function will work.
Separate three different connections
| Connection | What it covers | What to confirm |
|---|---|---|
| Vehicle to charger | The physical inlet and vehicle charging communication | Connector, vehicle compatibility and electrical limits |
| Charger to management system | Remote charging operations through OCPP | Protocol version, firmware, supported functions and credentials |
| Management system to business services | Payment, reporting, roaming and support workflows | Service providers, interfaces, ownership and fees |
Choosing OCPP equipment does not by itself purchase a backend subscription, payment service or roaming agreement.
Can an OCPP 2.0.1 charger use an OCPP 1.6 backend?
Not merely because both products say OCPP. OCPP 2.0.1 is not backward compatible with OCPP 1.6, as explained in OCA’s OCPP 2.0.1 overview. Confirm a protocol version actually supported at both ends. If a supplier proposes multi-version support or a gateway, make the supplied firmware, responsibilities and acceptance tests explicit.
Record the required version and implemented functions in the brief instead of asking only for the “latest OCPP.” OCA’s protocol overview lists OCPP 1.6, 2.0.1 and 2.1; version availability alone does not establish a particular charger’s implementation.
What does an OCPP certificate establish?
Check the named product, software version and tested scope. OCA lists Core, Smart Charging and Advanced Security profiles for OCPP 1.6; Smart Charging is optional for a charging station in that programme. A certificate should therefore be read for its actual scope, rather than treated as proof of every function. OCA certification guidance.
For an OEM project, ask whether the supplied brand and firmware are covered and whether additional certification work is required. Keep protocol testing separate from the product’s electrical and market documentation.
Agree an acceptance test before ordering
| Test | A useful acceptance record |
|---|---|
| Connection and authentication | The selected unit connects with the agreed identity and security settings |
| Authorization | Approved RFID or other access methods start the correct session |
| Transactions and meter values | Start, stop, timestamps and energy records appear correctly in the backend |
| Remote commands | Start, stop, reset and configured limits behave as agreed |
| Offline operation | The station follows the agreed offline policy and recovers records on reconnection |
| Smart charging | A requested limit is applied and the response is measured under changing demand |
| Software maintenance | Updates, rollback or recovery, logs and support access have a defined process |
Record the hardware revision, firmware, backend version, date, test conditions and unresolved issues. Recheck affected functions when a module or firmware changes.
Which Ampvoya products are candidates?
The EC-W300 7 kW wallbox lists Wi-Fi and Bluetooth connectivity, but its technical data does not specify OCPP. Connectivity alone does not establish OCPP support. Any future OCPP configuration needs its own protocol, firmware and backend acceptance review.
Use the commercial AC brief or public charging brief to define the application. If the site needs power control, include the load-management requirements in the same test plan.