PacifiCorp’s Wattsmart Battery Program is, quietly, the most consequential utility-led battery storage program in North America. It is the first at-scale US program built on IEEE 2030.5 paired with a utility-operated Distributed Battery Grid Management System (DBGMS), and its architecture is rapidly becoming the template other US utilities (APS, Xcel Energy, NV Energy, Duke) are studying as they design their own bring-your-own-battery and utility-aggregated BESS programs. The interesting story is not that one Western utility chose a particular protocol stack. The interesting story is that the rest of the US utility sector is converging on the same one.

For technology leaders inside an investor-owned utility weighing how to stand up a residential or commercial BESS aggregation program, or for VPP and aggregator platform teams selling into US utility programs, the architectural decision has been made elsewhere. The question is no longer whether to build on IEEE 2030.5 — that is now the default assumption in any serious US utility BESS program design. The question is how to implement IEEE 2030.5 specifically for battery assets, where the protocol’s BESS profile differs meaningfully from the solar/inverter implementations most teams are already familiar with. This piece breaks down what Wattsmart actually does, why PacifiCorp chose this architecture, where IEEE 2030.5 implementation looks different for BESS than for solar DER, and which utilities are next.

It builds on Codibly’s whitepaper on the BESS software stack and a companion analysis of ERCOT merchant BESS economics, where the regulatory environment is materially different.

The Wattsmart Battery Program, Decoded

Wattsmart Battery is a customer-sited battery program operated by PacifiCorp through its Rocky Mountain Power and Pacific Power utility brands across Utah, Wyoming, Idaho, Oregon, Washington, and California. Customers install qualifying behind-the-meter batteries (with their own solar PV, in most cases), and the utility receives the right to dispatch those batteries during peak events in exchange for an upfront incentive and ongoing performance payments. The program is structured as a virtual power plant (VPP): individually small assets aggregated into utility-controllable capacity, dispatched as a single grid resource for peak shaving, capacity, and reliability.

What makes Wattsmart structurally different from a typical residential battery rebate program is the integration architecture. PacifiCorp does not call individual batteries through ad-hoc APIs to inverter manufacturers. The utility runs a Distributed Battery Grid Management System (DBGMS) that communicates with every enrolled battery through IEEE 2030.5, the standardized smart-energy protocol whose Common Smart Inverter Profile (CSIP) variant has become the de facto US grid-services interface for distributed energy resources. Vendors that want to participate in Wattsmart implement an IEEE 2030.5 client that speaks to PacifiCorp’s IEEE 2030.5 server. The utility maintains a single, protocol-conformant interface; the vendor ecosystem implements clients that conform to it. That is a profoundly different operating model from the device-by-device, vendor-by-vendor integration patterns that have dominated US utility DER programs for the last decade.

The result, for PacifiCorp, is that adding new battery vendors to the program is a conformance-test exercise rather than a custom integration project. The result, for vendors, is that one protocol implementation gives them market access to the entire Wattsmart geography. The result, for the wider US utility sector, is a working example of how to scale a customer-sited battery program without scaling integration headcount linearly with vendor count.

Why PacifiCorp Chose IEEE 2030.5 + DBGMS

Three architectural pressures drive the IEEE 2030.5 + DBGMS choice for any US utility designing a customer-sited battery program at scale, and they apply equally to APS in Arizona, Xcel Energy in Colorado, NV Energy in Nevada, and Duke Energy in the Carolinas as they apply to PacifiCorp.

The vendor-count problem: a successful BYOD program will onboard dozens of battery and inverter vendors over its lifetime. Building one-off integrations for each one is unsustainable in cost, in operational support, and in security posture. A standardized protocol with a strong conformance test regime collapses the integration matrix into a clean grid-harmony architecture. The regulatory-fit problem: California’s Rule 21 has driven IEEE 2030.5 / CSIP adoption for DER interconnection across the West, and other US state PUCs are following with their own grid-code adaptations, including the Texas DER market. A utility that builds on IEEE 2030.5 inherits a regulatory tailwind rather than fighting one. The operational-data problem: a utility-operated VPP needs continuous, structured telemetry from every enrolled asset (state of charge, power available, dispatch responses, fault states) at intervals tight enough to support real-time grid operations. IEEE 2030.5’s DERControl, DERStatus, and DERAvailability function sets are designed exactly for this.

The DBGMS is the utility-side platform that consumes IEEE 2030.5 telemetry, runs the aggregation and dispatch logic, schedules and executes events, and reports back into the utility’s settlement and program-administration systems. It is where the utility’s program-design choices (event qualifying logic, performance measurement, customer comp) become operational. Different utilities will make different DBGMS build/buy/integrate choices, but the protocol layer underneath them is converging.

What IEEE 2030.5 Implementation Looks Like for BESS

For teams whose IEEE 2030.5 experience comes from solar PV and inverter integrations, BESS implementation has differences worth surfacing early in any project plan. Solar PV is, broadly, a generation asset with a controllable curtailment surface; BESS is a bidirectional asset whose state of charge is itself a system variable and whose dispatch is constrained by stored energy, throughput warranties, and degradation cost.

Capability Solar / inverter DER profile BESS profile Why the BESS implementation is different
State of charge Solar: Not applicable — generation flow is determined by irradiance and curtailment. BESS: First-class concept; reported continuously alongside available capacity. Why: The utility cannot dispatch a battery without knowing how much energy is stored, how much is reserved against other commitments, and how much is dischargeable in the relevant horizon.
Dispatch direction Solar: Unidirectional (curtailment only). BESS: Bidirectional — charge and discharge in the same DERControl, with sign conventions and ramp behavior. Why: Charge instructions support solar shifting and grid services; discharge instructions support peak shaving and capacity events. Both must be modeled in the same protocol envelope.
Capacity reservation Solar: Generally not reserved in advance. BESS: Required for capacity / reliability programs — utility schedules dispatch in advance and battery must respect the reservation. Why: Capacity-program participation depends on demonstrated availability windows; the implementation must arbitrate between scheduled reservations and any default autonomous behavior.
Performance measurement Solar: Curtailment vs. baseline. BESS: Awarded MW and energy delivered, reconciled per event. Why: Battery performance is measured against discrete event-level commitments, not against a continuous baseline. Reporting and reconciliation are richer.
BMS substrate dependency Solar: Inverter directly exposes the controllable surface. BESS: IEEE 2030.5 client sits above a BMS that must cleanly expose cell-level state, faults, and SOC estimates. Why: Protocol-conformant responses do not save an implementation whose underlying BMS cannot deliver accurate operational data; vendors fail program performance reviews on the substrate, not on the protocol.

Five differences shape the implementation work. First, state-of-charge management is a first-class concept for BESS that has no solar equivalent: the IEEE 2030.5 client must accurately report state of charge, expected available capacity over the dispatch horizon, and any constraints that limit either. Second, bidirectional dispatch means the protocol must support charge and discharge instructions in the same DERControl, with appropriate sign conventions and ramp constraints that solar inverters never need. Third, capacity reservation is required for batteries enrolled in capacity or reliability programs: the utility needs to schedule and reserve dispatch capability in advance, and the IEEE 2030.5 implementation must respect that reservation against any other autonomous behavior the battery would default to. Fourth, performance measurement for batteries is conducted against awarded MW and energy delivered, requiring richer reporting and reconciliation than the simpler curtailment-versus-baseline that solar performance is measured against. Fifth, integration with the BMS sits underneath the IEEE 2030.5 client: a vendor implementation that does not cleanly read from and write to the underlying battery management system delivers compliant protocol responses on top of operational gaps.

For Wattsmart vendors and their counterparts in upcoming US utility programs, the practical advice is to architect the IEEE 2030.5 client as a thin protocol-translation layer above a robust BMS-and-fleet-management foundation. The protocol is the easy part; the conformance and certification path itself is well-trodden. The substrate underneath is what makes a vendor reliable in front of a utility’s DBGMS, and what survives the conformance test in California, Utah, Arizona, and the next jurisdictions to arrive. Codibly has executed this exact pattern publicly: an eight-week IEEE 2030.5 CSIP certification under California Rule 21 for a BESS provider, and a multi-jurisdiction IEEE 2030.5 CSIP-Australia integration for SolarEdge across regional DNSPs, demonstrating that the same architectural pattern generalizes across grid codes when the substrate is built correctly.

The US Utility BESS Playbook, Forming

Wattsmart is not the only US utility battery program, but it is the one whose architectural decisions other utilities are explicitly studying. APS in Arizona, Xcel Energy in Colorado, NV Energy in Nevada, and Duke Energy in the Carolinas have either announced or designed programs that operate on the same fundamental shape: customer-sited batteries, utility-operated DBGMS, IEEE 2030.5 / CSIP as the device-level protocol, and a vendor conformance regime that decouples program operations from any one vendor’s integration roadmap.

Utility Service area Program IEEE 2030.5 / DBGMS architecture Status (early 2026)
PacifiCorp (Rocky Mountain Power / Pacific Power) Region: UT, WY, ID, OR, WA, CA. Program: Wattsmart Battery — customer-sited BYOD BESS aggregation. Architecture: Utility-operated DBGMS; vendor IEEE 2030.5 / CSIP clients. Status: Operational at scale; vendor ecosystem certified.
APS (Arizona Public Service) Region: AZ. Program: Cool Rewards / Battery Reward — residential battery aggregation. Architecture: IEEE 2030.5 alignment and DERMS integration in design. Status: Active program with growing battery scope.
Xcel Energy Region: CO and surrounding states. Program: Aggregated Virtual Power Plant pilot moving toward production. Architecture: Utility-controlled DERMS; standardized device interface roadmap. Status: Pilot deployments; broader rollout planning underway.
NV Energy Region: NV. Program: Customer-sited battery storage incentive program. Architecture: DERMS-integrated with standardized device profiles in design. Status: Program funded; integration architecture under design.
Duke Energy Region: NC, SC. Program: EnergyWise customer-sited battery and DR programs. Architecture: Standardized DER interface evaluation; IEEE 2030.5 in scope. Status: Active design phase as battery scope expands.

The reasons IEEE 2030.5 wins this race over proprietary or alternative protocols are direct. It is a published standard with a stable specification and an active conformance test regime. It carries California Rule 21 regulatory backing, which means the utility-scale vendor ecosystem already invests in IEEE 2030.5 conformance for inverter products, and the marginal investment to extend that to BESS is small. It supports the function sets needed for utility-controlled VPP operations (DERControl, DERStatus, DERCurve, DERAvailability) without extension. And it is independent of any specific cloud platform or vendor, which lets utilities preserve full ownership of their program architecture and customer relationships. The same logic now extends into adjacent domains: the V2G mandate trajectory for fleet operators and the multi-protocol architectural decision facing EV charging platforms are converging on the same standardized-interface logic for the same reasons.

The European parallel is instructive without being identical. European DSOs are building DER signaling infrastructure under different protocol stacks (Germany’s 14a regulation drives a different model, Nordic and Iberian DSOs have their own grid codes), but the underlying architectural insight is the same: the utility’s controllable-capacity layer needs a standardized, conformance-tested device interface, and bespoke integrations do not scale to the volumes that policy now expects. The US is converging on IEEE 2030.5; Europe is converging on its own analogues. Both are architecturally moving in the same direction.

Utility Battery Programs Are About to Look a Lot Like This One

For a utility VP of Grid Modernization, a Director of DER Integration, or a program manager designing an aggregation program in 2026, the architectural decision tree has narrowed substantially. IEEE 2030.5 is the device-level protocol. A utility-operated DBGMS is the platform layer. Vendor onboarding is conformance testing rather than custom integration. The program design choices that remain (incentive structure, event-call logic, performance windows, customer experience) are commercial and policy choices, sitting on a technology stack the industry is settling on.

For battery vendors and aggregator platforms wanting to participate in those programs, the implementation work is BMS-foundation-first, then IEEE 2030.5 client, then conformance test, then market access. Skip-stepping the BMS foundation produces protocol-conformant clients that fail in operational telemetry and lose program eligibility on the first quarterly performance review. Built correctly, an IEEE 2030.5 implementation done once for one US program is the same implementation that wins access to the next program in the next state. PacifiCorp’s Wattsmart is teaching the rest of the US sector how to scale this. The utilities and vendors who internalize the lesson early are the ones whose programs will be operational in 2027 and 2028 when the next wave of state-level battery program funding arrives.

Software-Defined BESS whitepaper promo - Codibly