There's a temptation in grid software architecture to treat the cloud versus edge question as primarily a cost optimization problem: move computation where it's cheapest. That framing misses the more important constraint in grid applications, which is latency. Some grid functions can tolerate 30-second round-trip latency to a cloud service. Others cannot tolerate more than 200 milliseconds. Getting the split right is not about minimizing cloud compute bills; it's about matching the compute location to the timing requirements of the grid function.
In practice, most DER dispatch platforms end up with a hybrid architecture whether they planned for it or not. The question is whether that architecture was designed or accumulated. This piece walks through how we think about the edge versus cloud decision for different dispatch functions, and where the real tradeoffs live.
The Timing Hierarchy in Grid Operations
Grid operations span at least five orders of magnitude in timing requirements. Understanding which functions need which latency class is the starting point for any architecture decision.
Primary frequency response (PFR) operates on a sub-second basis. When grid frequency deviates from 60 Hz, batteries and other fast-responding resources are expected to respond within 30 seconds, and high-performance assets are expected to begin responding within 4 seconds. This is governed by NERC standard BAL-003 and its ISO equivalents. For a battery participating in frequency response markets, the control logic that detects the frequency deviation and commands the inverter must run locally, at the asset. There is no cloud round-trip possible at this timescale. The edge controller is not optional; it is the only place this function can physically run.
Secondary frequency control (automatic generation control, or AGC) operates on a 4-second to 4-minute timescale. At the transmission level, AGC signals are sent directly from the ISO's energy management system to generators. At the DER level, an ISO-connected battery participating in regulation service receives a dispatch signal from the ISO every 4 seconds. The asset controller needs to receive this signal and translate it to an inverter setpoint within the signal interval. This function is typically handled by the asset controller firmware or a local edge device, not by a cloud service, because the reliability requirement for signal reception is very high and 4-second intervals don't leave room for WAN connectivity failures.
Economic dispatch decisions, the scheduling of battery charge and discharge cycles to maximize revenue or minimize cost over a day or multi-day horizon, operate on 15-minute intervals and can tolerate several minutes of computation time. These optimization problems often involve significant data inputs (load forecasts, price forecasts, state of charge across multiple assets) and computationally expensive solvers. They are well-suited to cloud execution, where you have access to more compute, better data infrastructure, and reliable storage for the inputs and outputs.
Market bidding, day-ahead and real-time market submissions, has ISO-specific deadlines. Day-ahead bids are typically due before noon for the following operating day. Real-time bids may have 5-minute or hourly submission windows depending on the market. These are not hard real-time functions, but they have fixed deadlines and failure to meet them has direct revenue consequences. Cloud is appropriate here, with appropriate reliability engineering around uptime and deadline monitoring.
What Edge Controllers Actually Do
An edge controller in a DER dispatch context is a compute device co-located with the asset or at the site level, connected to the asset via local network or serial bus, and connected to the cloud platform via cellular or broadband WAN. It runs the logic that must execute locally, and passes data and instructions between the cloud platform and the asset.
The minimum function an edge controller must handle is direct asset control: translating dispatch setpoints from the cloud platform or ISO signal into inverter commands, and reporting asset state back to the cloud. This is the basic edge function that exists in every serious DER deployment.
Beyond that minimum, there's a spectrum of functions that can optionally be pushed to edge versus kept in the cloud. The decision depends on: latency requirements, connectivity reliability, computational cost, and how often the logic changes.
Functions that benefit from edge execution: continuous state monitoring with threshold-based protective actions (over-charge protection, thermal limits), local frequency response logic if the asset is participating in fast-frequency-response markets, site-level demand limit enforcement if the aggregator has contractual peak demand obligations, and fallback dispatch logic that maintains acceptable asset operation during WAN connectivity outages.
Functions that should stay in the cloud: multi-asset portfolio optimization (too much data and compute for edge), load and generation forecasting, market bid construction, and any function requiring data from multiple sites or external feeds. These functions need access to data and compute infrastructure that doesn't exist at the edge.
The Connectivity Reliability Problem
One of the arguments for pushing more logic to edge devices is resilience against WAN connectivity failures. This argument is real but easy to over-apply.
A DER site that loses WAN connectivity to the cloud platform doesn't need to execute a portfolio-level dispatch optimization. It needs to operate its local asset in a reasonable fallback mode: continue ongoing discharge if in mid-cycle, hold state of charge within safe bounds, and reconnect and resync when connectivity restores. This fallback behavior is appropriate for edge execution. It's relatively simple logic, it doesn't require external data, and it protects the asset during outages.
What's not appropriate is trying to run a full economic dispatch algorithm locally during a connectivity outage. The algorithm needs price forecasts, load forecasts, and state from other portfolio assets, none of which are available at the edge during an outage. The correct fallback is to hold the most recent cloud-issued schedule and execute against it, not to attempt local re-optimization with stale or missing data.
The reliability engineering that matters most is not pushing more logic to edge; it's building the cloud platform with enough reliability that connectivity failures are short and infrequent, and designing the edge controller fallback behavior to be safe and conservative when they do occur.
Data Flow Architecture
The data architecture between edge and cloud is as important as the compute allocation. In a DER portfolio with 50 sites, each with an edge controller reporting asset state at 1-minute intervals, you have a significant continuous data stream flowing from edge to cloud. The cloud platform needs to process this stream, update its asset state models, and propagate updated dispatch instructions back to the edge devices, all within the 15-minute dispatch interval.
The data pipeline choices have real implications. Polling-based architectures, where the cloud periodically queries each edge device for state, are simple but don't scale well past 20 to 30 sites before latency accumulates. Pub/sub architectures, where edge devices push state updates to a message broker and the cloud subscribes, scale more naturally and decouple the cloud from individual device connectivity failures. MQTT is the dominant protocol for this pattern in DER applications, running well on constrained network connections and handling intermittent connectivity gracefully.
The dispatch instruction path runs in the opposite direction: cloud to edge. The latency requirements here are determined by the market service being provided. For day-ahead economic dispatch, instructions can be published hours ahead. For real-time economic dispatch, instructions need to arrive at least 5 minutes before each dispatch interval. For regulation service, instructions need to be received and acted on within 4 seconds. These different requirements may argue for different instruction channels: a bulk update path for day-ahead schedules and a low-latency direct TCP path for real-time regulation signals.
Where This Gets Complicated
The clean separation between "fast functions at edge, slow functions in cloud" works for homogeneous portfolios with standard asset types. It gets complicated in two scenarios: mixed asset types with very different control interfaces, and multi-tier grid services where the same asset is participating in both a fast ancillary service and an economic dispatch program.
The multi-service case is where careful architecture pays off. An asset committed to regulation service is expected to respond to AGC signals every 4 seconds. That same asset may also be dispatched for economic energy arbitrage during hours when it's not providing regulation. These two dispatch modes have different latency requirements, different data sources, and different priority rankings when they conflict. The edge controller needs a clear priority hierarchy: regulation dispatch signal overrides economic dispatch setpoints; the economic dispatch schedule is suspended during regulation service windows; safety limits override both.
Getting this priority logic right, and testing it under fault conditions, is where most real-world edge control bugs occur. Not because the individual functions are complex, but because the interactions between services under unexpected conditions reveal assumptions that weren't made explicit in the design. This is the part of edge compute architecture that takes time to get right and is worth investing in before fleet scale, not after.