The Protocol Stack Problem: Why Multi-Protocol Compliance Is an Architecture Decision, Not a Checklist

Abstract

EV charging platforms face a multi-protocol compliance challenge that most organizations underestimate. Open Charge Point Protocol (OCPP), OpenADR, IEEE 2030.5, and ISO 15118 are no longer optional add-ons — regulations in the US, EU, and UK increasingly mandate all four. Yet most Charge Point Operators (CPOs) and e-Mobility Service Providers (eMSPs) still treat each protocol as a standalone integration project. This paper argues that multi-protocol compliance is fundamentally an architecture decision. Organizations that design a unified protocol layer gain speed-to-market, lower certification costs, and multi-market access. Those that bolt on protocols incrementally accumulate integration debt that compounds with every new regulatory deadline. The paper maps the protocol requirements across three jurisdictions, identifies the architectural patterns that separate scalable platforms from fragile ones, and outlines a practical path from single-protocol dependency to multi-protocol readiness.

Executive Summary

Four EV charging communication protocols now define market access across three major jurisdictions. OCPP governs charger-to-backend communication. OpenADR enables demand response participation. IEEE 2030.5 handles grid-facing DER coordination. ISO 15118 manages the vehicle-to-charger interface, including Plug & Charge and bidirectional power transfer.

No single protocol covers the full stack. And no major market requires just one.

In the US, FERC Order 2222 opens wholesale markets to EVs as distributed energy resources (DERs), California Rule 21 mandates IEEE 2030.5 for Vehicle-to-Grid (V2G) interconnection, and the National Electric Vehicle Infrastructure (NEVI) program sets baseline interoperability requirements. In the EU, the Alternative Fuels Infrastructure Regulation (AFIR) mandates data transparency, while the proposed Network Code on Demand Response will formalize EV flexibility participation. In the UK, Smart Charge Point Regulations require grid flexibility capabilities alongside OCPP connectivity.

The common approach (implementing each protocol as a separate project with its own team, data model, and security infrastructure) creates compounding complexity. Each new protocol addition multiplies integration points rather than extending a shared foundation. The result is longer certification timelines, higher maintenance costs, and slower response to new regulatory requirements.

The alternative is a unified protocol architecture: a common abstraction layer, shared event bus, and harmonized security profiles that allow new protocols to plug into an existing foundation. Organizations that have taken this approach, including those using pre-built protocol accelerators, report certification timelines measured in weeks rather than months.

This paper examines the protocol landscape, maps requirements by jurisdiction, and provides a practical framework for making the architecture decision that will define your platform’s regulatory agility for the next decade.

The Multi-Protocol Reality for EV Charging Platforms

Five years ago, building an EV charging platform meant implementing one protocol: OCPP. A charger-to-backend connection, a transaction handler, and a management dashboard covered the operational basics. That era is over.

Today, a charging platform that wants to operate across major markets needs to speak four distinct protocol languages, each governed by a different standards body, each addressing a different layer of the energy ecosystem, and each increasingly mandated by regulation.

OCPP (Open Charge Point Protocol) remains the foundation. It governs all communication between the charging station and the backend Charging Station Management System (CSMS) — session management, firmware updates, smart charging profiles, and diagnostics. With OCPP 2.1 now designated as IEC 63584-210:2025, it has moved from an industry convention to an international standard. The OCPP market is projected to reach $1.47 billion at a 22.8% CAGR, according to recent market analysis. Procurement processes and public tenders are beginning to reference the IEC designation rather than the Open Charge Alliance (OCA) specification alone.

OpenADR (Open Automated Demand Response) handles the grid-facing demand response interface. When a utility or grid operator sends a curtailment signal, the charging platform needs to receive, interpret, and execute that instruction across its charger fleet. The OpenADR Alliance has recently announced the first certified OpenADR 3.0 products from E.ON, EVoke, and Universal Devices — but the 3.1 specification introduces breaking changes from 3.0, creating an immediate migration challenge for early adopters.

IEEE 2030.5 governs DER communication with the grid. In V2G scenarios, where EVs export energy back to the grid, IEEE 2030.5 (often implemented via the Common Smart Inverter Profile, or CSIP) is the protocol DSOs and utilities require for interconnection approval. California Rule 21 already mandates it for DER interconnection. Hawaii and Utah have parallel requirements, and more states are expected to follow.

ISO 15118 sits at the vehicle-to-charger interface. It enables Plug & Charge authentication (eliminating the need for RFID cards or mobile apps) and, in its 15118-20 revision, governs bidirectional power transfer for V2G transactions. Without ISO 15118, a platform cannot support the vehicle-side handshake that makes V2G technically possible.

The forcing functions behind this multi-protocol reality are regulatory, not theoretical. FERC Order 2222 opens US wholesale energy markets to DER aggregations that include EVs. The EU’s Alternative Fuels Infrastructure Regulation (AFIR, 2023/1804) mandates data transparency requirements that effectively require OCPP 2.0.1 or later for the data granularity required. The UK Smart Charge Point Regulations (SCPR) mandate default off-peak charging and grid flexibility capabilities. And the European Commission’s forthcoming Network Code on Demand Response — proposed by ACER in March 2025 — will formalize EV participation in harmonized demand response programs across member states.

Each of these regulations translates into a protocol implementation requirement. And the protocols are stacking up.

Three Protocol Stacks, Three Market Access Gates

The four EV charging protocols do not apply uniformly everywhere. Each major jurisdiction has assembled its own protocol stack: a specific combination of standards required for full market participation. Understanding which protocols are mandatory, recommended, or emerging in each market is the first step toward an informed architecture decision.

The US Stack is the most fragmented. OCPP 2.0.1 serves as the charger management baseline, with NEVI program requirements reinforcing interoperability and uptime reporting mandates. IEEE 2030.5 with CSIP is required in California under Rule 21 for any DER — including V2G-capable chargers — seeking grid interconnection approval. OpenADR is the dominant demand response protocol across California and is gaining traction in PJM, CAISO, and NYISO territories as FERC Order 2222 implementation accelerates state by state. ISO 15118 is required for Plug & Charge functionality and V2G vehicle-side communication. The complication: each state, and often each ISO/RTO region, has its own implementation timeline and technical requirements. ERCOT operates separately from FERC jurisdiction entirely.

The EU Stack centers on AFIR compliance. AFIR Article 5 requires real-time data transparency — pricing, availability, and connector status — which in practice demands OCPP 2.0.1 or later for the data granularity required. The proposed EU Network Code on Demand Response will mandate harmonized DR participation for connected assets, including EV chargers, with national enforcement expected by 2027. This will require an OpenADR or EEBUS-compatible demand response interface. ISO 15118 is driven by automotive OEM adoption across European markets. National implementations vary: Germany, France, the Netherlands, and the Nordic countries are at different stages of AFIR transposition, creating a patchwork of compliance deadlines.

The UK Stack is shaped by the Smart Charge Point Regulations (SCPR) 2021 and subsequent amendments through 2025. SCPR mandates that all private charge points sold in the UK must support smart functionality — including default off-peak charging, randomized delay, and the ability to respond to grid flexibility signals. This requires OCPP for charger management plus an OpenADR or Open Smart Charging Protocol (OSCP) interface for grid flexibility participation. The UK’s grid flexibility framework is evolving rapidly, with the National Grid ESO actively expanding DER participation pathways that will likely require IEEE 2030.5 for V2G scenarios.

The protocol-to-market matrix below captures the current landscape:

Protocol	United States	European Union	United Kingdom
OCPP 2.0.1+	Status: Required (NEVI baseline, IEC 63584-210:2025 in tenders) Scope: Charger-to-backend management, session control, smart charging	Status: Required (AFIR Article 5 data transparency) Scope: Charger management, real-time pricing/availability reporting	Status: Required (SCPR smart functionality mandate) Scope: Charger management, off-peak defaults, randomized delay
OpenADR	Status: Required for DR participation (California, expanding via FERC 2222) Scope: Grid-facing demand response signaling and compliance reporting	Status: Emerging (EU NC DR, national transposition by 2027) Scope: Harmonized DR participation for connected EV chargers	Status: Recommended (grid flexibility framework, OSCP alternative) Scope: Grid flexibility signal reception and response
IEEE 2030.5	Status: Required for V2G/DER (California Rule 21, expanding to other states) Scope: DER grid interconnection, V2G authorization, smart inverter coordination	Status: Emerging (V2G pilots, no EU-wide mandate yet) Scope: DER communication for V2G scenarios	Status: Emerging (National Grid ESO DER pathways) Scope: V2G grid interconnection and DER participation
ISO 15118	Status: Required for Plug & Charge and V2G vehicle-side Scope: Vehicle-to-charger authentication, bidirectional power transfer (15118-20)	Status: Driven by automotive OEM adoption Scope: Plug & Charge, V2G vehicle-side communication	Status: Driven by automotive OEM adoption Scope: Plug & Charge, V2G vehicle-side communication

The critical insight from this mapping is that no single protocol provides full market access in any jurisdiction. A platform built exclusively on OCPP can manage chargers, but it cannot participate in demand response programs, cannot achieve V2G interconnection approval, and cannot enable Plug & Charge. Each missing protocol is a closed market gate.

For organizations operating across jurisdictions (European CPOs expanding into the US market, or US eMSPs scaling into the UK), the protocol requirements compound. The real question is how you architect for multiple protocols, because the protocols themselves are non-negotiable.

Attribute	OCPP	OpenADR	IEEE 2030.5	ISO 15118
Scope	Function: Charger-to-backend communication	Function: Grid-facing demand response signaling	Function: DER-to-grid communication	Function: Vehicle-to-charger interface
Governing Body	Organization: Open Charge Alliance (OCA) / IEC	Organization: OpenADR Alliance	Organization: IEEE Standards Association	Organization: ISO / IEC
Current Version	Version: 2.0.1 (IEC 63584-210:2025); 2.1 emerging	Version: 3.0 (first certifications 2026); 3.1 in development	Version: IEEE 2030.5-2018 (CSIP for DER)	Version: ISO 15118-20:2022 (bidirectional)
Transport	Protocol: WebSocket (JSON/SOAP)	Protocol: REST/HTTP (3.x); XML/HTTP (2.0b)	Protocol: RESTful HTTP over TLS	Protocol: PLC (HomePlug GreenPHY) / TLS
Data Model	Model: Charging station, connectors, transactions, Device Model (2.0.1+)	Model: Events, reports, opt-in/opt-out signals	Model: DER function sets, metering, pricing, control	Model: Vehicle identity, charging schedules, energy transfer
Security	Method: 3 security profiles (basic auth → mutual TLS with certificates)	Method: OAuth 2.0 (3.x); XML signatures + TLS (2.0b)	Method: Certificate-based mutual TLS (mandatory)	Method: TLS with certificate-based Plug & Charge

The Architecture Pitfall: Why Separate Protocol Projects Fail

The most common approach to multi-protocol compliance is also the most expensive in the long run: treat each protocol as a separate project.

The pattern is familiar. A CPO builds an OCPP backend to manage its charger fleet. Six months later, a utility partnership requires OpenADR for demand response participation. A different team (or a different vendor) implements a standalone OpenADR VEN. Then a V2G pilot demands IEEE 2030.5 for grid interconnection. Another project, another integration, another data model.

Each protocol implementation, built in isolation, makes architectural assumptions that conflict with the others. The OCPP backend models a charging session as a transaction between a charger and a driver. The OpenADR VEN models the same charger as a dispatchable load in a demand response event. The IEEE 2030.5 client models it as a DER with generation and consumption capabilities. Three representations of the same physical asset, maintained in three separate systems, synchronized through brittle point-to-point integrations.

This is the N×M problem. With N protocols and M integration points per protocol, total complexity grows multiplicatively. Adding a fourth protocol does not add 25% more work — it adds integration touchpoints with every existing system. Security credentials must be managed separately for each protocol’s TLS requirements. Event handling logic is duplicated: an OpenADR curtailment event and an OCPP smart charging profile may need to produce the same physical outcome at the charger, but the logic to translate between them sits in custom middleware that no one wants to maintain.

The compounding effects show up in three areas:

Certification timelines multiply. Each protocol certification tests against its own conformance suite. When protocols are implemented in silos, a change to the shared charging infrastructure (a firmware update, a security patch, a new charger model) can break certifications across multiple protocol stacks. Re-certification becomes a recurring cost, not a one-time event.

Operational visibility fragments. A demand response event arrives via OpenADR. The charging platform adjusts session power via OCPP. The grid interconnection reports updated DER status via IEEE 2030.5. If these three systems do not share a common event log and data model, diagnosing a failed DR event requires cross-referencing three separate audit trails. For a fleet of 10,000 chargers, this operational complexity is not merely inconvenient; it becomes a reliability liability.

Time-to-market for new requirements slows with each addition. The first protocol takes six months to implement. The second takes eight, because it must integrate with the first. The third takes twelve, because it must integrate with both predecessors while navigating the conflicts between their data models. One global technology solutions provider building a multi-protocol fleet management platform experienced this compounding effect firsthand — achieving multi-protocol support (OCPP, MODBUS, and ChargePoint API) for automated demand response required designing the platform for protocol diversity from the start, not bolting it on after the fact.

The architecture pitfall is seductive because each individual decision seems reasonable. “We only need OCPP right now.” “We will add OpenADR when we need it.” “IEEE 2030.5 is a future requirement.” Each statement may be true in isolation. But the cumulative cost of sequential, siloed protocol adoption far exceeds the upfront investment in a unified architecture.

The organizations that avoid this trap share a common characteristic: they made the architecture decision before the first protocol implementation, not after the third.

Designing a Unified Protocol Architecture

The alternative to siloed protocol projects is a platform architecture designed from the start to accommodate multiple protocols through shared infrastructure. This is not a theoretical exercise; it is a pattern already proven in production by organizations that have deployed multi-protocol charging and energy platforms at scale.

A unified protocol architecture rests on three foundational design principles.

A common abstraction layer sits between the protocol-specific adapters and the core business logic. Each protocol speaks its own language externally — OCPP messages, OpenADR event payloads, IEEE 2030.5 function sets — but internally, they all translate into a shared domain model. A charging station is represented once, with protocol-specific views derived from that single representation. When a new protocol is added, the team builds an adapter to the existing abstraction layer rather than a standalone system with its own data model.

In practice, this means a demand response curtailment event (whether it arrives via OpenADR, OSCP, or a direct utility API) translates into the same internal command structure that produces an OCPP SetChargingProfile message at the charger. The business logic (which chargers to curtail, by how much, with what priority) lives in one place and serves every protocol.

Event-driven cross-protocol orchestration replaces point-to-point integration. Rather than building direct bridges between OCPP and OpenADR, or between IEEE 2030.5 and the session manager, all protocol events publish to a shared event bus. A V2G discharge transaction, for example, involves IEEE 2030.5 (grid authorization), OCPP 2.1 Device Model (charger command), and ISO 15118-20 (vehicle-side power transfer). In a siloed architecture, orchestrating these three protocols requires custom middleware for each combination. In an event-driven architecture, each protocol adapter publishes and subscribes to domain events — GridAuthorizationGranted, DischargeSessionRequested, VehicleHandshakeComplete — and the orchestration emerges from the event flow rather than from hard-wired integrations.

Security profile harmonization addresses one of the most underestimated sources of multi-protocol complexity. OCPP 2.0.1 defines three security profiles with escalating TLS requirements. IEEE 2030.5 mandates certificate-based mutual authentication. OpenADR 3.x uses OAuth 2.0. Managing three separate certificate authorities, three credential stores, and three renewal cycles is operationally expensive and creates security gaps at the boundaries between systems. A unified architecture consolidates certificate management, TLS termination, and credential rotation into a shared security infrastructure that serves all protocol adapters.

These are not abstract principles. Codibly’s protocol accelerators — covering OCPP, OpenADR, IEEE 2030.5, and OCPI — share exactly this foundation: a Java/Spring codebase, event-driven architecture, and cloud-native deployment model. The accelerators were designed to work together from the start, which is why a pool equipment manufacturer achieved OpenADR 2.0b certification in six weeks using the OpenADR Accelerator, and a BESS provider achieved IEEE 2030.5 CSIP certification in eight weeks — timelines that would be impossible if each protocol required building from a blank foundation.

The same architectural pattern enabled a UK-based energy aggregator to scale a DER aggregation platform to 2,000 sites processing three billion data points at 1,000 requests per second. That throughput is achievable not because of any single protocol optimization, but because the shared event-driven infrastructure handles cross-protocol data flows without the bottlenecks of point-to-point integration.

For organizations evaluating their architecture options, the interoperability service and energy standards pages outline how these shared-foundation patterns translate into practical implementation engagements. The core trade-off is clear: invest in architecture now, or pay the compounding integration tax later.

The Regulatory Acceleration: Deadlines That Won’t Wait

The argument for a unified protocol architecture would be strong on engineering merits alone. But regulation is removing the luxury of incremental adoption. Compliance deadlines across all three jurisdictions are converging within a narrow window, and the standards themselves are still evolving, which means platforms must be architecturally ready to absorb changes, not just meet today’s requirements.

OCPP’s transition from industry convention to international standard is the most significant near-term shift. The designation of OCPP 2.1 as IEC 63584-210:2025 signals that procurement mandates and public tenders will increasingly reference the IEC standard rather than the OCA specification. For CPOs still operating on OCPP 1.6, this creates a migration imperative: 1.6 lacks the security profiles, Device Model, and transaction handling capabilities that 2.0.1 introduced, and OCPP 2.1 — with native V2G support — is already on the horizon. The migration from 1.6 to 2.0.1 is not a firmware update; it is an architecture change that affects backend data models, security infrastructure, and charger firmware coordination. Organizations that have not begun planning this migration are already behind.

OpenADR 3.1 introduces breaking changes from 3.0 — a reality that complicates adoption planning. The OpenADR Alliance announced the first certified 3.0 products in early 2026 from E.ON, EVoke, and Universal Devices. But the 3.1 specification, already under development, is not backwards compatible with 3.0. Organizations that invested in 3.0 implementations face a migration within a migration. For platforms built on siloed protocol architectures, this means two separate upgrade projects — one for 3.0 to 3.1, and one to maintain integration with the rest of the charging stack. For platforms with a unified architecture, it means updating a single protocol adapter while the rest of the system continues operating.

FERC Order 2222 implementation is creating a state-by-state patchwork across US wholesale markets. PJM, CAISO, and NYISO are leading implementation, each with different participation models, metering requirements, and communication protocol expectations for DER aggregations. ERCOT, operating outside FERC jurisdiction, has its own DR provider framework. A platform seeking to aggregate EV flexibility across multiple ISO/RTO regions must accommodate protocol variations at the regional level — a challenge that multiplies rapidly for organizations without a flexible protocol layer.

The EU Network Code on Demand Response, proposed by ACER to the European Commission in March 2025, will mandate harmonized DR participation rules across EU member states. National enforcement is expected by 2027. For EV charging platforms operating in Europe, this means that grid flexibility participation, currently a competitive differentiator, will become a compliance requirement. The protocol implementation to support this (OpenADR or EEBUS, depending on national transposition) needs to be in place before enforcement begins, not after.

The time-to-market calculation is unforgiving. Building a single protocol implementation from scratch typically takes an engineering team 12 to 18 months. Multiplied across four protocols, the sequential approach consumes years during which compliance deadlines pass and market access narrows. Pre-built protocol accelerators compress individual protocol deployments to 4 to 8 weeks. But the real acceleration comes from the shared architectural foundation: when the second, third, and fourth protocols plug into an existing abstraction layer and event bus, rather than starting from zero each time.

When Flux needed to validate bidirectional energy exchange between EVs and the grid, the V2X proof of concept required coordinating multiple protocol layers, a challenge that was tractable precisely because the platform architecture was designed for multi-protocol orchestration from the start. Similarly, when IMP PAN built a scalable OCPP server for a Horizon 2020 V2G research project spanning Poland, Denmark, and the Netherlands, the multi-country deployment demanded an architecture that could accommodate regional protocol variations without rebuilding the core platform.

The regulatory trajectory is clear: more protocols, more jurisdictions, shorter compliance windows. The architecture decision you make now determines whether each new requirement is an adapter you plug in or a project you start from scratch.

One Architecture Decision, Not Three Compliance Projects

The EV charging protocol landscape will only grow more complex. New protocol versions, new regulatory mandates, and new market participation models are arriving faster than most engineering organizations can absorb them through sequential, siloed implementation projects.

The organizations that will navigate this landscape successfully share a common trait: they recognized early that multi-protocol compliance is an architecture decision, not a series of independent compliance checkboxes. They invested in a common abstraction layer, event-driven orchestration, and shared security infrastructure before the second protocol was required, and that investment pays compounding returns with every protocol addition.

For CPOs and eMSPs evaluating their architecture today, the practical path forward involves three steps. First, audit your current protocol stack against the jurisdiction-specific requirements mapped in this paper. Identify which market access gates are closed and which are closing. Second, assess whether your existing architecture can accommodate new protocols through adapter addition or whether each new protocol requires a standalone integration project. If the answer is the latter, the architecture tax is already accumulating. Third, evaluate whether building that unified foundation internally — with all the protocol-specific expertise it demands — is the right use of your engineering capacity, or whether pre-built protocol accelerators and interoperability services can establish the architectural foundation in weeks rather than months, freeing your team to focus on the features that differentiate your platform.

The regulatory deadlines mapped in this paper are not aspirational targets. They are compliance clocks. The architecture decision you make now determines whether your platform meets them with confidence or scrambles to catch up.

For a deeper exploration of the topics covered in this paper, see the companion articles in this series: the OCPP 1.6 to 2.0.1 migration path, V2G standards readiness for fleet operators and DSOs, and the regulatory-to-protocol implementation mapping for CPOs operating across jurisdictions. For a broader perspective on interoperability as a strategic imperative across the energy transition, read The Interoperability Imperative.