What is OCPP? Open Charge Point Protocol Explained (2026)

Quick answer: OCPP (Open Charge Point Protocol) is an open WebSocket-based protocol from the Open Charge Alliance that lets EV chargers communicate with a backend platform (a CPMS). It standardizes how a charger registers, authorizes users, runs transactions, reports meter values, and applies smart charging — across vendors. The main production versions are OCPP 1.6 (the most widely deployed) and OCPP 2.0.1 (the modern standard with mandatory security profiles, a device model, and ISO 15118 support). OCPP 2.1, published in 2025, is the latest version and adds bidirectional charging (V2X).

OCPP (Open Charge Point Protocol) is the standard that lets EV chargers communicate with a backend platform — the Central System in OCPP 1.6, the CSMS (Charging Station Management System) in OCPP 2.0.1. Operators often call that backend a CPMS (Charge Point Management System); that expansion is industry slang, not the 2.0.1 spec term. 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 2024, the Open Charge Alliance counts more than 400 member organizations worldwide, and every major charger manufacturer --- ABB, Schneider Electric, EVBox, Wallbox, Alfen, Tritium, Kempower, and Autel --- ships hardware with OCPP support built in. The specifications themselves run to several hundred pages: per the OCPP specification published by the OCA, OCPP 1.6 Edition 2 defines 28 unique core actions (10 charger-initiated, 19 CPMS-initiated counting DataTransfer once) plus 11 more in the Security Whitepaper edition 2, while OCPP 2.0.1 reorganizes and substantially expands the message set across 16 functional blocks (labelled A through P), covering many more messages than 1.6.

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

Why Does OCPP Exist?

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 CPMS 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 (OCA), founded in 2014 in the Netherlands, created OCPP to solve these problems with a single, open, royalty-free standard. The specifications are freely available from the OCA at openchargealliance.org/protocols/open-charge-point-protocol. 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 Does OCPP Work?

OCPP operates on a client-server architecture where the charge point (the physical charger) acts as the client and the CPMS 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 CPMS hostname and establishes a TCP connection to the configured endpoint (typically wss://CPMS.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 CPMS 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": "Emulator"}]

• 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", "FormatViolation", "Invalid payload", {}]

• 4 = Message type (CallError)
• Standard error codes like NotImplemented, NotSupported, InternalError, ProtocolError, SecurityError, and FormatViolation (OCPP 2.0.1 and 2.1; OCPP 1.6 calls it 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 emulators compared.

OCPP 1.6

Released in 2015, OCPP 1.6 remains the most widely deployed version in the field by a wide margin. 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 core defines 28 unique actions split between charger-initiated and CPMS-initiated operations (with DataTransfer going in both directions). The optional Security Whitepaper edition 2 extension adds 11 more — signed firmware, certificate management, log upload, and SecurityEventNotification — for a total of about 39 when both are implemented.

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 many more messages than 1.6, organized into 16 functional blocks spanning provisioning, security, transactions, smart charging, and ISO 15118.

OCPP 1.6 vs 2.0.1: What's the Difference?

OCPP Message Types: Complete Reference

OCPP 1.6 Messages

Charger-initiated (Charge Point to CPMS):

CPMS-initiated (CPMS 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:

What Are the 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 CPMS 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 CPMS server certificate
• Use case: Production deployments where client certificate management is not feasible
• Advantage: All traffic is encrypted; CPMS identity is verified

Security Profile 3: TLS with Client-Side Certificates

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

• Transport: Encrypted WebSocket (wss://) with mutual TLS
• Authentication: Client certificate (charger) + server certificate (CPMS)
• 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.

How Does Smart Charging Work 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 CPMS sends a SetChargingProfile message to the charger containing:

• Stack level: Priority of this profile (higher levels override lower ones)
• Charging profile purpose (OCPP 1.6): ChargePointMaxProfile (charge-point limit), TxDefaultProfile (default for new transactions), or TxProfile (specific to an active transaction)
• Charging profile purpose (OCPP 2.0.1): ChargingStationMaxProfile, ChargingStationExternalConstraints, TxDefaultProfile, or TxProfile — there is no ChargePointMaxProfile in 2.0.1
• 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 an OCPP 1.6 ChargePointMaxProfile (or an OCPP 2.0.1 ChargingStationMaxProfile) 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 CPMS 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) --- one of the largest public fast-charging networks in the U.S.
• 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

CPMS 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: How Do They Compare?

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 CPMS.

How Do You 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 networked DC fast charger is a major capital purchase, and grid upgrades, trenching, and permitting push the installed cost far higher
• 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: Run many virtual charge points at once to load test your CSMS without buying hardware
• Protocol coverage: Test OCPP 1.6, 2.0.1 and 2.1 chargers against the same backend
• Realistic behavior: Simulate charger models from a catalog of real brands, including vendor-specific behavior and timing
• 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

Because virtual chargers run on demand, you can run the same OCPP scenarios on every release instead of waiting for lab hardware.

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 (CPMS) --- 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? What about CPMS?

A CSMS (Charging Station Management System) is the OCPP 2.0.1 name for the backend that manages chargers over OCPP. OCPP 1.6 calls the same role Central System. CPMS (Charge Point Management System) is industry slang for that backend — it is not the 2.0.1 spec acronym, and it does not expand to Charging Station Management System. The backend handles authorization, sessions, billing, energy monitoring, remote operations, firmware updates, and analytics.

Which OCPP version should I implement?

If you are starting a new implementation in 2026, support both OCPP 1.6 and 2.0.1. Most chargers in the field still run 1.6, so your CSMS needs 1.6 for backward compatibility. New charger models increasingly ship 2.0.1, and features like ISO 15118 Plug & Charge, mandatory security profiles, and the device model require 2.0.1. OCPP 2.1 is a published spec (2025); OCPPLab does not implement it. The 1.6 and 2.0.1 versions differ substantially in security, device modeling, and transaction handling.

How does OCPP handle offline charging?

OCPP supports offline operation through the Local Authorization List. The CPMS 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 CPMS 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?

Core OCPP 1.6 has minimal built-in security --- TLS is optional, and many deployments run unencrypted. The optional OCPP 1.6 Security Whitepaper edition 2 retroactively adds security profiles 1, 2 and 3, certificate management, signed firmware updates, and SecurityEventNotification to 1.6, but it is opt-in per deployment, so a large portion of the installed base still runs without it. OCPP 2.0.1 makes the same profile model, with the same Profile 1/2/3 numbering, part of the core spec and bakes signed firmware and security event logging into the core spec. 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 CPMS 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 CPMS server time (the Heartbeat response includes the current UTC timestamp). If the CPMS stops receiving heartbeats, it marks the charger as offline.

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

OCPP 2.0.1 includes foundational ISO 15118 integration (NotifyEVChargingNeeds, charging profiles that can carry negative power). OCPP 2.1 (published 2025) is the OCA spec aimed at ISO 15118-20 bidirectional / V2G workflows. OCPPLab covers OCPP 1.6, 2.0.1 and 2.1, so you can run 2.1 virtual chargers against your CSMS. Full V2G orchestration typically also needs grid-side protocols such as OpenADR.

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 carries a per-transaction seqNo and the Charging Station replays queued offline events in order on reconnect, so the CPMS can detect gaps and reconstruct the full transaction without losing data. (OCPP 2.0.1 does not define an explicit retransmission request — gap recovery relies on the Charging Station's offline message queue.) For a complete guide to error handling, see our OCPP error codes reference.

Related reading

• What is a CSMS? — Charging Station Management System vs CPMS software
• OCPP 1.6 testing and OCPP 2.0.1 testing
• OCPP emulator — virtual charge points without hardware
• Platform features and pricing
• OCPPLab docs — actions, test cases, and operator guides