VPP

A virtual power plant has no turbine and no single site. It is software that connects many small assets, such as home and commercial batteries, solar plants, heat pumps, EV chargers and industrial loads, and operates them as if they were one power plant. Each asset alone is too small to trade on a power exchange or to offer a balancing service. Together, with a control system that can move them on command, they can.

A VPP runs in four steps:

• Aggregate. The platform registers assets, their location on the grid, their technical limits and the contract with each owner, and groups them into units that match a market product.
• Forecast. It predicts what the assets will produce and consume without intervention, and how much flexibility they can offer in each period. That forecast is the baseline.
• Dispatch. When a market, a grid operator or the VPP's own trading strategy calls for a change, the platform splits the requested power across assets and sends setpoints, usually to the EMS or gateway at each site.
• Verify and settle. Afterwards it compares metered values with the baseline, proves what was delivered and pays each owner their share.

The same platform can serve several markets: wholesale trading on the day-ahead market, balancing services such as aFRR, demand response programs and local flexibility for distribution operators. What changes between them is the response time, the size of the minimum bid, the telemetry the buyer wants and the rules for proving delivery.

A VPP is mostly an integration and accounting problem. The optimization algorithm matters, but projects fail on device diversity, data gaps and disputes over what was delivered. Requirements worth writing into the specification:

• Devices are heterogeneous and partly unreliable. Every brand of inverter, battery or charger has its own interface, some report through the maker's cloud, and some go offline. The platform needs a per-model integration layer and has to know, for each asset, whether it is reachable right now.
• Owners and operators declare availability. They report when an asset is unavailable, for a single metering point or a whole aggregation unit, and the dispatch logic must take those declarations into account before it accepts a call.
• Allocation is a rule you can explain. Splitting a call evenly across assets is simple but ignores what each one promised. Allocation by declared power, with a buffer above the requested total, is fairer and safer, and the rule must be visible to the operator.
• The baseline decides the money. The platform needs a documented baseline method, a way to rebuild data after a communication outage and reports that come out soon after each period ends.
• Telemetry matches the product. Balancing services need fast, frequent readings and setpoints; a demand response call can work with metered 15-minute data. Pick the target market before you design the data path.
• Customers see only their own assets. An aggregator serves many owners, so data separation is a functional requirement as well as a security one. A customer whose points share a call with others should see only their own part.
• Local control stays local. Safety limits and battery protection run at the site, and a central VPP command never overrides them.

EU law does not define a virtual power plant. It defines the activity behind it. Article 2(18) of Directive (EU) 2019/944 defines aggregation as a function performed by a natural or legal person who combines multiple customer loads or generated electricity for sale, purchase or auction in any electricity market, and Article 2(19) defines an independent aggregator as one not affiliated with the customer's supplier. Article 17 requires Member States to allow final customers, including those offering demand response through aggregation, to take part in all electricity markets alongside producers without discrimination.

For balancing services, Commission Regulation (EU) 2017/2195 (the electricity balancing guideline) sets the framework in which transmission system operators buy reserves. Each operator defines the prequalification and the technical conditions for its products, so a VPP that wants to sell aFRR has to meet that operator's rules on response time, telemetry and testing for every unit it offers.

We do not offer a VPP platform and have not built one end to end. We have built two of its layers for clients: the aggregation and call layer of a demand response platform, which runs in production, and a site-level orchestrator for battery storage, which we are building in 2026.

We built the demand-side response module of the Zeronest energy management platform. It groups metering points into aggregation units, keeps unavailability reports for each point and each unit, and lets an aggregator create a call across many points. Participants confirm a call through a link sent by SMS and e-mail, and the platform builds a corrected baseline and a report for each hour of the call. The demand response entry describes how a call is split across points, including the buffer above the requested power. In the energy cooperative module, added in 2026, an operator can control the installations of many metering points at once.

For Global Green's battery storage sites we are building an EMS whose orchestrator combines setpoints from several sources, such as trading, aFRR and direct control, resolves conflicts between them and only then distributes the result across batteries. That is the site-level layer of a VPP: it turns commands from several sources into safe setpoints for each battery.