OCPP 2.0.1 CMS Migration: Run 1.6J and 2.0.1 Chargers on One Platform
Your backend has to accept 2.0.1 before a single charger can speak it, and you cannot take the network down to do it. We add a dual-stack layer, a certificate authority and device model handling underneath a live service, without touching billing, roaming or your apps.
Every 1.6J charger keeps running throughout. Chargers move one model at a time, once their firmware has proven itself.
- RIOD builds the Powerpod chargers and Charger360, its own OCPP software
- Both ends of the connection are tested against each other on our own bench
- Around 50 engineers, and over ten years of embedded and cloud engineering
Why the backend moves first
The two protocols are not compatible, so a 2.0.1 charger pointed at a 1.6J-only backend does not connect at all. Every charger maker shipping 2.0.1 firmware, every AFIR deadline and every tender naming IEC 63584 arrives at your platform before it arrives anywhere else.
The constraint is that none of it can stop. Drivers keep charging, invoices keep going out, roaming partners keep sending sessions. The work happens underneath a running service or it does not happen.
If nothing is forcing the move yet, we will say so. What follows is for the networks where something is.
What changes in the backend
| Area | 1.6J backend | 2.0.1 backend | What gets built |
|---|---|---|---|
| Connections | One WebSocket subprotocol | Two on the same platform | A gateway that reads the version and routes |
| Charger data | Charge point and connectors | Station, EVSE, connector, device model | One model holding both, so one screen shows everything |
| Transaction IDs | The CMS issues a number | The charger issues a text ID | Session records accepting both, mapped to one billing ID |
| Session messages | Start, stop, meter values | TransactionEvent with sequence and trigger | Handling that reassembles sessions, including ones sent late after an outage |
| Tokens | An idTag string | Typed IdToken | One token model for RFID, app, Plug and Charge and roaming |
| Security | Passwords, if anything | Profiles 2 and 3 with certificates | A certificate authority and lifecycle service |
| Firmware | A download URL | Signed images with status | Campaigns in waves, with rollback |
| Smart charging | Charging profiles | Profiles, EV needs and external limits | Site and grid-aware scheduling |
Dual-stack: both protocols, one platform
A gateway that routes by version
Every charger connects to the same address. The gateway reads which OCPP version the charger asks for as it opens the WebSocket and routes it accordingly. A charger moves between them without its address or identity changing.
One domain model underneath
Both handlers translate into one shared model of stations, EVSEs, connectors, sessions and tokens. A session is a session, whichever protocol reported it.
Everything else stays as it is
Billing, OCPI roaming, the driver app, the support desk and reporting all read the shared model. None of them needs to know a migration is under way.
Becoming a certificate authority
Security profile 3 means your platform signs certificates for your chargers, for as long as those chargers live. That is a service to build and run carefully, not a feature to switch on.
- Separate handling for profile 2 and profile 3 endpoints, TLS 1.2 or higher.
- Signing requests checked against a known charger before anything is signed.
- Expiry tracking, automatic renewal, and revocation when a unit is replaced or compromised.
- New roots rolled out to the fleet before the old ones expire.
- A unique password per charger for profile 2, set and rotated remotely.
- CA keys in a hardware security module or cloud key service, never in application code.
- Security events and logs feeding alerts, so repeated failed logins are seen rather than discovered.
- For Plug and Charge, integration with V2G root and contract certificate providers.
Onboarding without anyone on site
- 1The maker's serial numbers and identities are imported before the units ship.
- 2The charger connects to the provisioning endpoint and sends BootNotification.
- 3The CMS matches the serial, replies Pending, and assigns operator and site, often from the installer's scan.
- 4It reads the device model and applies the template for that model and site.
- 5It signs the certificate, sends the new connection profile, and moves the charger to profile 3.
- 6It brings the charger to the approved firmware version.
- 7The charger is accepted, appears on the map and starts taking sessions.
Device model, firmware campaigns and smart charging
2.0.1 chargers describe themselves in detail. The platform stores each full report, applies templates by model, sets monitoring thresholds and flags any charger whose settings have drifted. Support sees what is inside a charger instead of guessing.
Signed firmware goes out in waves by model, region or site, with every step tracked from download to signature check to install. Updates wait for idle chargers, a failure stops the wave, and rollback is one action.
Site power limits, load balancing, limits from building energy systems and the vehicle's own reported needs all feed one schedule per site. The same logic drives 1.6J chargers through the profiles they support.
Plug and Charge and AFIR
AFIR requires ISO 15118-20 on public AC and DC points installed or renovated from 1 January 2027. On the backend that means contract certificate handling, eMAID tokens, and roaming data shared through OCPI. Standard price display and in-session cost updates come with the same protocol work.
How a CMS migration runs
- 1Audit: your platform, charger models, integrations and security posture.
- 2Gateway and domain model first, with every 1.6J charger still running exactly as before.
- 3Then the 2.0.1 handlers and the PKI: transactions, device model, certificates, firmware, smart charging.
- 4Testing: compliance cases, then a bench of real 2.0.1 chargers from more than one maker.
- 5Pilot: one group switches while billing and roaming are checked line by line.
- 6Migration by model, each once its firmware is proven.
- 7The 1.6J handler stays for as long as you have chargers that need it.
What you get
- A dual-stack gateway on the platform you already run.
- A common data model for stations, EVSEs, sessions and tokens.
- A certificate authority with signing, renewal, revocation and root rotation.
- Zero-touch onboarding from factory import to live.
- Device model storage, templates and drift alerts.
- Firmware campaigns with waves and rollback.
- Smart charging and the Plug and Charge back end.
- Test reports, runbooks and documentation.
Who it is for
- Operators with chargers from several makers, some already shipping 2.0.1.
- Platform companies that need 2.0.1 for their own customers.
- eMobility service providers preparing for Plug and Charge.
- Fleet, depot and utility operators whose IT requires certificate-based security.
Common questions
Can one platform run 1.6J and 2.0.1 at once?
Yes. A dual-stack gateway routes each charger to the right handler and both feed one shared data model.
Do we have to take the network down?
No. The gateway goes in while every 1.6J charger keeps running, and chargers move one model at a time.
What happens to billing and session history?
Both protocols map into the same session records, and 2.0.1 transaction IDs are linked to your existing billing IDs, so history stays continuous.
Why does the backend need a certificate authority?
Profile 3 gives each charger its own certificate. Something has to sign, renew and revoke those for the life of the charger, and that something is your platform.
Does this affect OCPI roaming?
No. Roaming reads the common model, so partners see the same sessions and locations as before.
Do we have to replace our CMS?
No. The 2.0.1 layer is added to what you already run. Replacing it is a different project, and usually a worse one.
How long does it take?
Industry guides suggest two to three months for the backend and six to twelve for a full network move including firmware rollout. The audit gives you a figure for your platform rather than an average.
Can you test against our charger models?
Yes, alongside our own Powerpod units on the bench.
Is OCPP 2.0.1 a recognised standard?
Yes. It is published as IEC 63584:2024, which is the name tenders increasingly use, and OCPP 2.1 builds on it.
How do we know whether it is time?
Four triggers decide it: AFIR for public points from 1 January 2027, a tender naming IEC 63584, a buyer requiring certificate-based security, or charger makers shipping 2.0.1 into your network. If none applies yet, the migration can wait, and we will tell you that rather than sell you one.
Related
Add 2.0.1 without switching anything off
The migration review looks at your platform, your charger models and your integrations, and comes back with a plan and an order of work.