How Can CSIP-AUS Be Made Available To All DER Operators
Recently I was working with a developer looking to roll out solar to residential properties in an embedded network. One requirement was to limit the total export of the microgrid to a site-wide export limit. Two options they were considering were assigning export limits to each solar system or controlling all the solar systems in real-time to stay below a site-wide export limit.
The issue was there were multiple brands of inverters and integrating against each, or choosing an energy management provider that integrates against multiple brands, would dramatically exceed the budget of the project.
This challenge isn't unique to this developer. Across Australia, microgrid operators, VPP (Virtual Power Plant) aggregators, and community energy providers face the same problem: expensive, fragmented vendor integrations that make cost-effective DER (Distributed Energy Resources) orchestration difficult or costly.
But here's the thing: all of these inverters already support a common protocol. A protocol that the Australian industry has invested hundreds of millions of dollars developing, with maturing testing, certification and operational functions: CSIP-AUS.
The question is: how would these alternate operators get into the ecosystem?
CSIP-AUS for non-DNSP use cases
CSIP-AUS is the protocol used to communicate export limits, set points, and soon other functions such as prices between an operator and DER. The original need for the protocol was for solar systems participating in flexible exports or emergency backstop programs to communicate with distribution networks in a standardised way.
Today when you install a solar system in say, Victoria, the installation process will point the solar system's CSIP-AUS client at the relevant network's utility server. For instance if you're in the Ausnet area it's https://derms.ausnetservices.com.au:30101/api/v2/dcap. After the connection has been established and client/server authenticated, the server can start sending commands and settings to the solar system and receive telemetry back.
Below is a list of the publicly available utility server URLs in Australia:
| State | Utility | Endpoint URL |
|---|---|---|
| QLD | Energex | https://sep2.energyq.com.au/api/v2/dcap |
| QLD | Ergon Energy | https://sep2.energyq.com.au/api/v2/dcap |
| VIC | Ausnet | https://derms.ausnetservices.com.au:30101/api/v2/dcap |
| VIC | CitiPower / Powercor / United Energy | https://dermsp.powercor.com.au:30101/api/v2/dcap |
| VIC | Jemena | https://sep2.aws.jemena.com:8444/sep2/dcap |
Wouldn't it be excellent if a non-DNSP operator could also operate their own server, and with the customer's consent, connect the DER's CSIP client to their server?
There are terrific CSIP-AUS reference servers, test harnesses , and the soon to be minted NEPKI to handle certificates and authentication that build quality, consistency and cost efficiencies into the CSIP-AUS ecosystem. It would be a bit of a shame to waste this on narrow network use cases.
Operators of microgrids, VPPs, and even monitoring solutions could leverage the investment made into CSIP-AUS and its associated infrastructure that are in many cases mandated in inverters sold across Australia.
We already have an example of this, with Western Australian retailer Synergy using CSIP-AUS to operate batteries in their VPP.
There are a few issues to resolve to make this widely available.
How can CSIP-AUS clients discover the server?
Currently, the connection between the CSIP-AUS client and server is established during the DER installation process that points the client at the relevant network's utility server.
An easy first step towards broader CSIP-AUS takeup would involve manufacturers allowing installers to flexibly set or add additional utility servers for the client to connect to. This feature could be an extra selling point for manufacturers and would get some customers, such as my microgrid developer, very interested in using solar and battery systems with these features.
A more enduring step is to have a common discovery server. This would be a standard web server operating Australia wide that DER would connect to automatically and periodically check to find which CSIP-AUS utility servers they should connect to. Often this would just be the network's utility server, but there is the option for an alternate utility server to send a request to the common discovery server to include itself on the client's server list. Next time the client checks in with the discovery server, it'll know to connect to the alternate utility server.
A simplified example of the discovery process
This discovery server need not be just for CSIP-AUS. Any change or addition of parties needing to control or communicate to DER could be recorded on this discovery server. Currently when you want a 3rd party to control your DER, such as through a VPP plan, the 3rd party has to contact the manufacturer through email or other systems to connect. These processes can take time and be error prone, leading to poor outcomes for consumers. A common discovery server would allow more transparent, cost-effective, and reliable methods for adding and changing parties controlling DER. Think of it as a MSATS for DER.
What about certificates?
The next issue would be ensuring the client and server have the correct certificates. There are some overly complex solutions such as each utility server operator issuing its own certificates to the clients, and those clients managing multiple certificates and certificate authorities in their trust store, but this is unfeasible, particularly for small operators such as my microgrid operator.
What would be ideal is all CSIP-AUS clients and servers using the same certificate authority. Fortunately, we now have NEPKI, who are making that happen. One addition required would be a process for non-network utility servers to be able to apply and receive a certificate for their utility server that could be used within the NEPKI ecosystem.
This means that CSIP-AUS clients could use the same certificates (or types of certificates) that they use with the networks for non-network use cases, and non-network utility servers could easily authenticate and communicate with clients participating in network programs.
What about CSIP-AUS clients that are already connected to a network's utility server?
Finally, what happens in the increasingly common case that a solar system or battery is already connected to a network utility server. Can we connect it to two utility servers?
Absolutely (with some caveats). The 2030.5 standard, which CSIP-AUS is based on, supports multi-server operations (IEEE2030.5-2018 section 10.2.5 and IEEE2030.5-2023 10.2.4 as well as in other places throughout the document). CSIP-AUS currently doesn't require clients to support multiple servers, so this would need to be added.
This would not be a simple implementation, it would add complexity on the clients and servers, but I think it is worth considering pursuing.
Currently the industry has tested other options on how to manage multiple control signals, such as through the Advanced VPP Grid Integration Trial and Market Active Solar Trial…
Current DNSP/Aggregator control models being tested
…but we're yet to look at the option of two utility servers in parallel, creating more flexibility and independence for the non-network operator.
Currently untested DNSP/Aggregator control model
To sum up, three key enablers: server discovery, common PKI access, and multi-server support, can transform CSIP-AUS from a network-only tool into a platform for the entire DER ecosystem.
This isn't just about making life easier for microgrid operators or VPP aggregators. It's about maximising the return on hundreds of millions of dollars of investment Australia has already made in trials, policy and solutions for CSIP-AUS and common interoperability standards. And it's about creating competition and innovation in DER services.
