**5.1 SKED optimization engine**

90 Renewable Energy – Trends and Applications

The relative increment (RI) in load is used to help capture the load features in the method since it removes a first-order trend and anchor the prediction by the latest load (Shamsollahi et al., 2001). After normalization, the *RI* in load of last time period *z(t)* is denoted as the input to the NN, where time t is the time index. The mixing weight *µ(t)* can

3

() () () *j j jj j j*

where *p* is the transition probability to be configured manually. *S1*, *S2* and *S3* are sample covariance matrices from Forecasts 1, 2 &3 derived from historic forecasting accuracy. Without loss of generality, we assume that dynamic covariance matrices *S2D* for Forecast 2 and *S3D* for Forecast 3 are available. To make a stable combination, the dynamic innovation matrices *S2D* from Forecast 2 and *S3D* from Forecast 3 are not used to calculate

*t tc tc*

3

1

*i where c p t j* 

Then predictions from individual models can be combined to form the forecast:

3

1 ( 1| ) ( 1| ) *<sup>j</sup> <sup>j</sup> j zt t t z t t* 

The output *z(t+1|t)* from NNs has to be transformed back due to the RI transformation on the load input. Similar to the prediction combination, the static covariance matrix *S1* derived from historic forecasting accuracy and dynamic covariance matrices *S2D* and *S3D* will also be combined. Here, *S1 S2D* and *S3D* are the covariance matrices for NN outputs (estimated RI in load). Since RI is a nonlinear transformation, the covariance matrix has to be transformed. If *S1 S2D* and *S3D* can be obtained directly from individual models, they

( 1) ( 1) 11 22 33 ( 1) ( 1) *D D St t S t t S t t S t*

Then*, S(t+1)* will be used to further derive CIs with respect to *RI* transformation (Guan et al.,

Demand forecast and its corresponding confidence intervals are crucial inputs to the Generation Control Application which robustly dispatch the power system using a series of

Generation Control Application (GCA) is an application designed to provide dispatchers in large power grid control centers with the capability to manage changes in load, generation,

1

 

*<sup>j</sup>* ( 1) 1,2,3 *ij i*

*<sup>j</sup>*(t), with superscript *j*=1, 2, 3 representing

*j j* ( ) ( ); | 1 , ( )] *t N zt z t t S t <sup>j</sup>* , (17)

,

*<sup>3</sup>*since *S2D* and *S3D* may largely affects the mixing weight.

. (19)

  (20)

, (18)

be calculated through the likelihood functions

*2* and 

Forecasts 1, 2 &3 respectively:

likelihood functions

can be combined first:

coordinated scheduling functions.

**5. Generation control application** 

2010).

SKED is a Mixed Integer Programming (MIP) / Linear Programming (LP) based optimization application which includes both unit commitment and unit dispatch functions. SKED can be easily configured to perform scheduling processes with different heart beats and different look-ahead time. A typical configuration for GCA includes three SKED sequences:


Traditionally, due to the uncertainty in the demand and the lack of compliance from generators to follow instructions, RTOs have to evaluate several dispatch solutions for different demand scenarios (low (L), medium (M) and high (H)). Figure 4 depicts such practice for real-time dispatch. Except for the initial conditions (e.g. MW from State Estimator (SE)), the solutions are independent. The operators have to choose to approve one of the three load scenarios based on their human judgments on which scenario is more likely to occur.

The conventional way of dealing with the demand uncertainty is stochastic optimization (Wu et al., 2007; Verbic and Cañizares, 2006; Ruiz et al., 2009). The data requirements of stochastic optimization, makes it more appropriate to solve longer term problems, e.g. expansion and operational planning, including day-ahead security constrained unit commitment process. However, the simplicity and flexibility of the solution proposed in this chapter makes it more practical for real-time dispatch.

Fig. 12. SKED 2 and SKED 3 Coordination

#### **A. Single interval dispatch model**

The traditional single interval dispatch model is formulated as a Linear Programming (LP) problem:

$$\begin{aligned} &\quad \underset{i}{Minimize} \\ &\quad \sum\_{i} (c\_i \ast P\_{\mathcal{G}\_i}) \end{aligned}$$

$$\begin{aligned} &\text{subject to} \\ &\sum\_{i} P g\_{i} = D m \\ &P g\_{i}^{\text{min}} \le P g\_{i} \le P g\_{i}^{\text{max}} \\ &-(time - time\_{SE}) \ast R R D n\_{i} \le P g\_{i} - P g\_{i \to E} \le (time - time\_{SE}) \ast R R L p\_{i,t} \\ &- F\_{k}^{\text{max}} \le \sum\_{i} D f \text{ax}\_{Fk,i} \ast P g\_{i} \le F\_{k}^{\text{max}} \end{aligned} \tag{21}$$

where

*<sup>i</sup> c* Offer price for resource *i*

*Pgi* Dispatch level for resource *i*

*Dm* Demand forecast for target time

min max , *Pg Pg i i* Min and max dispatch level for resource *i*

max *Fk* Line/flowgate *k* transmission limit

*D Fk i*, *fax* Sensitivity of line/flowgate *k* to injection *i* (demand distributed slack)

*time* Target time

*SE time* State Estimator time stamp

*RRDni* Maximum ramp rate down for resource *i*

*RRUpi* Maximum ram rate up for resource *i*

Fig. 13. Three independent dispatch solutions

#### **B. Dynamic dispatch model**

92 Renewable Energy – Trends and Applications

The traditional single interval dispatch model is formulated as a Linear Programming (LP)

*Minimize c Pg*

\**i i*

*SE i i iSE SE i t*

,

(21)

*i*

( ) \* ( ) \*

*time time RRDn Pg Pg time time RRUp*

Fig. 12. SKED 2 and SKED 3 Coordination

min max

*i ii*

*Pg Pg Pg*

*i*

*i i*

max *Fk* Line/flowgate *k* transmission limit

*RRDni* Maximum ramp rate down for resource *i RRUpi* Maximum ram rate up for resource *i*

*SE time* State Estimator time stamp

*subject to Pg Dm*

*<sup>i</sup> c* Offer price for resource *i Pgi* Dispatch level for resource *i Dm* Demand forecast for target time

*time* Target time

max max ,

*k Fk i i k*

*F Dfax Pg F*

min max , *Pg Pg i i* Min and max dispatch level for resource *i*

\*

*D Fk i*, *fax* Sensitivity of line/flowgate *k* to injection *i* (demand distributed slack)

**A. Single interval dispatch model** 

problem:

where

Adding the time dimension into the single interval dispatch problem above described, the basic multi-interval dispatch (dynamic dispatch) model is formulated as an extended LP problem (sub-index t is added to describe interval t related parameters and variables, as appropriate):

$$\begin{aligned} &\text{Minimize} \\ &\sum\_{t} \left\{ \sum\_{i} \left( c\_{i,t} \, \* \, P\_{\mathcal{G}\_{i,t}} \right) \* \left( Time\_{t} - Time\_{t-1} \right) / 60 \right\} \end{aligned}$$

, min max , ,, 1 , , ,1 1 , max max , , ,, ( ) \* ( ) \* \* *it t i it it it t t it it it t t i t k t Fk i i t k t i subject to Pg Dm Pg Pg Pg time time RRDn Pg Pg time time RRUp F Dfax Pg F* (22) *for t t tn* { 1,... }

Figure 13. illustrates the dynamic dispatch model with multiple scenario runs.

#### **C. Robust dispatch model**

A more robust solution that co-ordinates the three demand scenarios, guaranteeing the "reach-ability" of confidence interval of demand forecast from the medium demand dispatch is proposed.

The solution would provide a single robust dispatch, guaranteeing that the dispatch levels for the low and high demand scenarios can be reached from the dispatch corresponding to the medium (expected) demand scenario within consecutive intervals in the study horizon, e.g. avoiding extreme measures like demand curtailment if the high demand scenario materializes and it is too late to catch up. The robust solution proposed is depicted in Figure 14. The cost of Robust Dispatch will be higher than ordinary dispatch using medium load level. It can be justified as a type of ancillary services for load following.

A further refinement to the proposed solution is to limit the cost of the "robustness" and specify a merit order of the intervals in which robustness is more valuable.

Fig. 14. Robust dispatch solution

The following LP problem co-ordinates the three demand scenarios into one "robust" solution. The objective function and constraints corresponding to the medium demand scenario are the same as those of an independent dynamic dispatch (M only); for the high and low demand scenarios, however, while the objective function terms are the same as those of independent dynamic dispatches (H only and L only), the maximum ramp rate constraints for each resource do not link dispatch levels of consecutive intervals for the same scenario (H→H, L→L); instead, for a given interval t such constraints link the H and L dispatch levels with the dispatch level corresponding to the M scenario in the preceding interval t-1 (M→H and M→L); guaranteeing the "reach-ability" of the low and high demand scenarios dispatches from the medium demand dispatch level in successive intervals (upper and lower case h, m and l are used as extensions to describe high, medium and low demand scenarios parameters and variables).

The solution would provide a single robust dispatch, guaranteeing that the dispatch levels for the low and high demand scenarios can be reached from the dispatch corresponding to the medium (expected) demand scenario within consecutive intervals in the study horizon, e.g. avoiding extreme measures like demand curtailment if the high demand scenario materializes and it is too late to catch up. The robust solution proposed is depicted in Figure 14. The cost of Robust Dispatch will be higher than ordinary dispatch using medium load

A further refinement to the proposed solution is to limit the cost of the "robustness" and

The following LP problem co-ordinates the three demand scenarios into one "robust" solution. The objective function and constraints corresponding to the medium demand scenario are the same as those of an independent dynamic dispatch (M only); for the high and low demand scenarios, however, while the objective function terms are the same as those of independent dynamic dispatches (H only and L only), the maximum ramp rate constraints for each resource do not link dispatch levels of consecutive intervals for the same scenario (H→H, L→L); instead, for a given interval t such constraints link the H and L dispatch levels with the dispatch level corresponding to the M scenario in the preceding interval t-1 (M→H and M→L); guaranteeing the "reach-ability" of the low and high demand scenarios dispatches from the medium demand dispatch level in successive intervals (upper and lower case h, m and l are used as extensions to describe high, medium and low demand

level. It can be justified as a type of ancillary services for load following.

Fig. 14. Robust dispatch solution

scenarios parameters and variables).

specify a merit order of the intervals in which robustness is more valuable.

$$\begin{aligned} \text{Minimumize} \\ \sum\_{t} \left\{ \sum\_{i} \left( c\_{i,t} \, \* \, P \mathcal{g} m\_{i,t} \right) \* \left( time\_{t} - time\_{t-1} \right) / 60 \right\} \\ + \sum\_{t} \left\{ \sum\_{i} \left( c\_{i,t} \, \* \, P \mathcal{g} l\_{i,t} \right) \* \left( time\_{t} - time\_{t-1} \right) / 60 \right\} \\ + \sum\_{t} \left\{ \sum\_{i} \left( c\_{i,t} \, \* \, P \mathcal{g} l\_{i,t} \right) \* \left( time\_{t} - time\_{t-1} \right) / 60 \right\} \end{aligned}$$

, min max , ,, 1 , , ,1 1 , max max , ,, , , ( ) \* ( ) \* \* *it t i it it it t t it it it t t i t k t Fk i t i t k t i Pgm Dm Pg Pgm Pg time time RRDn Pgm Pgm time time RRUp F Dfax Pgm F* , min max , ,, 1 , , ,1 1 , max max , ,, , , ( ) \* ( ) \* \* *it t i it it it t t it it it t t i t k t Fk i t i t k t i Pgh Dh Pg Pgh Pg time time RRDn Pgh Pgm time time RRUp F Dfax Pgh F* (23) , min max , ,, 1 , , ,1 1 , max max , ,, , , ( ) \* ( ) \* \* *it t i it it it t t it it it t t i t k t Fk i t i t k t i Pgl Dl Pg Pgl Pg time time RRDn Pgl Pgm time time RRUp F Dfax Pgl F* 

*for t t tn* { 1,... }

It is important to note that there is certainly a tradeoff between cost and robustness for any given robust dispatch solution using the methodology proposed above. Figure 15 illustrates the conceptual idea of relationship between cost and flexibility which is proportional to robustness. The value of the "∆cost acceptable" will be very much dependent on the amount of risk one is willing to take for reliability purposes when dispatching the system.

#### **5.2 SKED and COP coordination**

GCA is built upon a modular and flexible system architecture. Although different SKED processes are correlated, they do not replay on each other. The orchestration between SKEDi is managed by COP. This design enables low-risk, cost-effective business process evolution. It also ensures high availability for the mission critical real-time GCA SKED functions. Failure of any one or more SKED components will cause smooth degradation of, instead of abrupt service interruptions to, real-time dispatch instructions.

Fig. 15. Robustness vs. Cost

COP is the repository of all operating plans in a multi-stage decision process. Each SKEDi in the decision process generates a set of schedules that are reflected in its corresponding COP (COPi). The aggregated results from the multi-stage decision process are captured in the total COP (COPt), which is the consolidated outcome of the individual COPi's. SKED and COP coordination is illustrated in Figure 16.

Initialization of the COP for each operating day begins with the day-ahead schedule, which is based on the DAM financial schedules and then updated with Reliability Commitment results. Before any SKEDi is run in the current day of operation, the overall COPt is initialized with the day-ahead schedules. When COPt is suitably initialized, it will be used to generate input data for SKED1, SKED2 and SKED3. Results of SKEDi's are then used to update their respective subordinate COPi, which will cause COPt to be updated, and thus the overall iterative process continues.

Fig. 16. SKED and COP Coordination

It also ensures high availability for the mission critical real-time GCA SKED functions. Failure of any one or more SKED components will cause smooth degradation of, instead of

COP is the repository of all operating plans in a multi-stage decision process. Each SKEDi in the decision process generates a set of schedules that are reflected in its corresponding COP (COPi). The aggregated results from the multi-stage decision process are captured in the total COP (COPt), which is the consolidated outcome of the individual COPi's. SKED and

Initialization of the COP for each operating day begins with the day-ahead schedule, which is based on the DAM financial schedules and then updated with Reliability Commitment results. Before any SKEDi is run in the current day of operation, the overall COPt is initialized with the day-ahead schedules. When COPt is suitably initialized, it will be used to generate input data for SKED1, SKED2 and SKED3. Results of SKEDi's are then used to update their respective subordinate COPi, which will cause COPt to be updated, and thus

abrupt service interruptions to, real-time dispatch instructions.

Fig. 15. Robustness vs. Cost

COP coordination is illustrated in Figure 16.

the overall iterative process continues.

Fig. 16. SKED and COP Coordination

GCA aims at enhancing operators' forward-looking view under changing system conditions (generation capacity, ramp capability, transmission constraints, etc.) and providing operators with a "radar-type" of recommendation of actions such as startup or shutdown of fast-start resources in near real-time. As shown in Figure 17 – COP review display, various startup and shutdown recommendations are approaching the "now" timeline like an 1 dimensional radar sorted by likelihood ranking from top to bottom. The COP review display also shows actual system total generation and comparing against demand forecast and system ramp constrained capacity. This provides situation awareness of any potential abrupt ramping events or potential system imbalance and alerts operators in advance if any actions need to be taken.

Fig. 17. Forward-looking view presented by COP Overview
