OCPP 2.1 Explained: V2G, Battery Energy Storage, and What Implementers Are Learning

Release Recap (Jan 23, 2025) and What 2.1 Added

On January 23, 2025, the Open Charge Alliance officially put out OCPP 2.1. The International Electrotechnical Commission also took it on as IEC 63584-210.

OCPP 2.1 V2G features brought a hard break from 1.6. The shift changed how devices were modeled, how transactions were handled, and how security was layered in. Many teams found that transition difficult.

OCPP 2.1 V2G features are different. Built directly on top of 2.0.1, the three-tier Device Model, the message structures, and the security profiles all stay in place. What 2.1 adds sits on top of that base without disturbing it.

The additions are substantial. The spec covers over 377 pages of errata and new use-case sections. The main areas of change are:

• Native support for ISO 15118-20: ISO 15118-20 is the vehicle-to-everything standard. Energy can now flow in both directions between the vehicle and the grid, the home, or a building.
• Distributed Energy Resource controls: Charging stations can now pick up and act on signals from utility systems in real time. This covers frequency response, reactive power adjustment, and ramp-rate controls.
• Offline payment and local cost calculation: Stations can now work out session costs and take payments without any backend connection. This covers prepaid limits, card terminals, and dynamic QR codes.
• Transaction continuity after reboot: Sessions can now pick back up cleanly after a forced hardware reset. This was a long-standing operational problem.
• Battery swap support: There is now built-in support for swap-based setups, mainly aimed at two- and three-wheelers.
• Real-time pricing and phase-level power control: Stations can pick up and act on time-of-use tariff schedules and adjust power delivery at the individual phase level.

V2G Functional Block: How OCPP 2.1 Works with ISO 15118-20

The most significant technical change in OCPP 2.1 V2G features is how the protocol handles Vehicle-to-Everything. Before this OCPP 2.1 release, bidirectional charging was largely proprietary.

Teams added custom extensions to OCPP 1.6 or fell back on CHAdeMO standards. There was no uniform way to carry this out across different hardware and software stacks.

OCPP 2.1 changes this by folding native support for ISO 15118-20 directly into the protocol. This gives every participant in the charging chain, from the vehicle to the station to the management system, a common, cryptographically secure way to handle bidirectional energy flows.

On the security side:

• The protocol supports putting OEM root certificates directly into the charging station.
• Larger certificate chains are handled without issue, and Certificate Revocation Lists are processed automatically.
• A single vehicle can hold separate digital identities for mobility services and grid services. This matters for fleet setups where a vehicle may be buying energy for travel at one point and selling energy back to the grid at another.

What does OCPP 2.1 V2G Features Bring to Managing Energy Discharge:

The OCPP 2.1 V2G features bring in five distinct control modes for managing how energy flows:

1. ChargingOnly: The default state. The station runs as a standard unidirectional charger and ignores any commands to send energy back. This keeps compatibility with older vehicles.
2. ExternalLimits: An outside party such as a utility controller sets the upper and lower power boundaries. The central system can read these limits but does not set the precise power curve.
3. Central or External Setpoint: The central system or a local controller sends a specific power target. Positive values mean the station is pulling energy in. Negative values mean the station is pushing energy out.
4. Central or Local Frequency: The vehicle responds to grid frequency changes on its own. Droop curves come from the central system, or the station reads the local AC frequency directly to counter grid imbalances in real time.
5. Idle: The vehicle drops into an energy-saving state without ending the active session. The station can bring it back instantly when needed, which cuts out unnecessary battery drain during long stops.

Because the vehicle has no direct link to the local grid operator, the charging station steps in as an edge proxy. The station picks up grid parameters via OCPP and converts them into ISO 15118-20 format before passing them down to the vehicle. 

Battery Energy Storage System (BESS) Controls

OCPP 2.1 V2G features are set up to handle both the vehicle's internal battery as a short-term storage node and a permanent stationary battery sitting alongside a fast-charging unit to absorb peak demand.

The OCPP 2.1 V2G features draw on the expanded Device Model from 2.0.1 to map the physical attributes of a battery system into logical variables that the management system can read and write. In OCPP 1.6, the battery gave back very little data. In 2.1, individual parts, including separate power converter modules, can each be picked out by their own standardized names.

The main data variables available for storage control are:

• State of charge: Shown as a decimal percentage of the nominal operating range.
• Maximum charge limit: The upper boundary the system can set to look after battery chemistry over time.
• Bulk state of charge: The level up to which fast, non-linear charging is allowed. Once the battery hits this point, the controller must taper the power curve to avoid heat damage.
• Phase-level current readings: The central system can read root-mean-square current across individual phases. This is important for catching phase imbalances when a storage system is sending energy back to stabilize a local multi-phase grid.

Energy arbitrage is a central use case here. Storing energy when grid prices are low and releasing it when prices go up is the economic basis of most BESS setups. OCPP 2.1 V2G features support this by working with structured tariff models that tie in with roaming protocols like the Open Charge Point Interface. The management system can send time-of-use or real-time pricing schedules directly to the local battery controller.

In a practical scenario:

1. A local energy management system looks after both a stationary battery and a bank of chargers.
2. The utility tariff goes up sharply.
3. The system cuts off grid import and switches the battery to release energy into the vehicles.
4. Service carries on without picking up demand charge penalties.

Every energy movement is logged via signed meter values, keeping everything auditable under metering laws.

DER (Distributed Energy Resources) Controls

Utility regulators now put high-capacity charging stations in the same category as commercial solar arrays or grid-scale battery farms. This means they must meet compliance requirements and take on grid-stabilization duties.

Utilities typically use protocols like IEEE 2030.5, IEC 61850, or OpenADR 3.0 to manage distributed resources. OCPP 2.1 V2G features act as a translation layer between these utility protocols and the charging station.

A management system or an on-site proxy controller picks up signals from the grid operator via IEEE 2030.5 and turns them into OCPP commands the station can act on straight away.

The specific control options this opens up include:

• Power factor adjustment: The station's inverter can push in or pull out reactive power to stabilize local voltage levels, regardless of whether there is an active charging session.
• Frequency droop response: If grid frequency drops suddenly, the station can cut consumption or start releasing stored energy on its own, based on pre-set droop curves. This happens without waiting for a command from a cloud server, which takes slow response times out of the picture for primary frequency response.
• Ramp rates and soft-start protocols: When a grid event ends and chargers are ready to start up again, having thousands of them come back at the same moment would knock the grid over again. OCPP 2.1 V2G features allow for strict ramp rates and randomized restart delays to head this off.
• Granular fault reporting: Rather than sending generic error codes, the station can flag specific grid-side problems such as current imbalances, under-frequency events, or over-frequency events. This lets the central system tell apart a hardware fault in a single dispenser from a wider grid instability event and carry out the right response for each.

Backward Compatibility with 2.0.1

The move from OCPP 1.6 to 2.0.1 was notoriously difficult. Backward compatibility was dropped entirely. Networks that wanted to upgrade often had to run two separate IT setups side by side or swap out hardware that lacked the memory to handle the larger payloads and mandatory cryptography of the newer standard.

OCPP 2.1 V2G features take a fundamentally different path. Backward compatibility with 2.0.1 is a design principle, not an add-on. All application logic, variable structures, and baseline message routing built for 2.0.1 carry over fully into a 2.1 setup.

How the process plays out in practice:

1. A charging station boots up and connects to the management system.
2. The station puts forward its supported protocol versions via the WebSocket handshake header.
3. If both sides support 2.1, the connection runs on the advanced protocol and opens up V2G and DER functions.
4. If either side only goes up to 2.0.1, the system falls back to 2.0.1 with no extra steps needed.

New features in 2.1 come in through new use cases, new messages, or optional non-breaking fields added to existing 2.0.1 messages. New variables for bidirectional transfer or local payment terminals slot into the existing Device Model without touching the underlying database schema. Software stacks built for 2.0.1 only need small, modular updates rather than a full rewrite.

When to Skip 2.0.1 and Go Straight to 2.1

For hardware manufacturers and network architects still running OCPP 1.6, the question is whether to move to 2.0.1 first or jump straight to 2.1. The answer depends on deployment type, timeline, and primary business goals.

Going straight to 2.1 makes sense when:

• You are starting a new deployment or designing new hardware. Stopping at 2.0.1 builds up technical debt without adding meaningful benefit for most new builds.
• Your fleet includes commercial vehicles, school buses, or municipal service vehicles. Bidirectional charging can bring in upward of £320 per vehicle per year in markets like the UK. Since 2.0.1 has no built-in bidirectional blocks, getting to V2G on 2.0.1 means building custom overlays that reduce interoperability.
• Your sites are in areas with grid congestion or incoming DER mandates. The DER controls in 2.1 are quickly becoming a condition of operation, not an optional feature.
• You are building new backend systems. OCPP 1.6 runs on unencrypted WebSockets and has well-documented security gaps including man-in-the-middle attacks, remote code execution via malicious firmware, and session disruption. Moving to 2.1 directly closes those gaps without a second migration down the line.

Staying on or moving to 2.0.1 first makes sense when:

• You are bidding on government tenders that require certified compliance. Formal 2.1 certification is not expected until 2026. Certified 2.0.1 documentation is available today.
• Your procurement timeline cannot hold off for 2.1 firmware to settle down.

The most workable strategy for current procurement is to set 2.0.1 compliance as a contractual baseline, while legally requiring the vendor to follow through with a clear firmware upgrade path to 2.1 as soon as certification is available.

Implementation Lessons from the Field

Teams building on OCPP 2.1 V2G features have come across consistent patterns across engineering forums, open-source projects like the Linux Foundation's EVerest project, and developer communities. The lessons below reflect what is actually happening in production builds.

Break up your code structure early. The number of variables and use cases in OCPP 2.x makes a single-class codebase unworkable. Teams are splitting their codebases into separate functional blocks, such as Authorization, Security, Reservations, and Smart Charging. This makes each block testable on its own and easier to keep up as the spec moves forward.

Use the facade pattern to support both 2.0.1 and 2.1. A single interface to the shared logic lets both protocol versions run through a common gateway without copying large amounts of code. Many teams put 2.0.1 and 2.1 under a single namespace to keep them clearly separated from older 1.6 code. New 2.1 variables can be added to JSON configurations without touching the database.

Test the backend before buying hardware. The lack of good testing environments for 2.x has held teams back. Major emulator providers have not yet fully caught up with the new Device Model. Community-built tools have stepped in to fill the gap:

• Browser-based WebSocket simulators and JSON schema validators let teams test connection setup, transaction events, and heartbeat flows in real time.
• Tools like ocpptools.renozix.com and evlab.i4b.pl let engineers check schemas locally without giving away proprietary data.
• The general advice from the field is to hold off on buying physical hardware until the backend WebSocket server and message parsers have been fully tested against these virtual tools.

Set up a local proxy for home energy management and V2G. Direct communication between a cloud management system and a residential charger is often too slow for real-time grid balancing. Field guidelines from ElaadNL point to a local OCPP 2.1 controller sitting between the charger and the cloud. This local controller:

• Shows up as the management system from the charger's point of view.
• Shows up as the charger from the cloud's point of view.
• Picks up telemetry straight away, routes solar generation into the vehicle, and triggers energy release cycles based on live household loads, completely independent of internet latency.
• Still sends updates to the cloud system in the background for billing.