OCPP 2.0.1 in Practice
OCPP 2.0.1 is not 1.6J with more messages. It introduces an explicit device model, a defined security model and a considerably richer diagnostic surface, and those three are the reasons to care. It also does not make two systems interoperable, which is the thing most buyers assume they are purchasing.
Written for deciding rather than implementing: what 2.0.1 was trying to fix, the device model that most underestimate, the security profiles, what changed in smart charging and diagnostics, what the version does not solve, and where 2.1 goes.
Ask if 2.0.1 matters to youFor Anyone who has read OCPP 2.0.1 in a specification and has to decide whether it changes what they buy or build.
What 2.0.1 was trying to fix
OCPP 1.6J was written for a smaller, simpler charging world and it succeeded well enough to become the installed base. Its weaknesses became visible at scale rather than in principle.
- Configuration was a flat list of keys and values, with no standard way to know what a given charger even supported
- Security was left to deployment, which meant it was frequently left out
- Diagnostics amounted to uploading a log file, which is not a monitoring system
- Smart charging was thin, and the installed base needed more control as sites got denser
- Vendor extensions filled the gaps, which meant every integration was bespoke
The device model, which is the part everyone underestimates
In 1.6J a charger was implicitly a charge point with connectors. In 2.0.1 a charger describes itself as a structured set of components, each with variables that have types, attributes and characteristics.
This is what lets a backend discover what a charger can do rather than being told out of band. It is also the single largest piece of work in a migration, because most existing firmware has no internal representation of itself and has to acquire one. Teams that scope a migration as a protocol layer swap and then meet the device model are the teams whose projects overrun.
Security, defined rather than assumed
2.0.1 defines security profiles rather than leaving transport security to the deployment. Profile 1 is basic authentication without transport security. Profile 2 adds TLS with a verified server. Profile 3 requires a client certificate and mutual TLS.
The practical consequence is that a tender can now specify security in a way that means something, and that a charger claiming 2.0.1 support should be asked which profile it implements. Support for the version does not imply support for profile 3, and profile 3 is where the provisioning and certificate lifecycle work begins.
Smart charging and diagnostics
- 1
Smart charging
Substantially extended: clearer limit hierarchy, better expression of what a limit means and where it came from, and a model that handles several sources of constraint without ambiguity about which wins.
- 2
Monitoring
Variables can be monitored with thresholds and reported on change, rather than polled. This is the difference between a platform that knows a charger is drifting and one that finds out when it fails.
- 3
Reporting
Structured reports about the device and its state, rather than a log file to be parsed by a human.
- 4
Transactions
An event based model with a defined lifecycle and richer reasons, which makes reconciliation of interrupted sessions materially easier.
What it does not solve
This is the part worth reading twice, because it is the assumption that causes procurement failures.
- It does not make two systems interoperable. Compliance with a specification and interoperability with a particular platform at a particular release are different properties, and only the second one runs a network
- It does not remove vendor differences. Optional features remain optional, and what a vendor chose not to implement is still not there
- It does not secure a deployment by itself. A charger supporting profile 3 that is configured to profile 1 is configured to profile 1
- It does not obsolete 1.6J, which is the installed base across most of the world and is not being switched off
We have seen a customer buy a charger sold as an OCPP unit that would not work with the backend they had already committed to. Nothing on the datasheet was untrue. A version number is a claim about a protocol; their requirement was about a specific platform, a specific release and a specific set of messages.
Where 2.1 goes
OCPP 2.1 builds on 2.0.1 rather than replacing it, with the emphasis on bidirectional power flow, richer energy management and tighter alignment with the grid services charging is increasingly expected to provide.
The practical point for anyone choosing now: the migration path from 2.0.1 to 2.1 is far shorter than from 1.6J, because the device model is already in place. Our own 2.1 work is in development, with 1.6J and 2.0.1 both shipping today.
Want this applied to your own site?
Ask if 2.0.1 matters to youTechnically reviewed by Deepu Joy, Director of Products and Delivery. Last reviewed 2026-09-10.
Frequently asked questions
Is OCPP 1.6J obsolete?
No. It is the installed base across most of the world and it is not being switched off. New procurement increasingly specifies 2.0.1, which is a commercial reason to support it rather than a technical reason to abandon 1.6J.
What is the hardest part of supporting 2.0.1?
The device model. A charger has to describe itself as structured components and variables, and most existing firmware has no internal representation of itself to describe.
Does 2.0.1 mean my charger and my platform will work together?
No. Compliance and interoperability are different properties. Verify against the platform and release you will actually run, with the messages your operation depends on.
Which security profile should we require?
Ask which one a vendor implements rather than accepting the version number. Profile 2 is the pragmatic position for most fleets; profile 3 is what utilities and national schemes tend to require.
Should we wait for 2.1?
Generally no. 2.1 builds on 2.0.1, so getting to 2.0.1 is progress toward it rather than a detour. Waiting mostly means staying on 1.6J for longer.
Deciding whether 2.0.1 matters to you?
Tell us what your operation actually needs to do. That answers it faster than reading the specification does.
Ask if 2.0.1 matters to you