Aggregating behind-the-meter solar and storage for ISO capacity market participation is not a simple data aggregation problem. It's an exercise in reconciling heterogeneous hardware, inconsistent data streams, varying interconnection arrangements, and the dispatch co-optimization constraints that arise when subscriber self-consumption competes with grid services commitment. This post covers the architectural fundamentals — what you actually need to build or source in order to operate a BTM DER aggregation that can meet ISO capacity qualification requirements.
The Heterogeneity Problem
Most community solar programs assemble their BTM asset inventory over time, often across multiple projects with different installation contractors, different inverter procurement decisions, and different local utility metering setups. A portfolio assembled over two or three years might include SolarEdge string inverters with commercial monitoring APIs on one project, Enphase microinverters with a different telemetry protocol on another, and a Generac PWRcell storage system on a third — all measured by AMI meters with different data delivery schedules from two different utility territories.
This heterogeneity is not an edge case — it's the normal operating condition for any community solar program of meaningful scale. The aggregation architecture needs to be designed around it from the start, not treated as a problem to be solved later when ISO enrollment gets close.
The core technical requirement is a normalization layer: a software component that ingests data from multiple inverter monitoring APIs and meter data sources, applies consistent unit conversions and timestamp alignment, and produces a unified asset data model that can be used for capacity modeling and ISO telemetry reporting. This layer needs to handle not just format differences but also data quality issues — missing intervals, meter read delays, inverter communication dropouts — and flag gaps for operator review rather than silently propagating bad data into capacity models.
Inverter Protocol Landscape
The three most common inverter monitoring APIs community solar operators encounter are SolarEdge (REST API with 15-minute interval data, commercial API access available), Enphase Enlighten (REST API, tiered access with rate limits at commercial tier), and SMA Sunny Portal (REST API with varying data freshness depending on gateway configuration). Generac PWRcell and sonnen are common for paired storage assets and have their own APIs. Fronius and ABB inverters appear in older commercial installations and typically export via Modbus or SUNSPEC over local network connections rather than cloud APIs.
The data freshness and reliability characteristics of these APIs differ materially. SolarEdge's commercial API is generally reliable for aggregation purposes. Enphase's residential monitoring setup, used for subscriber-level residential installs, has been known for latency and rate limiting at scale. For aggregations with thousands of Enphase assets, the data pipeline architecture needs to account for API rate limits and implement local collection via the Enphase IQ Gateway where feasible.
The important principle: don't design your aggregation architecture assuming that all inverter data will arrive on time and at the specified resolution. Design for late data, missing data, and communication dropouts as first-class operational conditions, because they will occur at scale.
Meter Data Management Integration
ISO capacity market telemetry requirements are typically expressed in terms of the metered output of the aggregated resource — not inverter-reported generation. The authoritative data source for ISO purposes is the revenue-grade meter, which in the BTM context means the AMI meter at each subscriber account, not the inverter monitoring system.
AMI meter data arrives through meter data management systems (MDMS), which are operated either by the electric distribution company or by a third-party MDM provider. For community solar programs, the typical data path is: EDC AMI meter → EDC MDMS → interval data export (Green Button Connect or utility-specific format) → program operator's data store. The interval data export is often 24-48 hours delayed for residential meters and sometimes 15-minute resolution for commercial accounts.
The 24-48 hour delay in residential AMI data creates a fundamental tension with ISO real-time telemetry requirements. ISOs expect capacity resource telemetry to be available within minutes of real-time dispatch events for performance assessment purposes. Aggregators who rely solely on AMI interval exports cannot meet this requirement and need a supplemental telemetry path — typically inverter API data, normalized and quality-checked against available AMI reference data — to provide the near-real-time telemetry the ISO requires during dispatch events.
Dispatch Co-Optimization: The Storage Layer
When BTM storage is part of the aggregated portfolio, the aggregation architecture needs to handle dispatch co-optimization — the problem of deciding how to use battery capacity at any given moment given competing priorities: subscriber self-consumption optimization, ISO capacity dispatch obligations, and revenue optimization across energy market signals.
Consider a scenario: a community solar program in the PJM territory has a 4 MW storage fleet distributed across 200 subscriber accounts, each with a 20 kWh battery. During a summer afternoon, a PJM dispatch instruction arrives requesting 2 MW of capacity dispatch from the aggregation. Simultaneously, afternoon solar generation is tapering off and subscriber self-consumption loads are increasing as people arrive home. The co-optimization problem is: which batteries dispatch for the ISO instruction, how much, and for how long — while ensuring subscriber self-consumption is not unnecessarily disrupted and state-of-charge constraints are respected for each individual battery.
This is not a problem that can be solved by a simple rule — "always prioritize ISO dispatch" creates subscriber dissatisfaction and potentially violates subscriber program agreements. "Always prioritize self-consumption" creates capacity performance shortfalls. The aggregation architecture needs a dispatch optimization layer that can evaluate the current state of each battery, the expected duration of the dispatch event, and the portfolio-level dispatch commitment, and then distribute the dispatch instruction across the fleet in a way that balances these constraints.
Asset Registry: The Foundational Data Structure
Before any of the aggregation, telemetry, or dispatch work can function reliably, the aggregation platform needs a complete and accurate asset registry — a structured data store that maps every DER in the portfolio to its relevant attributes: subscriber account ID, utility territory, interconnection type (NEM, non-NEM, shared-facility), meter point ID (MPID or equivalent), inverter manufacturer and model, storage capacity and rated power, and current operational status.
The asset registry is also the foundation for ISO enrollment documentation. PJM, ISO-NE, and NYISO all require DER aggregators to file asset inventory as part of the aggregation registration process. The format requirements vary by ISO, but all require the data elements listed above at minimum. An aggregation platform that maintains a live, ISO-synchronized asset registry can generate enrollment documentation directly — rather than requiring a manual data assembly exercise each time the asset inventory changes.
We're not saying the asset registry is technically glamorous work. It's the least exciting part of the aggregation stack. But the programs that have built clean, continuously maintained asset registries move through ISO enrollment substantially faster than those who discover at filing time that their asset data is scattered across three spreadsheets and a DER management system with no export API.
Putting the Architecture Together
A functional BTM DER aggregation architecture for ISO capacity market participation has at minimum five components: (1) an asset registry as the authoritative source of portfolio composition; (2) a telemetry normalization layer that ingests heterogeneous inverter and meter data and produces consistent, quality-checked time series; (3) a capacity modeling layer that translates normalized telemetry into ISO-reportable capacity availability estimates, accounting for ELCC adjustments and subscriber behavior variability; (4) a dispatch management layer that receives ISO dispatch instructions and distributes them across the portfolio with co-optimization against storage state-of-charge and subscriber constraints; and (5) a settlement reconciliation layer that matches ISO settlement statements against metered performance data and flags discrepancies.
Programs that are building this stack internally should plan for 18-24 months of development and integration effort before the architecture is reliable enough for ISO capacity commitment. Programs that are sourcing the stack from a third-party aggregation platform can move substantially faster — the normalization, registry, and modeling layers are where platform software creates the most leverage, not the last mile of dispatch logic, which programs often retain operationally regardless of what aggregation infrastructure they use.