Inside Mercury's EVSE working group: how EV charger flexibility requirements get decided

Vendor-neutral governance is easy to claim and difficult to show. So we are putting questions to the people who chair Mercury's working groups. First is Alberto Dognini, chair of the EVSE working group, on how EV charger flexibility requirements are written, who votes on them, and why adding a second communication protocol is more work than it sounds. In short:

• Mercury's EVSE working group defines the functional requirements and test procedures that an EV charge point must meet to be certified for grid flexibility. 
• It meets monthly, votes on adoptions, and includes EVSE manufacturers, utilities, flexibility service providers, and research organisations. 
• Its current work covers adopting OpenADR alongside OCPP, and refining what utilities need from a charge point.

‍

What does a Mercury working group actually do in a month?

"The group defines the functional requirements for the EVSE, based on multiple communication protocols, and the test procedures. We present the offline achievements of the past weeks, discuss the open points and vote on specific adoptions. The monthly activity is adapted to keep alignment with the other Mercury groups, guaranteeing a common Mercury approach in communication protocol adoption, test procedures and functional requirements."

Most of the work happens between meetings. The meeting is where it gets tested and where it gets adopted.

The alignment point Alberto mentioned is a key governance mechanism for us. Mercury covers EV chargers, batteries, heat pumps and hot water cylinders, and a device class has to mean the same thing across all four. A Class B battery and a Class B charge point answer to the same performance definition. Keeping that true takes deliberate coordination between the groups.

‍

Who is in the Mercury EVSE working group?

"The group is balanced in terms of organisation type. OEMs, utilities, flexibility service providers and research organisations. Each organisation type raises specific aspects regarding the feasibility of proposed changes, for example economic sustainability or regulatory compliance."

The makeup of our working groups is deliberate. A requirement an EVSE manufacturer cannot build economically does not survive the room. Neither does one a utility cannot rely on, or one that puts a flexibility service provider on the wrong side of a market rule.

‍

What were you working on before Mercury?

Before Mercury, Alberto spent years on grid digitalisation and flexibility projects. We asked what problem kept coming up.

"I have been working for several years with grid digitalisation and energy flexibility projects. Within them, missing interoperability has always been a recurring bottleneck for the distribution networks and utilities, limiting the full uptake of optimal flexibility solutions. Beyond semantic and syntactic interoperability, the new energy flexibility schemes require particular attention to functional interoperability too."

That last distinction is the one most often skipped, and it is the reason Mercury exists.

Semantic and syntactic interoperability cover whether two systems share a vocabulary and a message format. Get those right, and a signal arrives intact. Functional interoperability is the harder question underneath. Did the device do what the instruction asked, within the time the grid needed it, and did it report back accurately enough that anyone can tell? Mercury's device classes exist for that third question. 

‍

What is Mercury’s EVSE group working on right now?

“The group is currently focusing on two topics. The adoption of OpenADR as a second communication protocol, in addition to OCPP, aligned with Mercury requirements. And the utility requirements towards the EVSE, with the aim of refining the Mercury EVSE requirements."

OpenADR and OCPP are widely deployed, and neither competes with Mercury. They define how a message reaches a device. They do not set a performance requirement for how fast the device must act on the message, or how it reports what it did. That is the layer Mercury's requirements and test procedures occupy, which is why adding a second protocol is additive work rather than a replacement of anything.

‍

Why is an EV charger the hardest device to write requirements for?

"The EVSE lies in a peculiar position, between the electric vehicle and the utility. Hence, the group aims to enable the EVSE as an energy flexibility provider while simultaneously satisfying EV charging, user experience, and utility requirements. On some occasions, the viewpoints of OEMs and utilities on EVSE capabilities diverged; deeper consultations with industry and energy market experts helped the group to identify the right balance point."

‍

How to get involved

Mercury's working groups are open to member organisations. If your organisation builds, operates or buys grid-facing consumer energy devices and wants a hand in what the requirements say, the working group is where that happens.

Find out more.

‍