Intraday dispatch scheduling for smaller distribution operators

A small DSO may have two or three engineers covering all operational functions. Those engineers still face the same fundamental scheduling problem as large operators, where multiple full-time operations staff, dedicated dispatch desks, and integrated control room software support the work. The difference is that a lean team cannot spend an entire shift interpreting schedules and coordinating every adjustment manually.

What intraday scheduling involves

Day-ahead procurement commits generation capacity for the following 24 hours. Actual demand will not match that forecast exactly, so intraday corrections become necessary when the difference between committed capacity and the demand trajectory creates a shortage risk or material waste.

The intraday question is whether current demand and the outlook for the next 2 to 4 hours require any generation commitment to be activated, deactivated, or adjusted. If an action is needed, the operator must know which units to use, at what volume, and by which market notification deadline.

A large operator can assign an analyst to monitor telemetry, intraday market prices, refreshed forecasts, and reserve discussions with the commercial team. At a small DSO, the engineer responsible for intraday decisions may also be taking fault calls and handling network switching. That makes automation essential and leaves little room for a complicated decision surface.

The three capabilities a small operator needs

Our work with operators in the eZap Pilot tier highlighted three capabilities that are particularly important when a lean team handles intraday scheduling.

First, the system needs a clear deviation alert. It should compare actual demand with the day-ahead forecast, show what the intraday P50 forecast expects, and set that result against contracted capacity. The comparison should appear as one dashboard state: green for on track, amber for approaching threshold, and red for action required, rather than requiring the engineer to assemble it from raw telemetry.

Second, it should provide a pre-calculated adjustment recommendation. An engineer handling other work does not have time to optimise the generation unit stack during a shift. The output should state: activate Unit B for 15 MW from 14:30 to 16:00, or accept a 12 MW shortfall. The engineer can then review, approve, and communicate the choice. The decision should not depend on mental optimisation under time pressure.

Third, the tool must track market deadlines. Iberian intraday balancing markets have gate closure times that vary by product and session. Missing a gate closure while seeking additional capacity creates a genuine operational risk, so the system should show which adjustment options remain available and flag those closing within the next 30 or 60 minutes.

Why eZap built the scheduler around these constraints

The eZap dispatch prototype began as a full probabilistic schedule: a table of every generation unit and every time interval, with P10/P50/P90 bands for load and recommended commitment levels. It contained the necessary detail, but it was too much for a one-person dispatch operation during a demanding shift.

After observing how small operators used that first output, we reorganised the presentation around the three capabilities above. The full probabilistic detail remains available for post-hoc analysis and for operators who need it. The default intraday view shows the deviation state, whether it is on track, approaching, or action required, followed by the next recommended adjustment and any relevant deadline.

The underlying method did not change. It is the same forecast and optimisation engine with a different output surface. The simpler experience is an interface decision, not a reduction in the model. A clear view of a good model is more useful when the engineer is also responding to a feeder fault than a detailed interface that demands constant interpretation.

The limitation we state plainly

Intraday scheduling is harder when the generation mix has limited ramp flexibility. If contracted standby generation consists of diesel units with 20-minute startup times and 30-minute ramp-to-full times, the system can recommend only units able to respond within the available window. When demand moves away from forecast quickly, such as on a summer peak transition day, the physically achievable response may be slower than the response operations would prefer.

This is not a software problem. It is a contracted capacity and unit characteristic problem. The scheduler can work only with the units that exist, and no algorithm can make them respond faster than their physical limits. What scheduling can do within this constraint is provide earlier warning of likely shortfalls, giving the operator more lead time to activate slower-response units before the gap becomes critical. The physical constraint remains, but the available lead time improves.