How We Designed a Dispatch Architecture That Works With ISO Market Signals

When we started designing the dispatch system, we had a clear objective: integrate real-time ISO market price signals into a geothermal unit's routing decisions in a way that created genuine economic value for the industrial site operator. The technical problem we did not fully anticipate was the latency profile of ISO market data APIs, which is substantially different from what most software engineers working in other domains would expect. This article is a detailed account of what we built, why we built it the way we did, and what we would do differently with a year of operational data behind us.

The Latency Problem With ISO Data Feeds

CAISO publishes real-time 5-minute locational marginal prices through its OASIS API. PJM publishes similar real-time data through its Data Miner API. The published data intervals are 5 minutes, and the publication latency, the delay between when the interval closes and when the data is available on the API, runs from 2 to 15 minutes depending on the interval type and the API endpoint. Real-time LMP data typically has 3 to 8 minute publication latency. Day-ahead prices are available well before the operating day.

For a dispatch system designed around second-to-second control decisions, 3 to 8 minutes of data staleness is a significant constraint. We are not making speculative trading decisions where an 8-minute-old price has no value. We are making routing decisions where the relevant question is: is grid power currently cheap enough that I should pull from the grid and save my geothermal output for a higher-price period, or is grid power expensive enough that I should maximize geothermal output and sell excess to the grid? An 8-minute-old price is directionally useful but does not tell you what the market is doing right now.

The solution we implemented is a two-layer price model. The first layer is the real-time API data, which we pull on a 5-minute polling cycle and use as the baseline. The second layer is a short-horizon price forecast that we train on historical LMP data for the specific pricing node and update daily. The forecast gives us a probabilistic estimate of where the LMP is likely to be over the next 15 to 60 minutes, conditioned on the most recent confirmed data point. The dispatch decision uses a weighted combination of the confirmed price and the forecast price, with the weighting shifting toward the forecast as the time since last confirmed data grows.

This is not an elegant solution. It is a pragmatic response to the fact that the ISO data infrastructure was designed for energy market participants whose decision timescales are measured in minutes and hours, not milliseconds. We are adapting to infrastructure we do not control.

System Architecture Overview

The dispatch system runs as a set of services on edge hardware installed at the geothermal unit site. We chose edge deployment rather than cloud because the physical control path, the connection from the dispatch decision to the heat exchanger routing valve, must be local to the equipment. A dispatch decision that depends on a round trip to a cloud service introduces network latency variability that is unacceptable for time-sensitive control decisions. The cloud is used for data aggregation, monitoring, and model updates, not for the real-time control loop.

The core dispatch loop runs on a 50-millisecond cycle. At each cycle, the loop reads the four input signals (formation temperature, grid price, site demand, thermal headroom), evaluates the dispatch objective function, and issues a control command to the routing valve if the objective function indicates a change from the current state. In practice, the dispatch state changes infrequently. Most cycles result in no change. The 50-millisecond cycle rate is a safety mechanism, ensuring that the system can respond quickly when conditions change, not a reflection of how often routing changes actually occur.

The physical control interface is a Modbus TCP connection to the heat exchanger's programmable logic controller. The PLC handles the low-level valve actuation. The dispatch system provides the setpoint command: route X megawatts to site, route Y megawatts to grid, maintain thermal headroom above threshold Z. The PLC translates that setpoint into valve position commands and monitors safety interlocks.

The ISO Market Signal Integration: What Actually Works

We have CAISO integration deployed and operational. PJM integration is in testing. The CAISO integration uses the OASIS API with an authenticated access credential, polling the SP15 or ZP26 pricing zone depending on the site location. We pull three data types: the most recent 5-minute real-time LMP, the next 24 hours of day-ahead LMP, and the most recent 15-minute ancillary services clearing prices for spinning reserve and non-spinning reserve, where the site is eligible to participate.

The day-ahead prices are the most actionable for dispatch planning. A geothermal unit that knows the expected price profile for the next 24 hours can pre-position its thermal headroom to have maximum output available during high-price hours and to run at minimum output during low-price hours, managing the formation's thermal recovery in a way that maximizes revenue. This is essentially the same strategy a pumped hydro operator uses, adapted for thermal constraints rather than water constraints.

The ancillary services market integration is the most technically interesting component but also the most site-specific. Geothermal units can provide spinning reserve capacity under some ISO market rules because they can ramp from current output to rated output within the 10-minute spin reserve activation window. However, ISO eligibility requirements for spinning reserve vary by RTO and by the characteristics of the resource. We are not advertising ancillary services participation as a standard feature because the eligibility determination requires case-by-case review with the ISO. For sites where it is applicable, it represents meaningful additional revenue potential.

What We Got Wrong in the First Version

The first version of the dispatch system treated the price forecast as a black box prediction. The dispatch logic asked: is the forecast price above my threshold? If yes, route to grid. If no, route to site. This worked reasonably well when the price forecasts were accurate but produced suboptimal decisions in periods of forecast error.

The issue is that price forecast errors and dispatch errors compound. If the forecast incorrectly predicts high prices for the next hour and the dispatch system responds by drawing down thermal headroom to maximize output, you have both a forecast error and a depleted thermal buffer at the moment when market conditions revert. The correction we made was to add a thermal headroom floor to the dispatch logic: regardless of the price signal, the system maintains a minimum headroom percentage that is available for site demand response. The price optimization operates only on the thermal capacity above that floor.

This limits the economic optimization potential slightly but substantially improves the reliability of the site demand management function. Since the primary value proposition for our industrial customers is reliable baseload supply and demand charge management rather than energy market arbitrage, the tradeoff is correct.

Monitoring and Observability

The edge hardware sends telemetry to our operations platform at a 1-minute aggregation interval. The telemetry stream includes formation temperature readings, dispatch state, current output, grid price history, and site demand actuals versus forecast. This data feeds into monitoring dashboards that the site operator and our operations team can access.

One thing we learned early: industrial site operators are not interested in the internal state of the dispatch system. They want to know whether the unit is operating, whether it is meeting the site's power needs, and what the economic performance looks like month to date. The detailed dispatch logic is visible to our engineering team for diagnostic purposes but is abstracted behind an operational status dashboard for site operators. This was a user experience decision that required some iteration to get right.

Where We Are Going

The next phase of the architecture work is improving the load forecast model, particularly for sites with variable production schedules. We are also working on MISO integration, which involves a different API architecture than CAISO and PJM and requires some interface development work. Longer term, we are evaluating direct demand response program enrollment through ISO demand response aggregators, which would allow the dispatch system to participate in grid frequency regulation programs in addition to energy and ancillary services markets. That path has meaningful revenue potential for sites with sufficient output headroom but requires a more sophisticated control architecture than the current version supports.