There is a moment in most protocol projects when the certificate arrives and everyone assumes the hard part is finished. It is a reasonable assumption. It is also, fairly reliably, wrong.

A certified IEEE 2030.5 implementation is not the thing a utility enrolls. What it enrolls is a platform that satisfies one specific program, and the distance between those two states is where a surprising amount of engineering budget goes, usually unplanned. That gap is the subject of a recent conversation between Codibly and OpConnect, and it is worth setting out properly, because no specification document describes it.

Every program speaks its own dialect

The Common Smart Inverter Profile, CSIP, is the subset of IEEE 2030.5 built around California’s Rule 21, which made it mandatory and gave it its first real installed base. It has since traveled well beyond California. Hawaii uses it, Utah’s Rocky Mountain Power runs its Wattsmart program on it, Australia maintains its own profile, and the SunSpec Alliance has begun to see genuine interest in German-speaking European markets. Certifying a vanilla CSIP implementation through SunSpec is a real milestone.

It also opens the requirements conversation. Each utility and each regulatory market runs its own flavor of the profile: customer requirements that differ, enrollment features and workflows that have to exist, dispatch instructions that need interpreting a particular way, and occasionally a subset of the protocol that has to be adjusted away from the version that passed certification.

Written out as a backlog, program readiness usually means correct DER mappings, public key infrastructure and certificate handling, enrollment workflows, dispatch interpretation, site coordination, telemetry and reporting, certification planning, and an operational handoff to whoever runs the thing afterward. Some of that is discoverable from the specification. Most of it is discoverable only from the program.

So the practical implication is a sequencing one. A platform that decides which programs it intends to enter before implementation scopes the additional work as part of the project. A platform that certifies first and reads the program rules afterward finds the same work later, with a certificate in hand, a customer waiting, and less room to renegotiate scope. The same holds across OpenADR and the neighboring standards. Certification buys the right to be considered; entry is a separate build.

Why the requirements pile up above the protocol

The reason programs keep adding requirements is that the protocol deliberately does not carry the decisions. A utility’s management system states what it needs from the charge point operator and when. The operator decides what every individual charger does about it. That division is the whole point of the interface, and it means the operator’s platform is answerable for behavior the utility can specify but never observe.

OpConnect’s chief executive, Dexter Turner, described what that looks like in more detail than co-hosts usually do. Their algorithm, internally nicknamed EMMA, plans the coming day as a rolling sequence of 144 ten-minute intervals and assigns each group of chargers an energy budget per interval. A new utility signal mid-interval restarts the whole 24-hour computation.

What it enforces those budgets against is the part worth dwelling on. Not one limit but a hierarchy: two chargers sharing a breaker balanced against each other, a group of chargers on a loaded panel balanced at panel level, and the site as a whole respecting whatever the utility has asked for. All three apply at once. Which means the platform will sometimes hold a site below the instruction. Commanded to 400 kW, seeing a panel-level constraint the utility cannot, it manages the site to 300 kW instead.

No standard can specify that behavior, because the constraint is invisible from where the standard operates. This is why “supports IEEE 2030.5” and “can participate in this utility’s program” are different product states, and why the second one has a roadmap. A program tests whether the platform can be trusted with the decisions that follow the signal, and it writes requirements until it believes the answer. Ordinary load management already solves the site-side version of this problem. What the utility interface adds is accountability for the grid-side one: feeder loading, transformer protection, demand spikes, absorbing surplus renewable generation, emergency operations. None of those are visible from inside a charging site.

Two markets, two implementations

Australia makes the point concretely, because CSIP-AUS is the clearest case of the same foundation producing different work.

CSIP (United States) CSIP-AUS (Australia)
Origin Built around California Rule 21 Builds on IEEE 2030.5 and CSIP concepts
Primary focus Smart inverter interoperability DER coordination on a high-penetration grid
Typical use DER interconnection and utility communications Dynamic operating envelopes and flexible export management
Distinct requirements — Dynamic export, emergency backstop mechanisms, load control
Certification path Established pathway through the SunSpec Alliance Regional additions layered on the core profile
CSIP and CSIP-AUS share the IEEE 2030.5 foundation; the Australian profile adds requirements driven by high rooftop solar and distributed storage penetration.

The differences are not cosmetic. Australia’s grid carries an unusual density of rooftop solar and distributed batteries, and the profile reflects that: dynamic export management, emergency backstop mechanisms, and load control requirements that the US profile does not fully demand. A platform operating in both markets satisfies the core profile and then the regional additions, which is a second implementation path rather than a configuration flag.

That is exactly the ground the OpConnect certification project covered, using Codibly’s IEEE 2030.5 accelerator as the starting point rather than a blank repository. Turner’s assessment afterward was that arriving with code which had already been through certification compressed both the implementation and the certification itself, taking time to market from months down to weeks.

The commercial version of the argument

There is a way of reading all of this as a compliance burden, and most vendors do.

The more interesting reading came from Turner in the closing minutes. OpConnect operates in North America — roughly 6,000 charging ports across 35 states and three Canadian provinces — and is looking to expand internationally. Asked how Australia fits, he described the DERMS capability itself as a wedge: something the company can market to open a market it does not yet serve.

That reframes the whole exercise. Certification behaves as a market-access asset, because the requirement is written into how those markets procure. Utilities are increasingly evaluating EV charging as flexible capacity — programs like Southern California Edison’s SIDER and Pacific Gas and Electric’s FlexConnect are early examples of what that evaluation looks like — and the platforms that can answer are a much shorter list than the platforms that would like to.

For utilities designing those programs, the corresponding discipline is to keep the requirements layer above IEEE 2030.5 as thin as possible. Every addition is a bespoke integration somebody has to build, and each one quietly shortens the list of platforms that can enroll. Interoperability only pays off when one implementation works across many programs.

Where this leaves an implementation plan

The through-line is unglamorous: decide which program you are certifying for, and treat the standard as the means.

Pick the programs before the protocol work starts. Treat the certified implementation as the base layer and the program requirements as a known, scoped extension rather than a surprise. Plan certification early enough that it constrains the architecture instead of arriving as a checkbox at the end. And for fleets making deployment decisions, ask about program readiness rather than protocol support, because those are different questions and only one of them determines whether the assets can earn anything.

Certification stays essential. Scoped this way it becomes the opening milestone of a defined piece of work, with the rest of the backlog visible from the start.

Codibly works across that span — advisory on what the requirements backlog actually contains, and the standards implementation itself, including the program-specific adjustments. If you are weighing where your own platform sits between certified and program-ready, that is a conversation worth having early.