Key CSIP-AUS concepts

TS 5573 defines a subset of IEEE 2030.5 functionality that must be implemented to ensure secure, interoperable communication between a Utility Server and CSIP-AUS Client in Australia.

Utility Servers are systems operated by utilities and are responsible for receiving and maintaining records (DER installed and managed by a CSIP-AUS Client), defining functionality (what clients can do) and configuration (how clients should behave), creating controls, and receive monitoring and status data.

A CSIP-AUS Client initiates connection to a Utility Server and is responsible for providing capabilities and settings (rating information), retrieving configuration and control information and submitting monitoring and status data. In some jurisdictions each CSIP-AUS Client must tell servers about the existence and location of DER in the network through a process called “in band registration”.

IEEE 2030.5 defines a “function set” as a logical grouping of resources that cooperate to implement IEEE 2030.5 features.

TS 5573 defines function sets in 2030.5 that must be implemented, which include:

• DER: All functionality related to the representation and management of DER including controls, programs, capabilities settings.
• DeviceCapability: A top-level resource that allows the Utility Server to enumerate the function sets that it supports.
• EndDevice: Used by a server and client to submit send and receive information about a specific DER installed on a site.
• FunctionSetAssignments: Used by the server to map DER to specific roles or services such as control programs or pricing programs
• Meter/Mirror Meter: Allows CSIP-AUS Clients to submit timestamped monitoring data for a variety of measured electrical parameters.
• Response: Allow CSIP-AUS Clients to provide updates to Utility Servers about the status of a particular event.
• Subscription/Notification: As an alternative to polling, a mechanism for CSIP-AUS Clients to receive updates on server resources when they occur.
• Security: Minimum functionality to enable secure communications between CSIP-AUS Clients and Utility Servers.
• Time: Ensures time synchronisation between client and server, which is critical for event scheduling, telemetry timestamping and compliance auditing.

All function sets must be implemented in accordance with TS 5573:2025 which defines conformance requirements and expected behaviours.

Key functional architecture elements

TS 5573 integration architecture specifies or implies the following functional elements:

• Utility Server: A server operated by a DNSP or other utility that communicates with DER using IEEE 2030.5.
• CSIP-AUS Client: Software that implements the client-side functionality of CSIP-AUS.
• Energy Management System: Client-side software that monitors, coordinates and optimises electricity generation, storage and load under management to achieve a specified outcome. This can be located on-site (e.g. with the Local Controller) or in the cloud.
• Local Controller: A physical device located at the customer premises that directly manages DER assets.
• DER: The generation or load device that is enacting a control from a local or remote signal. This could include an inverter or EVSE.
• Site Meter: A meter situated at the PCC. The EMS and Site Controller utilise the site meter data as an input in coordinating assets to meet site level export or import limits.

The relationship and function of CSIP-AUS architecture elements (generic illustration)

Client-side elements can be physically integrated or separate. For example, the CSIP-AUS Client, EMS, Local Controller can all be physically integrated within a single PV or BESS inverter. Alternately compliant solutions can also locate the CSIP-AUS Client in:

• A Gateway Device: A physical device located at a customer premises, separate to the DER under control, typically operating multiple DER as a site (e.g. a HEMS).
• A Cloud Proxy: A cloud-based system that intermediates communication between DER or a Gateway Device, and a Utility Server. Such a cloud solution could include or exclude EMS functionality.

Where a solution does not have the CSIP-AUS Client built into the DER, local or remote communication to the DER is required, which may be through standardised or proprietary protocols. For example, in an EV charging context the EMS could act as a local or remote CSMS and pass instructions to an EVSE using OCPP. In a gateway context, the EMS could use multiple protocols (OCPP, Modbus, Matter, API etc.) to communicate with multiple DER devices at the customer premises, and act as the Local Controller.

Site-level application

CSIP considers DER as a logical concept generally thought of as one or more physical inverters organised and operating as a single system with a common point of aggregation behind a PCC.

TS 5573 reaffirms this position, allowing (but not requiring) for an EndDevice to encapsulate all relevant DER at a customer premises. A premises relates to a separate customer electrical installation that has a single PCC to an electricity network.

Additionally, TS 5573 introduces additional control instructions (e.g., DOEs), whose scope covers all controllable and non-controllable load and generation on site.

The ability for an EndDevice to encapsulate multiple DER, and the requirement to support controls whose scope covers the whole premises, has several implications for DER solution design:

• Coordination of all relevant devices: If a premises has multiple relevant devices (e.g. PV, BESS and/or EVSE) from different vendors, to deliver DOE conformance these must be coordinated by an EMS as a single EndDevice. This requires either:
  • Functional BTM interoperability between all relevant devices (including their testing and certification to a common protocol).
  • There is a proprietary integration from the CSIP-AUS Client and Local Controller to the DER that has been tested and is certified to work with those devices.
• Site metering for conformance: TS 5573 requires site-level monitoring information to be regularly sent to the Utility Server. Formal compliance checks can occur via the utility accessing a customer’s Market Meter data.
• Site controller configuration: While TS 5573 does not explicitly prescribe that the EMS and local controller must be located on site, there are practical impacts with operating a remote or “virtual” EMS. To meet a utility’s 15-second response time requirement, the EMS must be able to receive monitoring data from, and issue control signals back to, on-site devices within the same 15-second window, accounting for both upstream and downstream communication latencies.

Supported connection models

TS 5573 formally recognises three connection models:

• Direct-to-device model: In this model, the Utility Server communicates directly with a CSIP-AUS Client embedded in the DER device (e.g. an inverter). This architecture simplifies communication pathways but requires each device to be individually addressable and compliant (i.e. one EndDevice per NMI). The direct-to-device model is most suitable for customer sites with a single DER device, such as a PV inverter, under control. The device must act as the Local Controller to ensure compliance with DERControl instructions.
• Proxy connection model: A cloud proxy hosts the CSIP-AUS Client (potentially one client for a fleet of customers) and translates control signals to the customer premises using unspecified communications methods. As these communications are proprietary, the proxy client must be tested and certified against each DER series that is desired to be used with that proxy client.
• Gateway model: The CSIP-AUS Client is located at the customer site-level (e.g. physically co-located with the EMS and Local Controller). A gateway device typically manages multiple DER devices and can present a single interface to Utility Server or an aggregation platform. This model can simplify onboarding and ongoing management for complex sites with multiple DER.

Related Articles

• Overview of CSIP-AUS
• CER interoperability standards