Understanding OCPP: Technical Overview and Implementation

The Need for Standardization

In the early stages of the EV industry, proprietary protocols created significant interoperability challenges. Operators were often locked into specific hardware vendors, limiting flexibility.

The Open Charge Alliance addressed this by developing OCPP (Open Charge Point Protocol).

OCPP serves as the universal standard, decoupling hardware from software. This allows a CPO (Charge Point Operator) to manage chargers from multiple manufacturers within a single central system, such as Anthaathi's platform.

Technical Architecture

OCPP defines the messaging structure between a Charge Point (CP) and a Central System (CSMS).

SOAP vs. JSON (The Modern Shift)

• OCPP 1.5 / 1.6S (SOAP): Earlier versions relied on XML-based SOAP. This often presented networking challenges, as it typically required the CSMS to initiate connections to the charger, complicating firewall and NAT configurations.
• OCPP 1.6J (JSON over WebSockets): The current industry standard. In this model, the charger initiates a persistent outbound WebSocket connection to the server. This is firewall-friendly and supports full-duplex communication.

Implementation Note: Modern CSMS development focuses primarily on WebSocket implementations (OCPP-J) due to their efficiency and ease of deployment.

Transaction Lifecycle

A standard charging session involves a specific sequence of messages:

1. Authorize: The charger sends the credential (e.g., RFID tag) to the server.
   • Server Response: Validates the tag against the database and returns Accepted or Invalid.
2. StartTransaction: Upon authorization, the charger locks the connector and begins energy transfer. It sends a message indicating the start of a transaction with the initial meter reading.
3. MeterValues: During the session, the charger sends periodic updates (e.g., every 60 seconds) containing data such as current (A), voltage (V), and energy consumed (Wh).
   • Usage: This data drives real-time monitoring and smart charging calculations.
4. StopTransaction: When the session ends (user action or battery full), the charger reports the final meter reading and the reason for stopping.

Offline Resilience

Network connectivity can be intermittent. A robust OCPP implementation must handle these scenarios:

• Local Whitelist: The CSMS can push a list of valid tags to the charger (SendLocalList), enabling authentication even when offline.
• Message Buffering: Chargers must store transaction messages in internal memory during outages. Upon reconnection, these messages are "replayed" to the server to ensure accurate billing and record-keeping.

Evolution to OCPP 2.0.1

OCPP 2.0.1 introduces significant enhancements over 1.6:

• Enhanced Security: Native support for TLS and secure firmware updates.
• ISO 15118 Support: Enables Plug & Charge functionality.
• Device Management: Improved reporting of hardware status (e.g., component health, temperatures).

The Prevalence of OCPP 1.6J

Despite the benefits of 2.0.1, version 1.6J remains widely deployed. The transition to 2.0.1 involves significant changes to data structures and schemas, requiring updates from both hardware firmware developers and CSMS providers. However, adoption of 2.0.1 is accelerating, driven by new security regulations and advanced feature requirements.

Handling Implementation Variances

While OCPP is a standard, interpretations can vary between manufacturers.

• Heartbeat Intervals: Some chargers send "Heartbeat" messages strictly, while others suppress them during active transactions. A flexible backend must accommodate these behaviors.
• Addressing Connector Identification: Different hardware configurations (e.g., multi-gun DC chargers) may report connectors differently—either as sub-connectors of one charge point or as distinct charge points. The data model must support both configurations.
• Time Synchronization: It is best practice to rely on UTC server time for transaction records while logging charger-reported time for diagnostic purposes, as internal charger clocks can drift.

Anthaathi's Integration Layer

Anthaathi’s platform utilizes a scalable WebSocket architecture (Node.js/Go).

We implement a driver abstraction layer to manage the nuances of different hardware implementations. This ensures that variances in how different brands handle specific commands (like RemoteStart) are abstracted away from the operator.

We also support OCPP 2.0.1 for new deployments, ensuring compliance with emerging industry standards and security requirements.

For inquiries about network integration or backend compatibility, please contact our technical team.