OCPP 1.6 vs. OCPP 2.0.1: EV Charging Protocol Upgrade Guide
OCPP (Open Charge Point Protocol) is the universal communication standard in the electric vehicle charging field. Simply put, it acts like a "translator" between charging stations and backend management systems, allowing devices from different brands to communicate using the same language. This protocol is managed by the Open Charge Alliance, an international organization composed of global EV infrastructure companies. The core value of OCPP is that it is a free, hardware-independent open standard. This means that operators do not have to be locked into one vendor's ecosystem, and can flexibly choose ev charging stations from different brands while managing them using the same software system. Currently, the most widely used version on the market is OCPP 1.6, while 2.0.1, as the next-generation standard, is gradually being promoted. This article will provide a detailed comparison of these two versions to help you determine whether an upgrade is necessary.
Since its release in 2015, OCPP 1.6 has become the de facto standard for global charging networks. The vast majority of charging stations still use this version today, including its improved 1.6(j) variant. Its widespread adoption is simple to explain: it is structurally simple, operates stably, and is basically sufficient. For early charging networks, version 1.6 indeed met core needs: transmitting charging status, processing transaction records, and supporting remote control. However, as the charging industry rapidly develops, this nearly decade-old protocol has begun to show limitations. The main issues with OCPP 1.6 include:
The communication mechanism of version 1.6 was designed in an era of relatively simple network security threats. In today's complex network environment, its authentication method is relatively basic and easily becomes a target for attacks. For charging networks handling payment information and user data, this is a risk that cannot be ignored.
As charging station scale expands, version 1.6 begins to struggle. It does not support data compression or batch message transmission. Early versions even used the SOAP protocol, which is bulky and verbose, consuming a large amount of bandwidth. For large stations with hundreds of charging points, data transmission efficiency becomes a bottleneck.
Modern charging scenarios require diversified start methods: mobile apps, RFID cards, QR codes, NFC payments, credit cards, and ideally "plug-and-charge." However, version 1.6 natively supports only RFID cards and app tokens; other methods require external systems, increasing complexity and potential points of failure.
Version 1.6 simplifies the charging station structure to two layers: station and connector. This flat model cannot reflect the complex architecture of modern charging stations. In reality, a station may contain multiple power units, each controlling multiple plugs. The simplified 1.6 model makes it difficult for operators to accurately determine resource status, often relying on vendor-provided additional data, which varies in format and reliability.
The offline transaction handling mechanism in version 1.6 is not perfect. Transaction IDs are generated by the central system, and once the network is down, local IDs are prone to errors. Remote start events lack unique identifiers, making subsequent tracking difficult. These issues are particularly evident in areas with unstable signals, such as underground parking lots.
When a charging station malfunctions, the diagnostic information provided by version 1.6 is often not detailed enough. Operators find it difficult to quickly locate the root cause, resulting in low maintenance efficiency. Additionally, if a backend management system needs to be replaced, migrating 1.6 charging stations to a new platform is complex and can result in loss of historical data.
Although version 1.6(j) supports smart charging, allowing power limits and time windows, its capabilities are relatively basic. For scenarios requiring complex load balancing or Vehicle-to-Grid (V2G) interaction, version 1.6 is insufficient.
OCPP 2.0.1 is a revised version of 2.0 (the 2.0 version was discontinued due to multiple issues). It is a completely new architecture, incompatible with 1.6, with significant changes in design philosophy and operation.
The documentation for version 2.0.1 has been rewritten, with a clearer structure, modularized functions, and detailed diagrams and usage examples. For developers, this means shorter deployment time and fewer misunderstandings.
This is the most significant architectural change in 2.0.1. The new model consists of three layers:
Station: the entire charging facility
EVSE (Electric Vehicle Supply Equipment): physical controller managing power distribution
Connector: the actual charging plug
This layered structure allows the system to accurately identify the status of each power unit. For example, if an EVSE fails, operators can precisely locate the specific controller without affecting other functioning plugs at the station. This level of detailed management is particularly important for large charging stations.
Furthermore, the 2.0.1 device model extends to physical attributes such as temperature sensors, cooling systems, lighting, and display capabilities, providing more comprehensive data support for operations and maintenance.
Version 2.0.1 supports batch message transmission and data compression, greatly reducing bandwidth usage. In areas with limited communication infrastructure, this improvement can directly reduce operating costs.
The new version introduces security profiles, supporting basic authentication and certificate-based authentication (mTLS). Authentication information can be updated remotely, and security events actively notify the backend. These functions are essential for complying with data protection regulations and defending against cyberattacks.
The central system can restart individual EVSEs without affecting the entire station. For ongoing transactions, the system has improved status management. These functions significantly enhance operational flexibility and reduce reliance on on-site manual intervention.
Version 1.6 only supports transaction-based metrics, while 2.0.1 supports non-transaction-level metrics collection and introduces a new metrics model. Operators can more flexibly monitor equipment health, energy usage patterns, and other critical data.
2.0.1 natively supports advanced smart charging features, including load balancing and demand response. Importantly, it provides full support for Vehicle-to-Grid (V2G) interaction and ISO 15118 standard.
In addition to traditional RFID and app tokens, 2.0.1 natively supports PIN codes, credit cards, and other methods, providing a technical foundation for unmanned stations and plug-and-charge scenarios.
The new version improves offline operation: it supports complex token types, flexible local authorization list management, offline plug-and-charge, and standardized procedures for data caching and reconnection uploads. These improvements ensure reliable operation even in unstable network conditions.
This is one of 2.0.1's most forward-looking features. ISO 15118 is the communication standard between vehicles and charging stations, supporting plug-and-charge—users simply plug in, and the system automatically identifies them and starts charging, without card or app interaction.
Implementing this function requires coordination among vehicle manufacturers, charging station vendors, and network operators. 2.0.1 provides a complete technical framework, including certificate management, structured identity systems, and triggers aligned with ISO 15118 workflows.
2.0.1 allows the central system to send pricing information to charging stations, including current rates, estimated costs, and final bills. Users can view cost details directly on the station screen, enhancing transparency.
Understanding technical specifications is one thing; seeing their practical operation is another. The following three scenarios illustrate differences between the versions.
Taking the common scenario of "plug in first, then authorize":
Version 1.6 does not have a clear "CablePluggedIn" message. Systems usually infer this through status changes in StatusNotification (e.g., Preparing, SuspendedEV). The problem is that these statuses vary across vendors: some indicate waiting for card swipe, some indicate vehicle not ready, and some indicate internal self-test.
This ambiguity causes three issues: inconsistent behavior across brands affecting user experience, potential unauthorized transaction starts, and difficulty for backend systems to accurately assess the real status, affecting operational decisions.
Version 2.0.1 introduces TransactionEvent messages and TriggerReason fields, clearly indicating events like "CablePluggedIn." Combined with a well-defined transaction lifecycle, the process becomes predictable and traceable, with consistent behavior across vendors, significantly improving interoperability.
OCPP 1.6: Connector availability is limited to simple statuses such as online/offline or idle/occupied. For a station with eight plugs, if two are offline due to faults, 1.6 may not accurately reflect this detail.
OCPP 2.0.1: The EVSE layer allows precise identification of the problem—whether it's a communication failure of a controller or hardware issue of a specific plug. Operators can diagnose remotely and even restart a single power unit without dispatching technicians.
OCPP 1.6: Supports local RFID whitelist but lacks standards for expired lists, offline data integrity, and post-reconnection synchronization. Implementation varies widely, potentially causing lost or duplicate transactions.
OCPP 2.0.1: Defines complete offline workflows, including local authorization decisions, data caching, batch uploads after reconnection, and conflict resolution. This provides reliable technical support, particularly in areas with limited network infrastructure.
Despite the clear advantages of 2.0.1, industry adoption is slow. The main reasons include:
Cost and Complexity: Upgrading to 2.0.1 requires significant investment in hardware and software development. Firmware implementation cycles are long, and subsequent support costs are high. For operators, upgrading or replacing existing firmware may involve large-scale on-site work.
Stability Considerations: 1.6 has been proven stable over many years. While 2.0.1 has significant improvements, its complexity is higher. For operators prioritizing stable operations, “works reliably” often outweighs “has more features.”
Functional Alternatives: Many 2.0.1 features, such as QR code payment, fee display, and smart scheduling, can be implemented in 1.6 systems via external applications or custom development. Though less elegant, they meet basic needs.
Ecosystem Inertia: Millions of 1.6 devices are already deployed globally, forming a large ecosystem. Accessories, tools, and personnel skills revolve around 1.6. Migration requires rebuilding these capabilities.
New Charging Networks: For new infrastructure planning, it is recommended to adopt 2.0.1 to avoid future migration costs and fully utilize the performance and extensibility of the new standard.
High-End Applications: For plug-and-charge, V2G, and complex demand response projects, 2.0.1 is necessary, as 1.6 cannot reliably support these functions.
Large-Scale Operations: Operators with hundreds of chargers can benefit from 2.0.1's performance optimizations and detailed device models, improving operational efficiency.
Security and Compliance: Regions with strict data and payment regulations can rely on 2.0.1's security mechanisms to meet compliance more easily.
For most existing operators, fully switching to 2.0.1 is not yet timely. A pragmatic approach is:
Maintain existing 1.6 devices: Continue running the stable 1.6 system and supplement missing functions with external systems.
Select 2.0.1 for new devices: Choose 2.0.1-compatible equipment for newly built stations.
Require dual-version support: When purchasing new equipment, require vendors to support both 1.6 and 2.0.1, retaining flexibility for future upgrades.
Monitor industry trends: Track major vendors' 2.0.1 implementation progress to evaluate migration timing.
The relationship between OCPP 1.6 and 2.0.1 is similar to the transition from feature phones to smartphones. 1.6 is simple, reliable, and sufficient, supporting the first wave of global charging network development. 2.0.1 is more powerful, secure, and flexible, laying the foundation for next-generation charging experiences.
Which version to choose depends on your situation: if your existing 1.6 system is running well with no urgent feature needs, you can wait; for new projects or advanced feature requirements, embrace 2.0.1; for scenarios in between, adopt a gradual approach, preparing new devices for the future.
Regardless of the version, understanding these technical differences helps you make smarter decisions and build a more reliable and efficient EV charging network.
