The term "virtual power plant" appears in a lot of vendor marketing, utility regulatory filings, and clean energy policy documents, and the term is used inconsistently across all three contexts. For utility operations teams evaluating VPP programs or procuring software to run them, it helps to have a clear-eyed view of what a VPP actually requires to function as described, as distinct from what the concept implies at a high level.
The core idea is real and operationally meaningful: a collection of distributed assets, each too small to bid into wholesale markets or commit as a dispatchable resource individually, can be aggregated into a portfolio that functions like a single large dispatchable resource from the grid operator's perspective. 3,000 residential batteries averaging 10 kWh each, partially dispatched, could represent 5 to 8 MW of controllable load response. That is a meaningful grid resource. The question is what it takes to operate that resource reliably enough to commit it.
The difference between a VPP enrollment list and an operational VPP
Having 3,000 enrolled customers is not the same as having a 5 MW dispatchable resource. The gap between those two states is the operational infrastructure that makes enrollment actionable.
An enrollment list tells you which customers have agreed to participate in the program. It tells you their enrolled capacity based on the nameplate specification of their equipment at installation time. It does not tell you: how many of those assets are currently online and reporting telemetry, what their current SoC is, which ones have been cycled heavily in the past 24 hours and may have reduced available capacity due to temperature management limits, and which ones are on feeders that have capacity constraints that would limit dispatch on those circuits even if the asset is willing and available.
Answering those questions requires operational infrastructure: continuous telemetry from each enrolled asset, a data layer that normalizes that telemetry into a common schema, a dispatch model that calculates available capacity based on current state rather than nameplate enrollment, and a dispatch execution system that can issue asset-level signals and verify response within the commitment window.
What "dispatchable" actually means in VPP context
The word "dispatchable" is borrowed from wholesale power generation vocabulary, where it refers to a generator that can be committed to produce a specified output on demand within a defined time window. A gas peaker is dispatchable: commit it, it starts, it produces. A run-of-river hydro facility is not reliably dispatchable because its output depends on river flow.
In a VPP context, "dispatchable" means the aggregate portfolio can respond to a dispatch signal within the committed response time and sustain the committed output level for the committed duration. For ISO capacity market participation, the response requirements are typically 30-minute notification (for economic dispatch) or 10-minute (for spinning reserves). For utility-run demand response programs outside ISO markets, the program terms define the commitment, and those terms range from 2-hour event notification to near-real-time dispatch.
The portfolio-level commitment requires asset-level reliability that multiplies up. If a VPP commits 5 MW from 3,000 batteries and the average response reliability is 75% (meaning 25% of dispatched assets fail to respond as expected on any given event), the committed output is effectively 3.75 MW, not 5 MW. Program administrators and ISO settlement clerks will notice the gap. The path to reliable VPP commitments runs through higher per-asset response reliability, which requires better telemetry, better pre-dispatch SoC management, and better communication with enrolled customers about when their assets will be called.
Communication protocols and why they matter operationally
The communication layer between the VPP operator and the enrolled assets is where a lot of programs run into implementation friction that vendor marketing doesn't surface.
OpenADR 2.0b is the dominant standard for demand response event signaling in utility programs. It provides a well-tested mechanism for issuing DR event notifications to enrolled customers' EVSE, smart thermostats, and battery systems. It works at the program level: a DR event goes to all enrolled customers (or a defined subgroup), and each enrolled device responds according to its programmed logic.
OpenADR was not designed for individual asset dispatch with real-time confirmation. Issuing a signal to a specific battery asset and receiving a confirmation that the asset responded as requested within 60 seconds requires a different protocol layer. IEEE 2030.5 supports this: it includes DER monitoring and control functions that allow a utility or aggregator to read SoC, issue power set points, and verify response. But IEEE 2030.5 compliance varies by device manufacturer and vintage, and a DER fleet assembled from customer installations over multiple years will have assets at different compliance levels.
In practice, a mature VPP operation typically runs multiple communication paths simultaneously: OpenADR for program-level event signaling, IEEE 2030.5 for real-time monitoring and dispatch confirmation on compliant assets, and vendor API integrations for assets that don't implement either standard directly. Managing these three paths, normalizing the response data they return, and presenting a coherent operational view across all enrolled assets is the data infrastructure problem that VPP software needs to solve.
Settlement and accounting in VPP programs
For utility-run VPPs that participate in ISO markets, settlement adds a layer of operational complexity that pure program-performance metrics don't capture. The VPP commits a resource in the day-ahead market (or real-time market). When the ISO dispatches the commitment, the VPP must deliver. The settlement is based on the metered output of the committed resource against the committed quantity, with financial penalties for under-delivery and credit for over-delivery depending on the market rules.
Accurate settlement requires per-asset metering data that maps to ISO meter point registrations, time-stamped dispatch event records showing when each asset received a dispatch signal and when it responded, and aggregate delivered energy calculations aligned with the ISO settlement interval structure (typically 5-minute intervals for energy, sometimes hourly).
This documentation requirement shapes the data architecture of a VPP operations platform: every dispatch event needs an audit trail that goes from the ISO dispatch notification, through the VPP operator's dispatch decision, to the individual asset signals issued, to the asset-level telemetry confirming response, to the metered output used in settlement. Missing any link in that chain creates settlement disputes that are time-consuming to resolve and create uncertainty in the program's financial performance tracking.
Realistic scale for early VPP programs
There is a tendency in industry discussions to present VPP programs at the scale of California statewide initiatives or multi-state aggregator programs, which can represent hundreds of megawatts. For utility operations teams at municipal utilities, cooperatives, or regional distribution companies evaluating whether to run their own VPP, those reference points can be misleading about what it takes to get started.
A VPP program that enrolls 500 to 1,000 customers with solar-plus-storage assets and commits 2 to 4 MW to the utility's peak demand management program is operationally significant and achievable. It requires a telemetry platform capable of handling continuous telemetry from 1,000 endpoints, a dispatch system that can issue and confirm individual asset signals, and program management tooling for enrollment, customer communication, and event reporting. It does not require the infrastructure of a grid-scale aggregator.
Starting with a well-instrumented pilot program of 100 to 200 assets, validating the telemetry and dispatch confirmation reliability before scaling enrollment, and building the operational documentation habits that ISO settlement will eventually require is a more durable path than enrolling 3,000 customers and discovering response reliability gaps at the first peak event. The software infrastructure that supports 200 assets well scales to 2,000; the software that can barely manage 200 does not.