Open Charge Point Protocol (OCPP 1.6 & 2.0.1) Network Integration

1. What OCPP Is and Why It Matters to Charge Point Operators

The Open Charge Point Protocol (OCPP) is an open protocol defining communication between a charge point and a central management system (CSMS), developed by the Open Charge Alliance to break vendor lock-in. Without OCPP, an operator is bound to a single charger manufacturer's software indefinitely. Choosing OCPP-compliant hardware preserves the freedom to switch platform providers, to mix charger brands in one network, and to build toward the operator's own payment systems and applications later.

Technically, the widely deployed OCPP 1.6 communicates over WebSocket with JSON messages (known as OCPP 1.6J) and covers the full set of core operations: user authorization (Authorize), session start and stop (StartTransaction / StopTransaction), meter readings during charging (MeterValues), connector state reporting (StatusNotification), and remote commands such as resetting a unit or unlocking a connector. These messages are the foundation of billing on actual energy delivered and of remote unit management without dispatching a technician to site.

2. OCPP 1.6 Versus OCPP 2.0.1

OCPP 2.0.1 is not an incremental update but a complete redesign of the message structure, and is therefore not backward compatible with 1.6. Its major advances are finer-grained device management through the Component and Variable model, security defined within the standard itself — certificate handling, TLS encryption, and security event logging — and support for ISO 15118, enabling Plug & Charge where the vehicle authenticates itself automatically on connection without a card tap or an app.

In the Thai market, most chargers currently sold primarily support OCPP 1.6J, and commercial CSMS platforms support 1.6 completely. Operators making new investments should choose hardware with a declared firmware upgrade path to 2.0.1 to avoid obsolescence as the ecosystem transitions. The item worth verifying is Open Charge Alliance certification on both the charger and the platform side, because an unverified claim of "OCPP support" without compatibility testing frequently leads to connection problems that are difficult to resolve after installation.

• OCPP 2.0.1 redesigns all messages; it is not backward compatible with 1.6
• Security is built into the standard: certificates, TLS, security event logs
• Supports ISO 15118 for Plug & Charge
• Verify Open Charge Alliance certification on both charger and platform

3. Connecting a Charger to a CSMS

Onboarding begins with preparing the charger's communication path — LAN, Wi-Fi, or a 4G SIM — with signal strength always tested at the actual installation point. The charger is then configured with the CSMS WebSocket URL and a unique Charge Point Identity. On successful connection it sends a BootNotification reporting model, serial number, and firmware version; the central system accepts it and the Heartbeat cycle begins to continuously confirm the unit is online.

After connection, a full end-to-end test should follow: RFID tap for Authorize, session start with verification that MeterValues report cumulative energy matching the internal meter, session stop with correct energy totals on the transaction record, and remote commands such as Remote Start/Stop and Reset. Finally, tune the meter value interval to balance data resolution against SIM data consumption — an excessively frequent interval inflates cellular costs without operational benefit.

4. Common Connectivity Issues and Troubleshooting

The most common OCPP problem is intermittent offline periods caused by unstable cellular signal, leaving transactions unsent and billing totals mismatched against energy actually delivered. Standards-compliant chargers queue transactions in memory and forward them once back online, but some models have limited queue depth. Another recurring issue is incorrect unit clocks or missing NTP synchronization, which skews session start and stop timestamps and breaks time-of-use tariff calculation.

Troubleshooting should begin with OCPP message logs from both ends, identifying where the exchange breaks — for example, the charger sends StartTransaction but never receives a TransactionId, or the CSMS rejects a duplicate identity. Systemic preventions include multi-network roaming SIMs, external antennas at weak-signal locations, watchdog-driven automatic reconnection, and dashboard monitoring of missed heartbeats so the operations team learns of problems before users call to complain.

• Use multi-network roaming SIMs where signal is unreliable
• Fit external antennas at weak-signal locations
• Configure watchdog-driven automatic reconnection
• Monitor missed heartbeats on a central dashboard