Two groups of engineers, separated by the North Sea and working with no reference to each other, spent the better part of two years on the same question: which protocol should carry flexibility signals between a grid operator and the assets sitting on the far side of the meter?

In Great Britain, the Energy Networks Association convened a working group in 2023 with every system operator in the room, transmission included. In the Netherlands, three charge point operators sat down with the country’s three largest distribution system operators. Both groups wrote requirements first and evaluated against them. Both compared a similar field of candidates. Both landed on OpenADR.

That convergence is real, and it matters. What made it worth sitting through the whole session, though, was what came after it. On a panel Codibly co-hosted with the OpenADR Alliance in July, the people responsible for those two decisions sat alongside the convener of the IEC working group trying to reconcile the wider standards stack — and rather than relitigating the protocol choice, they went straight to the harder question behind it: why agreeing on a protocol does not, by itself, deliver interoperability.

Great Britain and the Netherlands Reached the Same Answer Separately

The British decision did not begin as a technology choice. The objective, as Tim Manandhar of UK Power Networks framed it, was never to pick a particular standard or technology at all. It was to reduce the barriers to flexibility participation and build a common approach across Great Britain’s networks. The working group set its criteria first: open standard, interoperability, scalability, security, maintainability, platform independence, backward and forward compatibility, and then the practical tests of cost efficiency and ease of implementation.

Only after that did the assessment run, against a field that included IEEE 2030.5, ICCP and the IEC’s Common Information Model among several others. OpenADR 3.0 came out ahead on fit against the stated requirements and on its alignment with modern REST-based architecture, with the profile-based governance model counting as an added benefit. The work has since moved to OpenADR 3.1, and since the start of 2026 it has been picked up by Elexon in its new role as market facilitator, appointed by Ofgem.

The Dutch decision started from congestion. ElaadNL and its partners needed a mechanism for a new congestion product aimed at public charge points, having previously focused on larger consumers. Their comparison covered the Open Smart Charging Protocol, IEEE 2030.5, IEC 61850 and DNP3. For the specific problem in front of them, as Nicholas Claaszen described it, OpenADR offered the best balance between capabilities and complexity, with the lowest implementation effort on the client side.

Two markets, two entirely different starting problems, one answer. For anyone tracking the protocol question across Europe, that is about as clear a signal as this industry produces, and it sits on top of the wider set of architecture patterns already visible across European DSOs.

The Dutch Architecture Was Set by Law, Not by Protocol Features

The most instructive detail of the session is easy to miss, and it has little to do with protocol features.

Dutch distribution system operators are not permitted to take direct control of customer assets. Control has to flow through an aggregator or market party. So when ElaadNL evaluated protocols, a clean separation of responsibilities was not an architectural preference — it was a legal requirement. OpenADR lets a DSO constrain a whole cluster of charge points while leaving the operator to decide which charger gets what power and which session is interrupted. That division of labour is the regulation, expressed in software.

Contrast that with Austria, where a DSO is working on something close to the Dutch NLFlex concept. As Claaszen described it, that operator is permitted to assume direct control of devices in a way the Dutch operators are not, which opens an architectural route the Netherlands simply cannot take.

Same protocol. Different legal envelope. Different architecture. Any operator planning a cross-border flexibility product should read that as a warning about how much of an implementation is determined by national law rather than by the specification — a pattern that recurs across Europe’s energy standards landscape.

Where OpenADR Stops and the IEC Standards Begin

A recurring assumption in this space is that competing protocols must eventually fight it out. The panel dismantled that briskly.

Laurent Schmitt, who convenes IEC TC57 Working Group 21, described the mapping work his group has been doing between the CIM flexibility package and OpenADR 3.1. The conclusion: the two are largely complementary. OpenADR defines the transport and API layers, which the IEC standards deliberately do not specify in detail. The IEC work concentrates on data ontology, formats and message payloads. They meet rather than compete, and OpenADR 2.0b has been a recognised IEC standard for years, as IEC 62746-10.

The same logic applies a layer down. Rolf Bienert of the OpenADR Alliance was specific about how the layers divide: IEEE 2030.5, SunSpec and Modbus are the right tools for reaching into a device and turning the many settings an inverter exposes, while utility-level objectives travel over OpenADR or the IEC standards to an aggregation point. His accompanying observation was an architectural one — that an operator coordinating a large fleet generally wants to send objectives to an aggregation layer rather than manage device settings one by one, and to let local control do what local control is good at.

The Fragmentation Risk Moved Up a Layer, to National Profiles

Here is the part that deserves more attention than it is getting.

OpenADR is flexible by design. Implementers define their own programs and profiles on top of the base specification, tailoring what they use and how. That flexibility is precisely why adoption has moved quickly: Great Britain, the Netherlands and Austria could each build what their market and their regulator required without waiting for anyone’s permission.

Schmitt named both sides of that trade-off in the same breath. OpenADR has historically left implementers a great deal of freedom, which he judged to be on balance a positive: it lets teams move quickly and with relatively little friction. The disadvantage, in his own framing, is ending up with different instances for different grid operators and different implementations for different classes of device. The same freedom that accelerated adoption lets national profiles drift apart. And the layer where they drift is the layer where cross-border compatibility is actually decided.

The argument that makes this concrete concerns manufacturing. Mass-produced assets — electric vehicles, chargers, heat pumps, home batteries — ship with a single firmware that is maintained across the product lifecycle. A manufacturer does not build a French variant and a Dutch variant of the same vehicle’s grid interface. Schmitt’s example is blunt: today a car can respond on aFRR markets in Belgium but not in France, because the programmes differ once you reach the detail of what measurement, metering and computing each expects from the device. Extend that logic across a continent of separately specified profiles and the result is a device that plugs in physically and does nothing useful — the same coordination problem that shows up wherever flexibility is operated at scale across the EU and US.

His conclusion follows: the goal has to be making the OpenADR instance in the UK the same as the one in the Netherlands, or Austria, or anywhere else. That is harder for the grid operators, who lose some latitude. It is the only way the device side scales.

Reusable Profiles Are the Counter-Mechanism, and They Already Exist

The encouraging part is that the counter-mechanism exists and is running.

The Alliance intends to publish the finalised program descriptions from Great Britain, Austria and the Netherlands on its website so that other markets can use them as templates rather than starting from a blank specification. ElaadNL has already open-sourced its grid-aware charging profile, with an open invitation to reuse it. Claaszen made a further point that is easy to underrate: the Dutch now have working relationships with counterparts in Belgium, Austria and the UK that would not exist had they built a national protocol instead. Interoperability at the technical layer produced interoperability at the institutional layer.

Regulation supplies the forcing function. The European network code on demand response will push transmission and distribution operators to harmonise programmes and products, which Schmitt characterised as a wave arriving over roughly the next three years — and the window in which to tighten profile alignment before a great deal of hardware is in the field.

Codibly’s interest here is an implementer’s one. Having built the OpenADR 3.0 certification test tool and delivered integrations across OpenADR, OCPP and IEEE 2030.5, the pattern is familiar: the specification is rarely the hard part. Reconciling one market’s profile with another’s is where the work actually lives.

Convergence Settled the Protocol, Not the Device

Bienert closed on the customer. Mature demand response markets have been built up over two decades, asset class by asset class, and the capability now reaches deep into the home — thermostats, water heating, pool equipment and much else besides. The breadth is an achievement. The risk that comes with it, in his framing, is that the proposition presented to the household grows more complicated with every addition. The industry’s next job is to make participation legible: propositions that make immediate sense on first encounter, and that visibly save money or improve comfort.

That is the right note to end on, because it reframes what convergence bought. Europe has largely settled which protocol carries flexibility signals. It has not settled whether a device bought in one member state will work in the next, and that question now sits with profiles rather than protocols. It is a narrower problem than the one the industry spent a decade arguing about. It is also the one that determines whether a hundred million connected devices behave like a single system or a hundred million separate ones — and it is decided in the integration work between one market’s profile and the next.