OCPP 1.6 vs 2.0: How to Evaluate Supplier Compatibility

Why the protocol version matters

OCPP is the standard protocol for communicating between a charging point and the central management system. It defines the messages sent for authentication, metering, error reporting, and firmware updates. Most charging infrastructure projects specify either OCPP 1.6 or OCPP 2.0 in the procurement documents. The chosen version determines the data model, the message structure, and the security features available to the operator.

Selecting a supplier based on general capability is not enough. A charger that supports OCPP 2.0 may still lack specific features required by a particular host network. The supplier evaluation process must verify that the hardware and software align with the technical specifications of the intended deployment. This section focuses on how to assess vendor readiness for these specific communication protocol versions.

In practice, the protocol version dictates how your backend software interprets the data stream from the field. If the charger sends a metering record in a format the backend does not expect, the data may be discarded or misattributed. This leads to billing errors, inaccurate utilization reports, and difficulty troubleshooting offline units. The protocol is not just a communication channel. It is the contract between the hardware and the software stack.

When specifying OCPP in a tender, avoid generic language like “OCPP compatible.” Specify the major and minor version, such as OCPP 1.6J or OCPP 2.0.1. Indicate whether the project requires the JSON variant for 1.6 or the full 2.0 data model. Clarify which authentication methods are mandatory, such as X.509 certificates or shared secrets. These details prevent ambiguity during the integration phase and allow your engineers to validate the supplier’s compliance before signing the contract.

What changes between OCPP 1.6 and 2.0

The shift from OCPP 1.6 to 2.0 represents a significant update to the protocol. OCPP 2.0 introduces a more structured data model that uses JSON. This makes the messages easier to parse for engineers and reduces the chance of parsing errors in the backend systems. The newer version also improves the handling of authentication, allowing for more secure token based access.

For a professional buyer, the difference is practical. OCPP 2.0 supports advanced metering data more efficiently. It also handles remote control and firmware updates with greater reliability. However, the transition is not always straightforward. A supplier that has built its platform on OCPP 1.6 may require a complete software rewrite to support 2.0. This affects the timeline and the cost of the project.

The data model change is the most visible difference. OCPP 1.6 relies on XML messages, which are verbose and require strict schema validation. OCPP 2.0 uses JSON, which is lighter and more flexible. This flexibility allows for nested data structures, making it easier to transmit complex information about energy usage, power quality, and vehicle data in a single message. For a backend system that processes thousands of chargers, the reduced payload size and faster parsing speed of JSON can lower processing costs and improve real-time response times.

Authentication in OCPP 2.0 moves away from simple shared secrets toward more robust methods. The protocol supports X.509 digital certificates, which provide strong identity verification and prevent man-in-the-middle attacks. This is particularly relevant for public charging networks where security is a priority. OCPP 1.6 relies on a simpler token-based system that is easier to implement but offers less protection against unauthorized access. If your host network requires certificate-based authentication, OCPP 1.6 may not meet the requirement without additional workarounds.

Metering capabilities have also expanded in OCPP 2.0. The protocol supports finer granularity in energy measurement, allowing operators to track power quality metrics such as voltage, current, and power factor. This data is useful for grid integration and demand management. OCPP 1.6 provides basic energy metering but lacks the detailed power quality reporting found in 2.0. For projects focused on grid services or smart charging, the advanced metering in OCPP 2.0 offers significant advantages.

Firmware updates are another area where 2.0 improves upon 1.6. The protocol supports a more structured update process, allowing the central management system to manage multiple chargers simultaneously and verify the integrity of the update package. This reduces the risk of bricking a unit during a failed update and simplifies fleet management. OCPP 1.6 has basic update support, but it often requires manual intervention or less reliable processes for large fleets.

How to check supplier documentation

The first step in OCPP supplier evaluation is reviewing the technical documentation. The supplier should provide a clear list of supported protocol versions. Do not rely on a general statement that the charger is OCPP compliant. Ask for the specific version number and the firmware release that supports it.

Request the API documentation or the data dictionary. This document lists every message and every parameter. It allows your engineering team to see exactly what data the charger sends and what commands it accepts. If the supplier cannot provide this document, it is a red flag. It suggests the team may not fully understand their own product, or they may be relying on a third party for the communication layer.

A practical check is to ask for a sample configuration file. This file shows how the charger connects to a specific host network. It includes the endpoints, the security tokens, and the authentication methods. Reviewing this file helps your team verify that the supplier has actually configured the charger for real world use, not just in a test lab.

Documentation quality is a direct indicator of a supplier’s engineering maturity. A well-documented product suggests a disciplined development process and a team that understands the protocol deeply. A poorly documented product often indicates a rushed release or a product that has not been thoroughly tested. When reviewing the data dictionary, look for clarity in parameter descriptions and units. Ambiguous descriptions, such as “energy value” without specifying kWh or Wh, can lead to integration errors.

The firmware release notes are equally important. They should detail the changes in each version, including bug fixes, new features, and known issues. This information helps your team assess the stability of the current release. If the notes are vague or missing, it may indicate that the supplier is not tracking changes rigorously. For a critical infrastructure component, this lack of transparency is a significant risk.

The sample configuration file is a powerful tool for verification. It should include the host network’s URL, the charger’s unique identifier, and the authentication details. Reviewing this file allows your team to check for common configuration errors, such as incorrect port numbers or missing certificate paths. If the supplier provides a generic configuration file that does not reflect the specific host network, it suggests that the supplier has not tested the product in the intended environment.

Evaluating interoperability and testing

Protocol support on paper is different from protocol support in the field. The supplier should be able to demonstrate interoperability with the host network. This is the most critical part of the evaluation. A charger must not only send the correct messages but also handle the responses from the backend correctly.

Ask the supplier to provide a test report or a proof of concept. This should show the charger communicating with the intended host network or a neutral testing environment. The test should cover basic charging, remote start, and error reporting. It should also include a check for metering accuracy. If the supplier cannot provide this evidence, you must plan for your own integration testing.

During this phase, your engineers should monitor the raw messages. They need to verify that the timestamps are correct, that the error codes are standard, and that the metering data matches the expected format. This level of detail is often missed in early procurement stages. It is better to catch these issues now than after the hardware is installed on site.

Interoperability testing is where many projects face delays. Even if the charger supports the correct OCPP version, it may fail to communicate with the host network due to subtle differences in implementation. For example, a charger might send a valid OCPP 2.0 message, but the host network might expect a specific parameter order or a particular error code handling method. These discrepancies can cause the charger to be listed as offline or to reject remote commands.

A proof of concept should involve a controlled environment where both the charger and the host network are present. The test should simulate various scenarios, including normal charging, network interruptions, and error conditions. The supplier should document the results, showing that the charger behaves as expected in each case. If the supplier cannot provide this documentation, it may indicate that they have not tested the product thoroughly or that they are unwilling to share their internal testing processes.

Your engineering team should also verify the handling of edge cases. For example, what happens if the charger loses network connectivity for an extended period? Does it buffer metering data and send it once the connection is restored? What happens if the host network sends a command that the charger does not support? The supplier should explain how the charger handles these situations and provide evidence that they have been tested.

A worked example

Consider a project for a multi site fleet charging network. The operator requires OCPP 2.0 support for all new chargers. The engineering team shortlists two suppliers.

Supplier A provides a data sheet that lists OCPP 2.0. The team requests the firmware release notes. The notes confirm that the current release supports the required authentication methods. The team then asks for a sample configuration file for the operator’s specific host network. Supplier A provides the file within a week.

Supplier B also claims OCPP 2.0 support. However, the data sheet is vague. When the team requests the firmware release notes, Supplier B says the information is available on a secure portal. The team accesses the portal and finds the release notes are for a beta version that has not been approved for commercial use. When asked for a sample configuration file, Supplier B states that it must be generated by the operator’s IT team.

The engineering team rejects Supplier B. The lack of a tested configuration file and the use of a beta firmware version create too much risk. Supplier A is selected because it can prove that the charger works with the specific network requirements. This example shows how a simple request for documentation can reveal a major gap in supplier capability.

In this scenario, Supplier A demonstrated a clear understanding of the project requirements and a willingness to provide detailed technical information. Supplier B’s reliance on a beta firmware version and a generic configuration process indicated a lack of maturity in the product. The engineering team’s decision to prioritize Supplier A was based on the need to minimize integration risk and ensure that the chargers would work as expected in the field.

This example highlights the importance of asking for specific documentation. A data sheet alone is not enough. The engineering team needed to see evidence that the supplier had tested the charger with the intended host network and that the firmware was stable and ready for production. By demanding this level of detail, the team was able to make an informed decision and avoid potential delays and costs associated with integration issues.

Key questions for the supplier

When speaking with a vendor, ask for specific details. Do not accept general answers. The following questions help narrow down the technical readiness of the supplier.

1. What is the exact OCPP version and firmware release number you are proposing?
2. Can you provide the data dictionary or API documentation for that specific release?
3. Have you tested this unit against the specific host network required for this project?
4. What is the process for applying firmware updates to the charger field?
5. How do you handle authentication and security tokens for the connection?
6. What is the expected message latency for metering data transmission?

These questions force the supplier to move from marketing language to technical reality. The answers will tell you whether the supplier has a mature product or if you are buying a prototype.

When asking these questions, listen for hesitation or vague responses. If a supplier cannot provide the exact firmware release number, it may indicate that they do not have a stable release. If they cannot provide the data dictionary, it may indicate that they are relying on a third party for the communication layer. If they have not tested the unit against the specific host network, it may indicate that they have not considered the integration requirements of the project.

The process for applying firmware updates is also critical. A supplier should have a clear process for updating chargers in the field, including how to verify that the update was successful and how to roll back if necessary. If the supplier does not have a clear process, it may indicate that they do not have a mature fleet management system. This can lead to downtime and difficulty in troubleshooting.

Comparing protocol support

The table below shows the typical differences between the two versions. This is a general comparison based on standard protocol features. Your specific project requirements may prioritize one aspect over another.

Feature	OCPP 1.6	OCPP 2.0
Data Format	XML	JSON
Authentication	Basic Token	Advanced Token
Metering	Standard	Advanced
Firmware Updates	Basic	Enhanced
Error Handling	Standard	Detailed

The JSON format in OCPP 2.0 is easier to read and write for modern software stacks. The advanced authentication allows for finer control over access rights. The enhanced firmware update process helps manage large fleets with fewer manual interventions. However, OCPP 1.6 is still widely supported by many legacy systems. If your host network has not migrated to 2.0, sticking with 1.6 may be the safer choice.

When comparing the two versions, consider the total cost of ownership. OCPP 2.0 may offer better performance and security, but it may also require more complex backend software and higher initial costs. OCPP 1.6 may be simpler and cheaper, but it may lack the features needed for future expansion. The right choice depends on your specific project requirements and long-term plans.

Final considerations

The goal of OCPP supplier evaluation is to reduce integration risk. The protocol is the bridge between the hardware and the software. If that bridge is not built correctly, the entire system fails. The supplier must be able to prove that the bridge is solid.

Review the documentation. Test the interoperability. Check the firmware status. These steps are not optional. They are the core of the procurement process for charging infrastructure. By focusing on these specific checks, you ensure that the supplier is ready to support your network for years to come. The time spent in this phase saves significant costs during the installation and commissioning stages.

the goal is to select a supplier that can deliver a product that works as expected in the field. By focusing on the technical details and demanding evidence of testing and documentation, you can make an informed decision and reduce the risk of integration issues. The time spent in this phase is an investment that will pay off in the long run, as it will help ensure that your charging network is reliable and efficient.