CER interoperability standards define how consumer energy resource devices communicate with networks, energy management systems, aggregators and market platforms. Standards vary for different types of CER technologies. For CER product and project developers, these standards affect device communications, remote control, telemetry, cybersecurity, certification and compatibility with Australian grid-integration requirements.

Key points

• CER interoperability standards define how devices and platforms exchange data, commands and operating limits.
• AS/NZS 4755 supports demand response functions for appliances, EVSE and inverter-connected systems.
• AS 5438 is being developed to define interoperability requirements for inverter energy systems.
• ISO 15118 and OCPP are central to EV charging, smart charging and future V2G capability.
• OpenADR may support demand response, dynamic pricing and aggregator-to-device communication, although Australian adoption is still limited.
• Product developers should consider interoperability early because it affects communications architecture, certification, cybersecurity and future market access.

AS/NZS 4755: Demand response standard

AS/NZS 4755 is a multi-part standard that defines the framework for demand response capabilities in electrical appliances. It enables equipment such as air conditioners, pool pumps, EVSE, and inverters to respond to signals from electricity networks or market operators to reduce or shift energy use.

The standard specifies nine DRMs, including DRM0 (cease all generation or load), DRM1–DRM8 (various levels of load reduction or increase), and the communication protocols required to implement them.

AS/NZS 4755 is structured in parts:

• Part 1: outlines the general requirements and definitions.
• Part 2: covers device-specific requirements (e.g. for air conditioners, pool pumps).
• Part 3: defines communication protocols and interfaces, including interoperability with external controllers.
• Part 4: supports integration with CER systems, including PV inverters and BESS.

DRM functionality is used by DNSPs under various programs to reduce peak demand or mitigate Minimum System Load conditions. These use cases are explored in the articles Dynamic network export and generation control schemes and Network load control schemes.

The principal use-cases for AS/NZS 4755 in Australia are in Queensland, where it underpins the PeakSmart rebate programme for demand response-enabled air conditioners, provides a pathway for load control of EVSE, and is mandated for Emergency Backstop (DRM0) implementation for inverters. Communication to customer premises for PeakSmart is typically achieved via ripple control signals sent by the DNSP to an on-site demand response enabling device (DRED), which interfaces with the appliance.

For inverters and EVSE, communication and control pathways may differ and can include wired or wireless interfaces as specified in AS/NZS 4755.3.5.

DRM0 support is also a mandatory national requirement under AS/NZS 4777.2.

AS 5438: Inverter interoperability (under development)

AS 5438 is a proposed Australian Standard for Interoperability Requirements for Inverter Energy Systems. The work is being led by the EL042, the Standards Australia technical committee responsible for standards related to “renewable energy systems”, particularly AS/NZS 4777 series. Minimum interoperability requirements for CER have been flagged as a Priority T1.1 under the National CER Roadmap and AS 5438 is considered the primary candidate for requirements on inverters.

The proposed standard and its testing procedure is intended to align closely with clause 10 of IEEE 1547 requiring a physical communications interface (Ethernet or RS-485) and support for a recognised communications protocol. It specifies that the interface shall be available when the inverter is powered up (i.e. on an ongoing basis).

As of October 2025, candidate protocols include:

• Sunspec Modbus (version 1.2)
• SEP2 - AS 5385 (IEEE 2030.5), and/or
• OCPP 2.1

The proposed standard defines read only and read/write settings for a range power and power quality settings for the purposes of local energy management and grid support.

The proposed standard also sets out two architecture options:

• Local orchestration with inverter-integrated EMS, including where that “primary” inverter may control a range of “secondary” inverters and other devices.
• Local orchestration with separate EMS device which may control multiple inverters and devices at a premises.

While the standard is intended to apply to inverters for the purposes of inverter control and telemetry, it also supports standardised interface requirements for EMS systems integrating with inverters.

Initial 18 CER Device Requirements

In March 2026, DCCEEW published Initial 18 Consumer Energy Resource Device Requirements, setting out nationally endorsed voluntary minimum interoperability requirements for new CER devices. The requirements were endorsed by the Energy and Climate Ministerial Council in December 2025 and are intended to guide product development ahead of a future national technical regulatory framework.

The requirements focus on minimum functional capabilities, rather than prescribing technologies or architectures. They apply to new CER including PV inverters, batteries, EVs, EV supply equipment (EVSE), flexible loads and Energy Management Systems (EMS). Existing installed devices are not expected to be retrofitted.

The Initial 18 requirements acknowledge gaps in current Australian standards, particularly for EMS, local device‑to‑device coordination, EVSE functionality and conformance testing.

The requirements span five capability areas:

1.  Safety and system protection

• Disconnection and reconnection (R‑1)
• Fail‑safe operation (R‑14)

2.  Power modulation and grid support

• Response to grid conditions (R‑2, R‑17)
• Response to external signals (R‑3, R‑18)

3.  Monitoring, telemetry and settings

• Remote telemetry and settings access (R‑4 to R‑6)
• Site‑level and aggregated monitoring (R‑8, R‑15)

4.  Interoperability and communications

• Trusted communications (R‑12)
• Unique device identification (R‑10)
• Local CER‑to‑CER coordination (R‑11)
• Provider portability (R‑9)

5.  Consumer outcomes

• Default settings (R‑13)
• Consumer override (R‑16)
• Remote price and tariff signalling (R‑7)

The Initial 18 requirements signal expected baseline capabilities likely to be formalised over time. CER product developers should assess products against the requirements, identify gaps (e.g. around local interfaces, secure communications, EMS integration and provider portability) and monitor ongoing work under the National CER Roadmap as standards and testing pathways are developed ahead of regulation.

ISO 15118: Vehicle to grid communication interface

EVs in Australia predominantly use the Combined Charging System with the Type 2 connector (CCS2). While some vehicles are being sold with the CHAdeMO (DC) charging system, this system is expected to be unavailable in new vehicles by around 2027.

CCS supports multiple standardised communication protocols for electric vehicle (EV) charging, beyond the basic Pulse Width Modulation (PWM) signalling used for AC charging. In Australia, several EV models have demonstrated compatibility with ISO 15118-2, which significantly expands on the capabilities of earlier CCS high-level protocols for DC charging, such as DIN SPEC 70121. ISO 15118-2 (2014) utilises Power Line Communication (PLC), as defined in ISO 15118-3, to enable advanced, high-level data exchange between the EV and the Electric Vehicle Supply Equipment (EVSE).

ISO 15118-2 represents the first generation of high-level communication protocols for both AC and DC charging stations within the CCS framework. The second generation, ISO 15118-20 (2022), introduces several key enhancements:

• Formal, standardised support for bidirectional charging: This enables energy to flow from the EV back to the grid or premises, supporting grid services and energy management.
• State of Charge (SoC) communication: The protocol includes a dedicated functional data block allowing the EV to communicate its battery SoC to the EVSE during AC charging sessions, improving charging control and user information.
• Expanded interface support: In addition to PLC, ISO 15118-20 supports Wi-Fi and Ethernet connections.
• Enhanced cybersecurity: Implements mutual authentication, TLS encryption, digital signatures, and certificate-based authorisation to secure charging sessions.

A notable feature of ISO 15118-20 is the introduction of two control modes for managing charging sessions:

• Dynamic Mode: The EVSE continuously sends updated power setpoints to the EV, allowing real-time adjustment of charging or discharging rates in response to grid signals, system load, or other external factors. This mode is essential for grid-interactive applications such as demand response and V2G services.
• Scheduled Mode: The EV proposes a charging schedule at the start of the session, which the EVSE then follows without further real-time adjustment.

While ISO 15118-20 requires that at least one control mode be supported per session, Dynamic Mode becomes "normatively binding" if it is implemented. In the Australian context, Dynamic Mode is particularly relevant as it aligns with emerging strategies for integrating EVs into grid management and supporting future-focused grid services.

ISO 15118-20 is expected to become the preferred protocol for V2G applications in Australia, with market adoption likely to accelerate in the medium term. Governments have foreshadowed that compliance with ISO 15118-20 may become a minimum requirement for publicly funded charging infrastructure in the future.

What is the Open Charge Point Protocol?

OCPP is the globally dominant protocol for communication between EVSE and a Charging Station Management System (CSMS). Recent versions of OCPP (from 2.0.1 onwards) are standardised as the IEC 63584 series.

OCPP versions typically consist of a Core profile and optional Security and Feature profiles. As with ISO 15118-2/20, minimum compatibility does not require support for the full feature set (this is important to consider when assessing interoperability and grid-interactive capabilities). For ISO 15118 feature sets, OCPP’s Core and Optional functionalities are designed to complement each other, supporting a functional communications chain from the EV to managing entities.

• OCPP 1.6J (released in 2015) is widely used in Australia for charging infrastructure. Compatibility with OCPP 1.6J is a minimum requirement for EVSE connection with Ausgrid, Endeavour Energy, Evoenergy, SAPN, and Western Power. These requirements do not mandate OCPP certification or support for specific feature profiles.
• OCPP 2.0.1 (released in 2022) introduced advanced features, including an improved security model with certificate management, enhanced smart charging (supporting Plug & Charge and a dedicated Tariff block), and richer diagnostics. ARENA has indicated a preference for OCPP 2.0.1 as a minimum forward requirement for EVSE installations in both public and private contexts.
• OCPP 2.1 (2023) is the latest released version, further enhancing cybersecurity and adding optional support for bidirectional charging and “EVs-as-DER” integrations. It is an incremental update to OCPP 2.1 and is expected to become a minimum requirement for EVSE connecting to the grid in the medium term. Formal adoption is at an early state, with state and federal agencies aligning procurement and compliance frameworks to the standard. Product developers should monitor updates and prepare for OCPP 2.1 compatibility as a future for market entry requirement.

OCPP certification requires conformance testing by a laboratory accredited by the Open Charge Alliance. Certification is considered an effective strategy to reduce risk in EVSE and CSMS integrations.

OCPP 2.0.1 onwards provides formal security profiles that mandate TLS encryption, server-side and optional client-side certificates, and mutual authentication, ensuring confidentiality and integrity of EVSE<>CSMS communications. These versions also define certificate lifecycle management and introduce secure firmware update requirements, including cryptographic integrity validation and controlled distribution via the CSMS. By contrast, OCPP 1.6 only optionally supports TLS and lacks a standardised secure firmware update mechanism or mandated certificate-based authentication, so additional security controls and vendor-specific hardening is required for robust deployment.

What are some of the options for implementing OCPP?

OCPP 2.0.1 adds significant functionality over OCPP 1.6J by enabling EVSEs to communicate changes in limit states (such as maximum allowable charging current, power, or energy) to a CSMS. This allows EVSEs to be connected to both a CSMS and an independent EMS or other controller via diverse protocols, with the CSMS maintaining control over the EVSE. OCPP 2.0.1 and later can also manage local controls directly, with low latency and high security.

OCPP communications may be direct to a cloud-based CSMS or routed through a Local Controller that manages loads at the edge, either as a dedicated device or as part of an EMS solution.

Some OCPP implementations use proxy servers between the EVSE and the CSMS, which can enable the interception or modification of control commands for purposes such as monitoring, load management, or protocol translation. Because this introduces potential security and operational risks, it is essential to design the network carefully to ensure that all communications remain secure and that any modifications to control signals are deliberate and authorised.

OCPP certification requires EVSEs to serve OCPP directly, rather than through proxies or virtualisation.

What is OpenADR?

OpenADR is a protocol standard used to automate and standardise the communication of demand response signals between utilities, aggregators, and energy resources. IEC 62746-10-1 is an international standard (published in 2019) that effectively adopts the OpenADR 2.0b profile specification.

While not widely used in Australia, OpenADR is particularly relevant for:

• Flexible loads such as air conditioners, pool pumps, and electric water heaters.
• EMS, which currently lack defined standards for receiving and acting on price signals.
• VPPs and aggregation platforms seeking to standardise communications with a DNSP or CER devices.

OpenADR 3.0 was officially released in late 2023 complementing (but not replacing) OpenADR 2.0b. It simplifies the protocol architecture introduced in 2.0b, replacing XML with JSON for easier cloud integration. It adds native support for dynamic pricing, emissions signals, and flexible export limits via DOEs.

Australia’s adoption of CSIP-AUS, and specifically its application of DOEs at the customer premises-level, is considered to somewhat conflict with the principal intent of OpenADR to coordinate CER device behaviours directly. However, pathways exist for local OpenADR adoption for example as an open standards approach to communicating between CER devices and an aggregation platform operating within site-level import and export limits issued by a Utility Server.

Local adoption to OpenADR may also be influenced by market uptake of CSIP-AUS v1.3 extensions including the Storage Extension and Pricing Extension which overlap with the scope of OpenADR 3.0.

Related articles

• CER technical and interoperability standards
• Standards for electrical installations in Australia
• Other standards
• Utility Interconnection (CSIP-AUS)
• Dynamic network export and generation control schemes
• Cybersecurity and EV charging