From Device Maker to VPP Operator: DER Aggregation for Your Own Fleet
A US battery or inverter maker’s device cloud already knows its installed fleet unit by unit: serial number, firmware version, state of charge, last check-in. The same console can push a firmware update to every device overnight. What it rarely shows is which of those devices earn money in utility programs, and who is paid when they do.
That information sits with whoever does the DER aggregation: enrolling many distributed energy resources (DERs), such as batteries, inverters, and EV chargers, and operating them as one resource that a utility program can dispatch and pay for. For many US device makers, that party is someone else. The equipment carries the original equipment manufacturer’s (OEM’s) brand, but when the grid calls, the answer comes from a third-party aggregator.
That made sense when every device family, utility program, and protocol version arrived as its own engineering project. Much of the standards work behind OEM fleet aggregation can now start from pre-built, tested code. Once it can, the question for an OEM moves from “which aggregator do we sign with” to “which parts of this chain should be ours.”
Key takeaways
- An aggregator offer takes more than dispatch: enrollment, the margin on spare capacity, and the customer relationship usually go with it.
- Running your own virtual power plant (VPP) needs four capabilities: enrollment, dispatch, the program interface, and settlement.
- None needs a full distributed energy resource management system (DERMS) procurement to start. One device family on one utility program is enough.
- For a small fleet with no program roadmap and nobody to run events, an aggregator remains the right call.
When Your Installed Fleet Becomes a Grid Asset
Installers ask whether their customers’ systems can join the utility’s virtual power plant program. Then an aggregator calls: expose an application programming interface (API), and it will handle enrollment, dispatch, and program paperwork for a revenue share.
Inside the OEM, that offer usually lands as an integration ticket. Engineering scopes the API. Product sees a feature customers asked for. Legal reviews a revenue-share agreement. Each step is reasonable, and none is framed as a decision about who operates the fleet.
A connected fleet has a device cloud, remote commands, over-the-air firmware updates, and telemetry. Inverters sold into California must already follow IEEE 2030.5 commands under Rule 21, either natively or through a gateway or aggregator. The distance from “our device speaks the protocol” to “we operate the fleet” is shorter than it looks.
What Changes Hands in a Third-Party Aggregator Offer
Flexibility from a device fleet moves through three links: integrate, orchestrate, monetize. Integration connects devices and returns their data. Orchestration decides which devices respond to which event, and by how much. Monetization turns that response into payment.
Most OEMs own the first link partly, rent the second, and hand the third away. Few chose that on purpose. The first link looked so expensive that owning the rest never reached the agenda, and aggregation became an energy aggregator’s business by default.
The integration cost explains how OEMs got here. The decision that matters sits in the middle link, because three things travel with it:
- Control of enrollment and dispatch. The aggregator decides which customers are enrolled, which events the fleet accepts, and how deeply devices respond, within the API contract’s limits.
- The margin on spare capacity during a demand response event. The program pays the aggregator, which passes on a contractual share. How demand response aggregators make money shows the other side of the deal.
- The customer relationship while the event runs. The notification, the opt-out, and the explanation when a battery ends the evening lower than expected come from whoever runs the event. The support call still comes to the OEM.
The offer transfers an operating role and deserves to be negotiated as one.
The Four Capabilities an OEM Needs to Run DER Aggregation on Its Own Fleet
OEM fleet aggregation needs four capabilities. Virtual power plant software covers the full platform around them.
Enrollment and device identity
A program pays for a specific device at a specific service point, owned by a customer who agreed to take part. Enrollment joins the device’s serial number to the utility’s meter and account, checks eligibility by territory, model, and firmware, and keeps a consent record the program will accept. It sounds administrative, and it is where programs gain or lose capacity, which is why enrollment decides VPP programs.
Dispatch and control
Dispatch turns an event’s window and signal into device commands: which batteries discharge and how deep, which chargers pause, which loads shift. It has to respect state of charge, the customer’s backup reserve, warranty limits, and devices already offline. Here the OEM holds a real advantage. It knows the device’s operating limits best, and it pays the warranty claim if those limits are exceeded.
The utility program interface
Device manufacturer participation in demand response programs depends on speaking each program’s protocol. In the US, OpenADR 2.0b is widely used for utility demand response signaling, and IEEE 2030.5 is widely used for DER communication, most visibly with the Common Smart Inverter Profile (CSIP) under California’s Rule 21.
Facing the utility, the fleet usually appears as one client: an OpenADR virtual end node (VEN), or an IEEE 2030.5 client acting for the aggregate. Facing its own devices, an operator can run the server end: an OpenADR virtual top node (VTN) or a 2030.5 server.
This layer made aggregation look like someone else’s job. Codibly builds it as accelerators. Codibly’s VTN product, Codibly OpenADR VTN 2.0b (Firmware 1.0), is OpenADR 2.0b certified by the OpenADR Alliance (1 September 2026, VTN Test Plan 1.1.7). The OpenADR VEN and VTN accelerators cover both ends of the program interface, and the VEN accelerator is pre-certified. For IEEE 2030.5, Codibly builds both the client side and the server side, starting from its IEEE 2030.5 accelerator. In client work, the client’s product goes on the register and Codibly gets it there. Codibly is also a SunSpec Alliance Authorized Test Laboratory, so it can run IEEE 2030.5 and CSIP conformance testing directly.
The interface also carries evidence. Utilities that run several programs increasingly check each aggregator’s reports against meter data and enrollment lists, one part of what utilities now ask for across programs. Whoever operates the fleet has to pass those checks.
Measurement and settlement
Programs pay for measured performance, usually against a baseline of what the device would have done anyway. OEMs already collect per-device telemetry. The work is making it settlement grade: consistent timestamps, retention, gap handling, the program’s reporting format, and reconciliation against the program’s own figures. A gap in the data during an event becomes a gap in the payment.
Why OEM Aggregation Does Not Start With a Full DERMS Procurement
A DERMS serves a utility’s view of the grid: a network model, feeder constraints, and hosting capacity. The differences between DERMS, VPP, and ADMS matter when a utility chooses that architecture. An OEM enrolling its own devices in one program asks a narrower question.
For one device family and one program, the four capabilities fit around what the OEM already runs: enrollment in the customer app, dispatch beside the device cloud, the program interface on pre-built code, and settlement on existing telemetry.
A procurement-first approach asks the OEM to specify requirements it has not yet learned: how reliably its fleet responds, how customers use opt-outs, how clean its telemetry is under settlement rules. A pilot answers those questions first.
An OEM that plans to aggregate other brands’ devices across many utilities and wholesale markets is building an aggregation business, and the platform question will return. It returns later, with pilot evidence behind it.
A Staged Path: One Program Pilot, Then Widen the Fleet
An OEM-run VPP grows in stages, and the effort moves from building toward operating.
| Stage | Scope | What it asks of engineering | What it proves |
|---|---|---|---|
| 1. Feasibility | Fleet audit against one target program | A telemetry quality check, a review of the control paths the firmware exposes, and a map of the installed base by utility territory | Whether one program fits the fleet as it stands |
| 2. Pilot | One device family, one program | Backend owns the program interface and dispatch. Firmware confirms control paths and device limits. Product owns enrollment. A named person owns event operations | That the fleet responds reliably and settlement reconciles |
| 3. Widen the fleet | More device families and firmware generations, same program | A device abstraction layer, per-family control profiles, and regression testing across firmware versions | That dispatch logic works beyond the first product |
| 4. Add programs | More utilities, possibly a second protocol | Protocol version management, conformance testing cycles, and repeatable program onboarding | That aggregation is a product line with its own roadmap |
Teams most often underestimate event operations. Events run on the grid’s schedule: hot afternoons, cold mornings, holiday weekends. Someone has to watch the fleet, chase devices that fail to respond, and answer customers the next day. That load grows with every program added and is the clearest test of whether the organization wants to be a VPP operator.
When the stage 2 program interface starts from pre-built code that comes with its source, stage 4 builds on the pilot instead of replacing it.
When Handing Your Fleet to an Aggregator Is the Right Call
Owning aggregation is a real commitment, and for many OEMs a demand response aggregator is the better answer. Four situations point that way.
- The fleet is small or scattered. Many programs set a minimum aggregate size, and a fleet spread thinly across many territories may reach it in none. A DER aggregator can pool your devices with others.
- There is no program roadmap. If one program is the whole plan, an operating capability built for it has nothing to grow into.
- Nobody can carry operations. Event coverage, settlement disputes, program renewals, and conformance retesting all need an owner. A team committed to the product roadmap cannot absorb them on the side.
- Diversity matters to the program. An aggregator’s mixed portfolio spreads risk across brands. A single-brand fleet carries correlated risk: one firmware defect or cloud outage can take every enrolled device out of an event at once.
There is also a middle path. An OEM can hand dispatch and market access to an aggregator while keeping the enrollment records, the customer notification path, and a standards-based interface on its own side. The arrangement then stays a contract the OEM can renegotiate or leave, so its exit terms matter as much as the revenue share.
Next Step: A Fleet Aggregation Feasibility Review
A Fleet Aggregation Feasibility Review maps where your devices sit on the integrate, orchestrate, monetize chain, which program is a realistic first pilot, and what the four capabilities would ask of your engineers. It can also conclude that an aggregator is the better route.
Teams choosing partners for power systems that support demand response participation usually weigh protocol depth at both ends of the program interface, experience with demand response program integrations, and the commercial terms around the code. Codibly’s accelerator terms are plain: the client owns the source code, pays a one-time license, and faces no lock-in.
The next event your fleet receives will get a reply from someone. A Fleet Aggregation Feasibility Review is the place to decide, deliberately, who that should be.
Frequently Asked Questions
DER aggregation groups many distributed energy resources, such as batteries, inverters, thermostats, and EV chargers, and coordinates them with software so they respond to grid needs as one resource. The coordinated group is often called a virtual power plant (VPP). In the US, most VPPs are run by utilities or third-party aggregators. In an OEM-run VPP, the device maker operates the aggregation for its own installed fleet: it enrolls customers, dispatches devices during events, speaks the program’s protocol, and settles performance with the program.
Usually enrollment, dispatch decisions within agreed device limits, the program interface to the utility, and settlement. The program pays the aggregator, which passes on the share its contract with the OEM sets. The aggregator often owns customer communication during events as well. Terms vary, so the data rights, customer contact rules, and exit provisions in the contract deserve as close a reading as the revenue split.
It depends on the program and the device. OpenADR 2.0b is widely used for utility demand response signaling, with the fleet typically appearing as a VEN to the utility’s VTN. IEEE 2030.5 is widely used for DER communication, most visibly with CSIP for inverter-based resources under California’s Rule 21. Many programs add their own enrollment or API requirements on top, so check the specific program’s technical requirements before scoping the work.
There is no single threshold. The useful test is whether one program, in a territory where the fleet is concentrated, can meet that program’s minimum enrollment and justify the effort of running events. A large fleet scattered across many utilities can fail that test. A smaller fleet concentrated in one territory with an active program can pass it. The answer comes from your own installed base and program map.
Yes, and it is usually the right way to start. One device family limits the control profiles and firmware variants to support. One program fixes the protocol, the enrollment rules, and the settlement method. The pilot shows how the fleet actually performs in events, and that evidence shapes every later decision, including whether to widen the fleet, add programs, or hand dispatch to an aggregator.