By AGILE Consulting Engineers, Solar PV and Battery Energy Storage Systems (BESS) specialists.
A virtual power plant (VPP) is often described as software, and that description undersells it badly. The dispatch platform is only one layer sitting on top of physical hardware, a communications path that has to survive a home internet outage, and a control hierarchy that has to fail safely if any part of that chain drops out. Get the hardware and telemetry layer wrong and no amount of clever aggregation software will produce a resource the market operator can actually rely on.
Table of Contents
- The Layered Architecture of a VPP
- Asset-Level Hardware: PCS, BMS, Meters and Inverters
- Local Controllers and Gateways
- Communications and Telemetry
- The DERMS/EMS Aggregation Layer
- Dispatch and Control Logic
- Cyber Security Considerations
- How Design Differs by Scale
- What to Do Next
- FAQ
The Layered Architecture of a VPP
A useful way to think about VPP design is as a stack of layers, each with a distinct job. At the bottom sits the physical asset, a battery energy storage system (BESS) or solar inverter with its power conversion system (PCS) and battery management system (BMS). Above that sits a local controller or gateway that talks to the asset over a local protocol. Above that sits a communications path back to a central platform. At the top sits the distributed energy resource management system (DERMS) or energy management system (EMS) that aggregates thousands of individual assets into a single dispatchable resource and issues the dispatch instructions the market or a network actually sees.
Each layer has to be specified with the others in mind. A gateway that cannot hold a stable connection undermines a beautifully designed DERMS. A DERMS that assumes telemetry latency the underlying communications network cannot deliver will produce an aggregate capacity figure that quietly diverges from reality. Good VPP design is largely the discipline of keeping every layer honest about what the layer below it can actually guarantee.
Asset-Level Hardware: PCS, BMS, Meters and Inverters
At the asset level, the PCS converts direct current (DC) from the battery or solar array to alternating current (AC) suitable for export, and its response characteristics, ramp rate, and ability to accept external setpoints for active and reactive power are what ultimately determine whether a fleet can deliver a fast frequency response product or simply a slower demand response service. The BMS manages the battery’s state of charge, temperature and cell balancing, and its role in a VPP context extends to reporting accurate state of charge and health data upward, since a dispatch platform making commitments to the market is only as good as the state of charge data it is fed.
Metering matters as much as the generation or storage hardware itself. Revenue-grade or market-grade metering may be required depending on the registration category and the services being offered, and the point at which metering sits, at the inverter, at the connection point, or both, affects what can be verified independently of the vendor’s own telemetry. Inverter selection also needs to account for firmware-level support for the specific control functions a program needs, such as accepting a dynamic operating envelope (DOE) from a network or curtailing export on instruction, rather than assuming every inverter marketed as “VPP ready” supports the same functions to the same standard.
Local Controllers and Gateways
Between the physical asset and the wider communications network sits a local controller or gateway, often a small device installed alongside the inverter or battery that translates between the asset’s native protocol and whatever the aggregation platform expects. This device is frequently the least glamorous part of a VPP’s design and also one of the more common points of failure in the field, since it typically depends on a customer’s home internet connection, has to survive power interruptions gracefully, and needs a defined behaviour for what the asset does if it loses contact with the central platform.
Specifying that fail-safe behaviour is a genuine engineering decision, not a footnote. A battery that continues operating on its last known instruction indefinitely during a communications outage behaves very differently to one that reverts to a conservative default state, and the right answer depends on the program’s risk tolerance and the network’s requirements.
Communications and Telemetry
Communications design has to account for the fact that a VPP’s assets are typically distributed across thousands of separate premises, each with its own connectivity quality, rather than a single site with dedicated fibre. Cellular connectivity, home broadband and, in some designs, mesh or dedicated radio networks are all used, and the choice affects latency, reliability and ongoing cost. Telemetry requirements are set by what the aggregator needs to report to AEMO or a network operator and by what the dispatch logic itself needs to operate safely, typically covering real and reactive power, state of charge, and operational or fault status at a defined resolution and latency.
It is worth being explicit that telemetry specified for billing or customer app purposes is often not the same telemetry needed for market dispatch or network visibility. A design that conflates the two tends to under-deliver on one of them.
The DERMS/EMS Aggregation Layer
The DERMS or EMS layer is where individual asset data becomes a portfolio view. This layer forecasts available capacity across the fleet, accounts for assets that are offline, in fault, or excluded by a customer opt-out, and produces the aggregate figure that gets offered into a market product or committed to a network agreement. It also has to translate a portfolio-level dispatch instruction back down into individual asset-level setpoints, respecting each asset’s own state of charge, network connection limit and any applicable dynamic operating envelope.
This layer typically also carries the supervisory control and data acquisition (SCADA) style monitoring function for the fleet, giving operators visibility of the aggregate resource’s real-time status, even though the underlying assets are geographically scattered rather than co-located in a single plant.
Dispatch and Control Logic
Dispatch logic is the rules engine that decides which assets respond to a given instruction, in what order, and by how much. Good dispatch logic accounts for diversity across the fleet, rotating which assets bear the load of frequent dispatch events so that no single customer’s battery is cycled disproportionately, and it needs defined behaviour for partial fleet availability, since a program that has enrolled a nominal capacity figure will rarely have every asset available and healthy at the exact moment of dispatch.
This is also the layer where compliance with frequency control ancillary services (FCAS) requirements or a network’s dynamic operating envelope gets enforced in near real time, which means dispatch logic has to be tested under realistic fault and degraded-communications scenarios, not just the clean-path case.
Cyber Security Considerations
A VPP is, functionally, a distributed control system with tens of thousands of endpoints in customer premises, which makes cyber security a design requirement rather than an afterthought. Considerations include how gateway devices authenticate to the central platform, how firmware updates are signed and distributed, how a compromised individual device is prevented from being used to send false telemetry or accept unauthorised commands, and how the platform itself is segmented so that a breach at the customer-facing layer cannot propagate into dispatch or market-facing systems. Given that dispatch instructions ultimately affect real power flows on a shared network, the security posture of a VPP platform is a genuine grid-security question, not simply a data-privacy one, and Australian programs are increasingly expected to demonstrate this rather than assert it.
How Design Differs by Scale
The architecture described above holds broadly true across scales, but the emphasis shifts. A residential fleet aggregation prioritises scale of onboarding, tolerance for variable home connectivity, and statistical management of thousands of small, heterogeneous assets where individual asset failure is expected and immaterial to the portfolio. A commercial and industrial (C&I) program typically involves fewer, larger assets, each of which may justify dedicated communications and more bespoke integration, and where a single asset’s availability matters much more to the portfolio’s reliability. A community battery sits somewhere in between, a single larger asset serving a defined customer base or feeder, which simplifies the aggregation problem but raises different questions about how value is shared among the customers it serves.
Matching the design pattern to the actual scale and use case, rather than defaulting to whichever architecture a particular platform vendor happens to sell, is one of the more consistent gaps in early-stage VPP designs seen in the Australian market.
What to Do Next
Getting this layered design right before a fleet is procured and installed is considerably easier than retrofitting telemetry, fail-safe behaviour or dispatch logic into an operating program. This is the point where a technical review of the proposed architecture, hardware selection and control logic can save months of rework later. We’ve helped teams work through exactly this before committing to a specific platform or hardware vendor.
FAQ
What is the difference between a DERMS and an EMS in a VPP context?
Both aggregate and manage distributed assets, but a DERMS is typically network-facing, managing DER within network constraints such as dynamic operating envelopes, while an EMS is typically market or portfolio facing, focused on optimising dispatch and value for the aggregator or asset owner.
Why does gateway fail-safe behaviour matter so much in VPP design?
Because gateways depend on customer-side internet connections that will periodically drop out, and an undefined or poorly chosen default behaviour during that outage can create either a safety risk or an unreliable aggregate capacity figure.
Does every inverter marketed as VPP compatible support the same functions?
No, support for specific functions such as accepting external setpoints, curtailing to a dynamic operating envelope, or providing fast frequency response varies by firmware and model, and this needs to be verified against the specific program’s requirements rather than assumed from marketing material.
How does VPP system design differ between residential and commercial and industrial programs?
Residential fleets prioritise scale, onboarding automation and statistical tolerance of individual asset failure, while commercial and industrial programs typically involve fewer, larger assets where individual asset availability and more bespoke integration matter more.
Why is cyber security treated as a core design requirement rather than an add-on?
Because a VPP is a distributed control system whose dispatch instructions affect real power flows on a shared network, so a security failure has potential grid-security consequences, not just data-privacy ones.
