IEEE 2030.5 vs CSIP AU
The difference between IEEE 2030.5 and CSIP AU
This is Part 2 of a series on CSIP AU and IEEE 2030.5. If you are new here, start with What is CSIP AU and why does it matter for Australian energy? — it gives you the foundation this post builds on.
In conversations about DER communication in Australia, two names come up constantly: IEEE 2030.5 and CSIP AU. They often appear in the same sentence, sometimes as if they mean the same thing. They do not — and using them interchangeably creates real problems for vendors, procurement teams, and engineers alike.
The simplest way to frame it: IEEE 2030.5 is the international standard. CSIP AU is an Australian profile built on top of it. They operate at different levels, serve different purposes, and were created by different bodies. Getting the distinction right is not pedantry — it is a practical requirement for anyone building, buying, or mandating DER communication systems in Australia.
IEEE 2030.5 — the international base standard
IEEE 2030.5, also known as Smart Energy Profile 2 (SEP 2), is a communication protocol developed by the Institute of Electrical and Electronics Engineers (IEEE). It defines how energy devices — solar inverters, batteries, EV chargers — communicate with network management systems.
A few things stand out about how it was designed:
It uses standard web technology. IEEE 2030.5 runs over HTTPS and uses a REST architecture — the same building blocks as modern web applications. This was a deliberate choice. It means devices can communicate over ordinary internet infrastructure, without proprietary hardware or dedicated network links.
It was built specifically for DERs. The protocol defines resource types for things like power generation, storage, demand response, and pricing. It is not a generic IoT protocol repurposed for energy — it was designed for this problem.
It supports monitoring, scheduling, and control. A server (typically a DNSP system) can read metering data from a device, send it control instructions, and schedule future actions. A device can discover what the server supports and register its own capabilities.
Here is the important caveat: IEEE 2030.5 is intentionally broad. It defines a rich vocabulary of resource types and interaction patterns, but it does not always specify which of those you must use, or exactly how you must use them. That flexibility is valuable for a global standard — different markets have different needs. But it also means that two systems can both be IEEE 2030.5 compliant and still fail to interoperate, because they each implemented different subsets of the standard in different ways.
This is not a flaw in IEEE 2030.5. It is a feature of how international standards work. The problem comes when people assume IEEE 2030.5 compliance is sufficient for Australian grid integration.
It is not.
CSIP AU — the Australian implementation profile
CSIP AU stands for Common Smart Inverter Profile — Australia. It is a profile: a constrained, prescriptive specification that sits on top of IEEE 2030.5 and defines exactly how that standard must be used in the Australian context.
In standards terminology, a profile takes a flexible base standard and makes deliberate choices: which functions are mandatory, which are optional, which are prohibited, and what additional rules apply. Where IEEE 2030.5 says “here is how you could do this,” CSIP AU says “in Australia, this is how you must do it.”
CSIP AU was developed by the DER Implementation and API Technical Working Group (DERIAPITWG), with participation from AEMO, distribution network service providers, inverter vendors, and other industry stakeholders. The requirements are formalised in two published Australian standards:
- SA HB 218:2023 — the implementation guide that defines how CSIP AU must be applied
- SA TS 5573:2025 — the updated technical specification that replaces HB 218:2023 following a 12-month transition period
These are the documents that matter for compliance in Australia. Not the IEEE 2030.5 base standard alone.
What does CSIP AU add? In practical terms:
- It specifies which IEEE 2030.5 functions are mandatory for Australian DER connections — not just possible, but required.
- It defines precise rules for device registration using mutual TLS certificates, tying each device to a verifiable identity.
- It sets expectations for control event handling — how devices must respond to instructions from a DNSP, including timing, prioritisation, and fallback behaviour.
- It mandates specific metering and telemetry reporting requirements.
Where IEEE 2030.5 hands you a toolkit, CSIP AU tells you which tools you must use, how to hold them, and what the finished job must look like.
The distinction at a glance
| IEEE 2030.5 | CSIP AU | |
|---|---|---|
| What it is | International communication standard | Australian implementation profile |
| Developed by | IEEE | DER Integration API Technical Working Group (DERIAPITWG) |
| Scope | Global | Australia |
| Mandate level | Flexible — defines what is possible | Prescriptive — defines what is required |
| Published as | IEEE Std 2030.5 | SA HB 218:2023 + SA TS 5573:2025 |
| Covers | Protocol, resource model, message formats | Mandatory functions, rules, certificate handling, Australian-specific requirements |
| Compliance means | You can speak the protocol | You meet Australian grid connection requirements |
An analogy that holds up well: think of IEEE 2030.5 as the HTTP protocol — the foundation that defines how requests and responses work on the web. CSIP AU is like a specific API specification built on top of HTTP — it says which endpoints exist, which fields are required, what the valid responses are, and what the error handling must look like. Knowing HTTP does not mean you know the API. You need both.
Why the conflation happens — and why it matters
The confusion is understandable. IEEE 2030.5 and CSIP AU are closely related, and people in the industry often reach for whichever name feels more familiar. “It supports IEEE 2030.5” has become shorthand for “it does the DER communication thing,” even when CSIP AU is the actual requirement.
The problem is that the gap between the two is large enough to cause real failures:
Vendor datasheets. A vendor may truthfully claim IEEE 2030.5 compliance while implementing only a subset of the standard — one that does not include the functions CSIP AU mandates. The claim is technically accurate. The product still cannot connect to an Australian DNSP.
Procurement specifications. A specification that says “must support IEEE 2030.5” without specifying CSIP AU creates ambiguity. A vendor can satisfy the letter of the requirement while delivering something that fails in the field.
DNSP connection tests. DNSPs test against CSIP AU conformance — the specific profile, not the base standard. A device that passes generic IEEE 2030.5 interoperability tests can still fail DNSP onboarding if it does not implement the mandatory CSIP AU functions correctly.
Practical implications
If you are building a DER device or client software, the standard you need to implement is CSIP AU — which means implementing IEEE 2030.5 as the base, then applying all the constraints and requirements that CSIP AU adds on top. Start with SA HB 218:2023. Use IEEE 2030.5 to understand the protocol mechanics.
If you are writing procurement specifications or evaluating a vendor’s claim, require CSIP AU conformance explicitly — not just IEEE 2030.5. Ask which published standard they tested against, which version, and against which conformance test suite. A vendor can satisfy the letter of “IEEE 2030.5 compliant” and still fail DNSP onboarding.
If you are a DNSP or regulator, be specific in your mandates. “IEEE 2030.5” and “CSIP AU” are not interchangeable in policy documents. The standard you reference determines what vendors are actually required to implement.
What comes next
With this distinction established, the series can go deeper into how CSIP AU actually works in practice.
The next post will look at device registration — how a DER client establishes a trusted identity with a DNSP server using certificates, and what the registration flow looks like from both sides.
If you are working through a CSIP AU implementation and have questions, reach out. And if this post helped clarify something that has been fuzzy, follow the blog — the next few posts go into the mechanics in detail.
Part of a series on CSIP AU and IEEE 2030.5. Part 1: What is CSIP AU and why does it matter for Australian energy?