The Protocol Bridge: Translating OpenADR Signals into OCPP 2.0.1 Commands

Since January 8, 2026, every newly deployed or substantially upgraded public AC charging station in Europe must support ISO 15118 under the AFIR regulation. Existing stations are grandfathered, but the direction is clear: the new hardware entering the network carries smart charging capabilities, ad-hoc payment interfaces, and the digital rails that regulators demanded. With the 2027 DC fast charger retrofit deadline approaching, that compliant footprint will only grow.

But compliant hardware is only half the equation. The Network Code on Demand Response (NC DR) is expected to open flexibility markets across the EU in 2027, allowing distributed energy resources — including EV chargers — to participate in grid services. When that market opens, grid operators and aggregators will send demand response signals to every asset that can shift load. Those signals will arrive in OpenADR. Your chargers speak OCPP 2.0.1. And right now, most CPO platforms have no way to translate between the two.

This is the Protocol Bridge problem: the grid and the charger are speaking different languages, and without a translation layer, even the newest AFIR-compliant hardware will sit idle while flexibility revenue flows to competitors who built the bridge first.

Two Protocols, One Missing Conversation

OpenADR (Open Automated Demand Response) is the standard protocol for communicating demand response signals between grid operators, aggregators, and distributed resources. It carries event-based instructions: reduce consumption by a specific amount, during a specific window, at a specific price signal. OpenADR is the language of the grid.

OCPP (Open Charge Point Protocol) is the standard for communication between EV chargers and their backend management systems (CSMS). OCPP 2.0.1 handles session management, metering, authorization, and — critically — smart charging via the SetChargingProfile message. OCPP is the language of the charger.

These two protocols were designed for different domains. OpenADR emerged from the utility demand response world. OCPP emerged from the EV charging ecosystem. They share no message format, no event structure, and no native interoperability. A grid operator cannot send an OpenADR oadrDistributeEvent and expect a charger to understand it. A CSMS cannot generate a SetChargingProfile from thin air when it has never received a demand response signal.

The consequence: most CPO platforms today are deaf to the flexibility signals that will drive NC DR revenue. The chargers are physically capable of modulating their load. The software simply has no way to hear the request.

What the Protocol Bridge Actually Does

The Protocol Bridge is a software translation layer that sits between the OpenADR VEN/VTN (the grid-facing interface) and the OCPP backend (the charger-facing interface). Its job is straightforward in concept but precise in execution: receive an OpenADR event, interpret the signal, and generate the corresponding OCPP command.

Here is how a typical demand response event flows through the bridge:

1. Signal received. An aggregator or DSO sends an OpenADR oadrDistributeEvent to the VEN. The event specifies a target load reduction (e.g., reduce by 200 kW), a time window (14:00–16:00), and a signal level.
2. Signal interpreted. The bridge logic reads the event payload and maps the aggregate target to individual charging stations. If a site has 20 chargers drawing 10 kW each, the bridge calculates how to distribute the 200 kW reduction across available sessions — prioritizing vehicles with higher state of charge, longer remaining dwell time, or lower priority flags.
3. Command dispatched. The bridge generates OCPP SetChargingProfile messages for each affected charger, adjusting the ChargingSchedule to reduce or pause power delivery within the specified window.
4. Telemetry reported. As chargers execute the adjusted profiles, the bridge collects OCPP MeterValues and TransactionEvent data, aggregates it, and sends an OpenADR oadrCreatedEvent acknowledgment (and optionally oadrReport data) back to the aggregator to confirm compliance.

Bridge Step	OpenADR Side	Translation Logic	OCPP 2.0.1 Side
1. Receive	Message: oadrDistributeEvent Payload: Signal level, target kW reduction, time window, event ID	Action: Parse event payload; validate signal against site capacity and active sessions	—
2. Interpret	—	Action: Map aggregate kW target to individual chargers based on SoC, dwell time, session priority; calculate per-charger power limit	—
3. Dispatch	—	Action: Generate charging schedule for each affected EVSE	Message: SetChargingProfile Payload: ChargingSchedule with adjusted power limits per period
4. Report	Message: oadrCreatedEvent (acknowledgment) + oadrReport (telemetry) Payload: Actual kW delivered, compliance status	Action: Aggregate charger telemetry into grid-level report	Message: MeterValues + TransactionEvent Payload: Real-time energy, power, session status per EVSE

This four-step loop — receive, interpret, dispatch, report — runs continuously during an active demand response event. The bridge must handle overlapping events, partial opt-outs (vehicles that cannot be curtailed mid-session), and real-time adjustments if the grid signal changes.

Three Design Decisions for a Reliable Bridge

Building a Protocol Bridge that works in a lab demo is relatively simple. Building one that operates reliably across thousands of charge points, with real drivers and real grid signals, requires three architectural decisions that separate production-grade implementations from prototypes.

1. Stateful session awareness. The bridge must maintain a real-time model of every active charging session: vehicle state of charge, remaining energy demand, session priority, and driver preferences. Without this context, the bridge cannot make intelligent curtailment decisions. A naive implementation that evenly distributes load reduction across all chargers will curtail a vehicle at 15% SoC the same as one at 90% — a guaranteed driver complaint and a reliability risk.

2. Graceful degradation. Grid signals are not always perfectly formed, and network connections are not always reliable. The bridge must handle partial signal delivery, duplicate events, and communication interruptions between the VEN and the CSMS. If the OpenADR connection drops mid-event, the bridge should continue executing the last valid instruction rather than reverting all chargers to full power — which would spike demand precisely when the grid needs relief.

3. Bidirectional telemetry. The value of the Protocol Bridge extends beyond receiving grid commands. Aggregators and DSOs need real-time visibility into the flexibility a charging site can actually deliver. The bridge should continuously report available capacity (total connected load minus minimum delivery commitments) back through OpenADR telemetry, so the aggregator can dispatch accurately rather than guessing.

Capability	Prototype Bridge	Production-Grade Bridge
Session awareness	Approach: Even distribution — splits load reduction equally across all chargers regardless of session state	Approach: Stateful optimization — considers SoC, dwell time, driver priority, and minimum delivery commitments per session
Failure handling	Approach: Revert to full power on signal loss — spikes demand during grid stress	Approach: Graceful degradation — continues last valid instruction; resumes normal operation only after signal timeout
Telemetry	Approach: One-way — receives grid signals but does not report back	Approach: Bidirectional — continuously reports available capacity and actual delivery to aggregator via OpenADR telemetry
Event handling	Approach: Single event — handles one DR event at a time	Approach: Concurrent events — manages overlapping events with priority resolution and partial opt-out logic
Scale	Approach: Lab-tested with 5–10 chargers	Approach: Load-tested for 1,000+ concurrent charge points with sub-second dispatch latency

These are not theoretical requirements. In an engagement where we built a multi-protocol fleet aggregation platform for a global technology solutions provider, the same architectural pattern applied: the platform needed to translate between grid-level dispatch signals and individual charger commands across OCPP, Modbus, and proprietary APIs. The charger protocols varied, but the bridge logic — stateful session awareness, graceful degradation, bidirectional telemetry — was identical.

Similarly, when a pool equipment manufacturer needed OpenADR 2.0b certification for California demand response programs, the certification was achieved in six weeks using pre-built accelerator components. The lesson: protocol translation is a solved engineering problem when you start from certified, production-tested building blocks rather than raw specification documents.

From Compliance Hardware to Flexibility Revenue

The AFIR regulation is building the rails. Every new public charger deployed since January 2026 carries ISO 15118 support, and the 2027 DC retrofit deadline will extend that compliance across the installed base. The data architecture challenges of payment transparency and NAP reporting are being addressed.

The NC DR will create the market that runs on those rails. When flexibility markets open in 2027, the operators who already have a functioning Protocol Bridge — receiving OpenADR signals, translating them into OCPP commands, and reporting telemetry back to aggregators — will monetize their charging networks as grid assets. Those without the bridge will watch flexibility revenue flow to competitors while their AFIR-compliant hardware sits underutilized.

The Protocol Bridge is not a future requirement. It is a current architectural decision with a 12-month runway. The operators building it now will enter 2027 with a tested, production-grade translation layer. Those who wait will face the same compressed timeline that made the January 2026 hardware retrofit so painful.

The question for every CPO architect: your chargers can modulate load on command. Can your software hear the command?