OCPP 1.6 vs 2.0: Complete Comparison

History and Evolution of OCPP

The Open Charge Point Protocol has evolved significantly since its inception. (New to the protocol? Start with our Introduction to OCPP guide).

• OCPP 1.2 & 1.5: Early versions that established the basic communication patterns.
• OCPP 1.6 (2015): The game-changer. Introduced JSON over WebSockets (OCPP 1.6J) alongside the traditional SOAP version, making it much easier to implement and scalable.
• OCPP 2.0 (2018): A major rewrite that solved many of 1.6's limitations but had some initial flaws.
• OCPP 2.0.1 (2020): The corrected and polished version of 2.0, which is now the target for next-generation implementations.

The Open Charge Alliance (OCA) recognized that to support millions of EVs, a simple remote control protocol was not enough. They needed a robust, secure, and bidirectional energy management system. This motivation drove the massive architectural leap from 1.6 to 2.0.1.

Architecture Differences

The most immediate OCPP protocol difference developers notice is the format.

• OCPP 1.6: Supports both SOAP (XML) and JSON over WebSockets. However, the industry has almost universally moved to the JSON (1.6J) implementation for efficiency.
• OCPP 2.0.1: Dropped SOAP entirely. It is exclusively JSON over WebSockets.

Device Management: In 1.6, configuring a charger was somewhat flat and limited. OCPP 2.0.1 introduces a comprehensive Device Model. Instead of simple configuration keys, you have a structured hierarchy of Components and Variables, allowing for much more granular control over the station's hardware and software.

Feature Comparison

Below is a detailed OCPP version comparison to highlight key functional differences.

Security Comparison

Security is where the differences are most critical. In OCPP 1.6, security was an afterthought, patched in via the "OCPP 1.6 Security Whitepaper".

• Profile 1 (Basic Auth): Uses HTTP Basic Authentication. Not secure over public networks.
• Profile 2 (TLS): Adds TLS encryption. Good, but the charger doesn't necessarily authenticate the server strictly in all implementations.
• Profile 3 (mTLS): Uses client certificates. Very secure, but certificate management in 1.6 is cumbersome.

OCPP 2.0.1 includes security by design. TLS is mandatory. It introduces dedicated messages for certificate management, making the handling of PKI (Public Key Infrastructure) feasible at scale. It also enforces signed firmware updates to prevent malicious code injection.

Message Structure Differences

The payload structure changed to be more camelCase and structured. 2.0.1 payloads are often cleaner but nested.

OCPP 1.6 BootNotification

{
  "chargePointVendor": "VendorX",
  "chargePointModel": "Model1",
  "chargePointSerialNumber": "SN123"
}

OCPP 2.0.1 BootNotification

{
  "chargingStation": {
    "model": "Model1",
    "vendorName": "VendorX",
    "serialNumber": "SN123"
  },
  "reason": "PowerUp"
}

Notice the nesting of chargingStation info and the addition of the reason field. This pattern of grouping related fields is common throughout 2.0.1.

Migration Considerations

Migrating a CSMS from 1.6 to 2.0.1 is not a simple update. It is effectively writing a new protocol handler.

• Backward Compatibility: There is none on the protocol level. A 1.6 charger cannot talk to a 2.0-only server.
• Dual-Stack Architecture: Most CSMS providers implement a "Dual Version" architecture. The server detects the protocol version during the WebSocket handshake and routes the connection to the appropriate handler (1.6 Service vs 2.0 Service).

Which Version Should You Choose?

Deciding between the two depends on your immediate needs and hardware availability.

• Choose OCPP 1.6J if: You need to support a wide variety of existing, older hardware. It is still the dominant standard in 2024.
• Choose OCPP 2.0.1 if: You are deploying a new fleet of modern chargers and need Plug & Charge (ISO 15118) or advanced smart charging features immediately.
• The Best Approach: Build your CSMS to support both. This allows you to onboard legacy hardware while being ready for the future.

Conclusion

OCPP 2.0.1 is undoubtedly the clearer, more robust, and more secure protocol. However, legacy hardware and the inertia of 1.6J mean we will live in a multi-version world for years to come.

Whether you are developing for 1.6 or 2.0, robust testing is essential to ensure your CSMS can handle the quirks of real-world chargers. See our CSMS Testing Guide for more strategies.

Check out how Mockpoint allows you to simulate both OCPP 1.6J and OCPP 2.0.1 scenarios to validate your implementation before you go live.