What Is OCPP? Open Charge Point Protocol Explained

OCPP (Open Charge Point Protocol) is the standard that lets EV chargers communicate with a backend platform such as a CSMS (Charging Station Management System). Maintained by the Open Charge Alliance (OCA), OCPP allows chargers from different manufacturers to connect to compatible software without proprietary lock-in, which is why it underpins most modern EV charging networks.

As of 2025, over 750,000 OCPP-connected charge points are deployed worldwide according to the Open Charge Alliance, and every major charger manufacturer --- ABB, Schneider Electric, EVBox, Wallbox, Alfen, Tritium, Kempower, and Autel --- ships hardware with OCPP support built in.

If you are evaluating implementation or QA work right now, go straight to OCPP 1.6 testing, OCPP 2.0.1 testing, or platform features.

Why OCPP Exists

Before OCPP, every EV charger manufacturer built proprietary communication protocols. A ChargePoint station could only talk to ChargePoint's backend. An ABB charger required ABB's software. This created four systemic problems:

• Vendor lock-in: Operators were permanently tied to a single manufacturer's ecosystem for both hardware and software.
• No interoperability: Running a mixed-brand charging network was either impossible or required expensive custom integrations for each charger model.
• High integration costs: Every new charger model demanded months of bespoke protocol development, driving up costs for CSMS vendors.
• Slow innovation: Closed systems meant features developed by one vendor stayed siloed, and the industry moved slowly as a result.

The Open Charge Alliance, founded in 2012 in the Netherlands, created OCPP to solve these problems with a single, open, royalty-free standard. Today, OCPP is mandated or strongly encouraged by public funding programs across the EU, UK, and parts of the United States (notably California's NEVI program), making it the de facto global standard for EV charger communication.

How OCPP Works

OCPP operates on a client-server architecture where the charge point (the physical charger) acts as the client and the CSMS acts as the server. Communication flows over persistent WebSocket connections, enabling real-time bidirectional messaging between charger and backend.

Connection Lifecycle

The WebSocket connection lifecycle follows a predictable pattern:

1. DNS resolution and TCP handshake: The charger resolves the CSMS hostname and establishes a TCP connection to the configured endpoint (typically wss://csms.example.com/ocpp/).
2. TLS negotiation (if using wss://): The charger and server negotiate a secure TLS session. OCPP 2.0.1 defines three specific security profiles governing this step.
3. WebSocket upgrade: The charger sends an HTTP Upgrade request with Sec-WebSocket-Protocol: ocpp1.6 or ocpp2.0.1. The server validates the charger's identity (often from the URL path, e.g., /ocpp/CP001) and accepts or rejects the upgrade.
4. BootNotification: Immediately after the WebSocket is established, the charger sends a BootNotification message containing its vendor, model, serial number, and firmware version. The CSMS responds with Accepted, Pending, or Rejected along with a heartbeat interval.
5. Steady-state communication: Both sides exchange messages over the persistent connection. The charger sends periodic Heartbeat messages to confirm connectivity. Either side can initiate requests at any time.
6. Reconnection: If the connection drops, the charger automatically reconnects using configurable retry logic with exponential backoff.

For a deep dive into WebSocket connection management, error handling, and reconnection strategies, see our OCPP WebSocket guide.

Request-Response Pattern

Every OCPP interaction follows a strict request-response pattern using JSON-RPC-style framing over WebSocket. Messages are JSON arrays with a specific structure:

Call (Request):

[2, "unique-message-id", "BootNotification", {"chargePointVendor": "OCPPLab", "chargePointModel": "Simulator"}]

• 2 = Message type (Call)
• "unique-message-id" = Unique identifier for correlation
• "BootNotification" = Action name
• {...} = Payload

CallResult (Successful Response):

[3, "unique-message-id", {"status": "Accepted", "currentTime": "2025-02-20T10:00:00Z", "interval": 300}]

• 3 = Message type (CallResult)
• Same message ID as the originating Call
• {...} = Response payload

CallError (Error Response):

[4, "unique-message-id", "FormationViolation", "Invalid payload", {}]

• 4 = Message type (CallError)
• Standard error codes like NotImplemented, NotSupported, InternalError, ProtocolError, SecurityError, and FormationViolation

Each side can only have one outstanding request at a time per the specification (though some implementations relax this). A request must receive a response within a configurable timeout, typically 30 seconds.

OCPP Versions: A Complete History

The protocol has evolved through several versions, each addressing limitations of its predecessor:

For a detailed feature-by-feature comparison, see our dedicated OCPP 1.6 vs 2.0.1 comparison.

If you are evaluating tooling rather than protocol features, see best OCPP simulators compared.

OCPP 1.6

Released in 2015, OCPP 1.6 remains the most widely deployed version. The OCA estimates that over 85% of OCPP-connected chargers in the field run version 1.6. It introduced JSON over WebSocket as a transport option alongside the original SOAP/XML format, which dramatically simplified implementations.

Key capabilities of OCPP 1.6:

• Smart Charging: Basic charging profile management with SetChargingProfile and ClearChargingProfile
• Remote Operations: Start and stop transactions remotely, reset chargers, unlock connectors
• Authorization: Local authorization list management and remote ID tag validation
• Firmware Management: Remote firmware updates and diagnostics file uploads
• Meter Values: Periodic and transaction-based energy measurement reporting
• Reservation: Reserve a connector for a specific ID tag

OCPP 1.6 defines 25 messages split between charger-initiated and CSMS-initiated operations.

OCPP 2.0.1

OCPP 2.0.1 represents a ground-up rearchitecture of the protocol. Released in 2020, it addresses the most significant gaps in 1.6 while adding support for modern EV charging requirements like Plug & Charge (ISO 15118) and vehicle-to-grid (V2G).

Key improvements over 1.6:

• Device Model: A comprehensive, standardized data model for charger configuration --- replacing the ad-hoc key-value approach in 1.6 with a structured component/variable hierarchy
• ISO 15118 Support: Native support for certificate-based vehicle authentication, enabling true Plug & Charge without RFID cards
• Security Profiles: Three defined security levels with mandatory TLS, signed firmware updates, and secure boot chains
• Transaction Handling: Redesigned transaction event model that eliminates the "hanging transaction" problem in 1.6 where a StopTransaction message lost in transit could leave a transaction open indefinitely
• Display Messages: Remote control of charger screen content for pricing information, instructions, or advertisements
• Cost and Tariff: Real-time cost updates sent to the charger during a transaction
• Improved Smart Charging: Composite charging schedules, external power limits, and better integration with energy management systems

OCPP 2.0.1 defines over 50 messages, more than double the count in 1.6.

OCPP 1.6 vs 2.0.1: Detailed Comparison

OCPP Message Types: Complete Reference

OCPP 1.6 Messages

Charger-initiated (Charge Point to CSMS):

CSMS-initiated (CSMS to Charge Point):

OCPP 2.0.1 Messages (Selected Key Additions)

OCPP 2.0.1 retains the concepts from 1.6 but reorganizes and extends them significantly. Notable new or redesigned messages include:

OCPP Security Profiles

OCPP 2.0.1 defines three security profiles that provide escalating levels of protection. Security was one of the weakest areas in OCPP 1.6, where TLS was optional and most deployments ran unencrypted WebSocket connections.

Security Profile 1: Basic Authentication

Security Profile 1 uses unsecured transport (ws://) with HTTP Basic Authentication. The charger sends a username (typically the charge point identity) and password in the WebSocket handshake headers.

• Transport: Unencrypted WebSocket (ws://)
• Authentication: HTTP Basic Auth (password in Authorization header)
• Use case: Lab environments, isolated private networks
• Risk: Credentials and all OCPP messages travel in plaintext; vulnerable to interception

This profile exists primarily for backward compatibility and testing. It should never be used in production deployments over public networks.

Security Profile 2: TLS with Basic Authentication

Security Profile 2 adds TLS encryption while retaining password-based authentication. The charger validates the CSMS server certificate against a trusted root, ensuring it connects to the legitimate backend.

• Transport: Encrypted WebSocket (wss://) with server-side TLS
• Authentication: HTTP Basic Auth over TLS
• Certificate: Charger validates CSMS server certificate
• Use case: Production deployments where client certificate management is not feasible
• Advantage: All traffic is encrypted; CSMS identity is verified

Security Profile 3: TLS with Client-Side Certificates

Security Profile 3 provides mutual TLS (mTLS) authentication. Both the charger and the CSMS present and validate X.509 certificates, providing the strongest available authentication.

• Transport: Encrypted WebSocket (wss://) with mutual TLS
• Authentication: Client certificate (charger) + server certificate (CSMS)
• Certificate management: Requires PKI infrastructure for provisioning, rotating, and revoking charger certificates
• Use case: High-security deployments, public charging infrastructure, compliance-driven environments
• Advantage: Eliminates password-based vulnerabilities; cryptographic identity verification for both endpoints

Additionally, OCPP 2.0.1 mandates signed firmware updates. The charger validates the cryptographic signature of firmware binaries before installation, preventing malicious firmware injection --- a critical concern for internet-connected devices on public infrastructure.

Smart Charging with OCPP

Smart charging is one of OCPP's most important features. It enables dynamic power management across a charging site, balancing grid constraints, energy costs, renewable availability, and vehicle needs.

How SetChargingProfile Works

A charging profile defines a power or current limit over time. The CSMS sends a SetChargingProfile message to the charger containing:

• Stack level: Priority of this profile (higher levels override lower ones)
• Charging profile purpose: ChargePointMaxProfile (site-level limit), TxDefaultProfile (default for new transactions), or TxProfile (specific to an active transaction)
• Charging schedule: A time-based series of power or current limits

Example: A site with 150 kW of available grid capacity and 4 DC fast chargers can use ChargePointMaxProfile to distribute power dynamically. When one charger is idle, the others can draw more. When all four are active, each gets 37.5 kW. When grid load peaks, the CSMS can reduce the site limit to 100 kW, and the charger recalculates the composite schedule.

In OCPP 1.6, charging profiles operate at the connector level with a simple stack. In OCPP 2.0.1, the system is significantly more capable:

• EVSE-level and station-level profiles: Apply limits at different points in the hierarchy
• Composite schedule calculation: The charger computes the effective limit from all active profiles, and the CSMS can query this composite via GetCompositeSchedule
• External limits: The charger can report constraints from an external energy management system via NotifyChargingLimit
• Absolute and relative schedules: Profiles can be tied to absolute timestamps or relative to transaction start

Smart charging is essential for fleet depot charging, workplace charging, and residential multi-unit installations where grid capacity is shared.

Who Uses OCPP?

OCPP adoption spans the entire EV charging value chain.

Charge Point Operators (CPOs)

CPOs deploy and manage physical charging infrastructure. Major CPOs running OCPP-connected networks include:

• ChargePoint (North America, Europe) --- operates one of the largest OCPP-connected networks globally
• Fastned (Europe) --- high-power fast charging along highways
• EVgo (United States) --- fast charging network with over 950 locations
• Allego (Europe) --- pan-European charging network
• Shell Recharge / Ubitricity (Global) --- leveraging OCPP to unify charger management across acquired brands
• bp pulse (Europe, North America) --- rapidly expanding OCPP-connected infrastructure

CSMS Vendors

Software companies building charging station management systems that communicate with chargers via OCPP:

• Driivz (acquired by Vontier)
• EVConnect
• AMPECO
• Current
• EV.energy
• Open Charge Point (open-source)

Charger Manufacturers

Hardware manufacturers shipping OCPP-compliant chargers:

• ABB E-mobility --- DC fast chargers (Terra series)
• Schneider Electric --- AC and DC chargers for commercial deployments
• EVBox --- residential and commercial AC chargers
• Wallbox --- residential and small commercial chargers
• Alfen --- smart AC chargers popular in the Netherlands
• Tritium --- high-power DC fast chargers
• Kempower --- modular DC fast charging systems
• Autel Energy --- AC and DC chargers for North American market
• BTC Power --- DC fast chargers for fleet and public deployments

Energy Companies and Utilities

Utilities integrating EV charging into grid management strategies use OCPP's smart charging capabilities to implement demand response, time-of-use optimization, and vehicle-to-grid (V2G) programs. Companies like Enel X, E.ON, and Engie are active participants in the OCPP ecosystem.

OCPP vs OCPI vs OICP: EV Charging Protocols Compared

OCPP is one of several open protocols in the EV charging ecosystem. Each serves a different purpose.

OCPP operates between the charger and the backend. It handles "make the charger do things" --- start charging, report meter values, update firmware.

OCPI operates between charging networks. It handles "let an eMSP customer use a CPO's charger" --- roaming, real-time location data, tariff information, and CDR (Charge Detail Record) exchange. If OCPP is the protocol inside a network, OCPI is the protocol between networks.

OICP serves a similar roaming purpose to OCPI but uses a centralized hub model (Hubject) rather than peer-to-peer connections. It is dominant in Germany and parts of Central Europe.

ISO 15118 operates between the vehicle and the charger (below OCPP in the stack). It enables Plug & Charge authentication and communicates the vehicle's charging requirements. OCPP 2.0.1 has specific messages to relay ISO 15118 data between the charger and CSMS.

How to Test OCPP Implementations

Testing OCPP is inherently complex. The specification defines hundreds of message flows, error scenarios, and state transitions that must work correctly across different network conditions. For a comprehensive testing approach, see our OCPP testing guide and EV charger testing guide.

Challenges of Physical Testing

Testing with real hardware is slow and expensive:

• A single DC fast charger costs $30,000--$150,000
• Testing requires physical EV connectors, power supplies, and often actual vehicles
• Reproducing edge cases (network drops mid-transaction, firmware corruption, concurrent sessions) is difficult with physical equipment
• Test cycles with hardware typically take weeks to months

Simulation-Based Testing

OCPPLab provides cloud-based OCPP simulation that eliminates these constraints:

• Scale: Deploy 1,000+ virtual charge points in minutes, simulating an entire charging network
• Protocol coverage: Test both OCPP 1.6 and 2.0.1 with full message type support
• Realistic behavior: Simulate real charger behaviors from 100+ device models, including vendor-specific quirks and timing characteristics
• Edge case testing: Simulate network failures, malformed messages, slow responses, concurrent operations, and protocol error conditions that are nearly impossible to reproduce with hardware
• CI/CD integration: Automate regression testing as part of your development pipeline
• Smart charging validation: Test complex charging profile scenarios, composite schedule calculations, and load management algorithms

Teams using OCPPLab typically reduce OCPP QA cycles from months to weeks and cut testing infrastructure costs by 60--90%.

OCPP Certification and Compliance

The Open Charge Alliance operates an OCPP certification program that validates conformance to the specification. Certification involves:

1. Self-testing: Vendors run the OCA's test tool against their implementation
2. Conformance testing: An accredited test lab executes the official test suite
3. Interoperability testing: The implementation is tested against other certified products

Certified products are listed in the OCA's product directory. While certification is not legally required in most jurisdictions, many RFPs and government funding programs require or strongly prefer OCA-certified products. The EU's Alternative Fuels Infrastructure Regulation (AFIR) references OCPP as the communication standard for publicly accessible charging points.

Frequently Asked Questions

Is OCPP free to use?

Yes. OCPP is an open protocol published by the Open Charge Alliance under royalty-free terms. Anyone can download the specification and implement it without licensing fees. The specification documents are freely available on the OCA website. Certification is optional and involves a fee, but implementing the protocol itself costs nothing.

What is the difference between OCPP and OCPI?

OCPP handles communication between a charger and its management backend (CSMS) --- operations like starting charging sessions, reporting energy usage, and updating firmware. OCPI handles communication between different charging networks for roaming, allowing an EV driver subscribed to one network to use chargers on another. OCPP operates inside a network; OCPI operates between networks.

Do all EV chargers support OCPP?

Most commercial EV chargers sold today support OCPP 1.6 at minimum. Tesla Superchargers historically used a proprietary protocol, but Tesla has begun adopting OCPP for its chargers that serve non-Tesla vehicles as part of NEVI-funded deployments. Some low-cost residential chargers may lack OCPP support since they are designed for standalone operation without backend management.

What is a CSMS?

A CSMS (Charging Station Management System) is the backend software platform that manages a network of EV chargers via OCPP. It handles user authorization, session management, billing, energy monitoring, remote operations, firmware updates, and analytics. Also referred to as CPMS (Charge Point Management System) or simply "the backend." The term CSMS is used in OCPP 2.0.1, while OCPP 1.6 uses "Central System."

Which OCPP version should I implement?

If you are starting a new implementation in 2025, support both OCPP 1.6 and 2.0.1. Most chargers in the field still run 1.6, so your CSMS needs 1.6 support for backward compatibility. However, new charger models increasingly ship with 2.0.1 support, and features like ISO 15118 Plug & Charge, advanced security profiles, and the structured device model require 2.0.1. For a detailed comparison, see our OCPP 1.6 vs 2.0.1 analysis.

How does OCPP handle offline charging?

OCPP supports offline operation through the Local Authorization List. The CSMS pushes a list of authorized ID tags to the charger via SendLocalList. When the charger loses its WebSocket connection, it can still authorize users against this local list and start charging sessions. Transaction data (meter values, start/stop events) is queued locally and transmitted to the CSMS when connectivity is restored. OCPP 2.0.1 improves this with its event-based transaction model, which handles message loss more gracefully than 1.6's paired start/stop messages.

Is OCPP secure?

OCPP 1.6 has minimal built-in security --- TLS is optional, and many deployments run unencrypted. OCPP 2.0.1 significantly improves security with three mandatory security profiles (basic auth, TLS with server cert, mutual TLS), signed firmware updates, and security event logging. For production deployments, Security Profile 2 (TLS with basic auth) is the practical minimum, and Security Profile 3 (mutual TLS) is recommended for public infrastructure.

What is the OCPP heartbeat?

The Heartbeat message is a lightweight keep-alive sent by the charger to the CSMS at a regular interval (configured in the BootNotification response, typically 30--300 seconds). It serves two purposes: confirming that the charger is online and connected, and synchronizing the charger's internal clock with the CSMS server time (the Heartbeat response includes the current UTC timestamp). If the CSMS stops receiving heartbeats, it marks the charger as offline.

Can OCPP support vehicle-to-grid (V2G)?

OCPP 2.0.1 includes foundational support for V2G through its ISO 15118 integration. The NotifyEVChargingNeeds message can communicate bidirectional power flow requirements, and charging profiles can specify negative power values for energy export back to the grid. Full V2G orchestration typically requires additional protocols (like OpenADR for demand response signals), but OCPP 2.0.1 provides the charger-to-backend communication layer needed to participate in V2G programs.

What happens when OCPP messages fail?

When a message fails (timeout, network error, or CallError response), the behavior depends on the message type. Critical messages like StartTransaction and StopTransaction in OCPP 1.6 are queued and retried until delivered. In OCPP 2.0.1, the TransactionEvent message with its sequence numbering ensures no transaction data is lost even if individual messages fail. The CSMS can detect gaps in the sequence and request retransmission. For a complete guide to error handling, see our OCPP error codes reference.