System and method for determining expected unserved energy to quantify generation reliability risks

[0001] The present invention relates generally to energy generation planning systems and, more particularly, to methods and systems for determining expected unserved energy in order to quantify generation reliability risks.

[0002] In planning for energy generation adequacy, determining the optimum level of energy reserves is difficult. If a utility maintains too low of a reserve margin, there is a high likelihood of being unable to serve the demands of all firm-load customers. If a utility maintains too high of a reserve margin, much money is wasted in building and maintaining capacity that is rarely used. A new digital simulation model is needed that can quantify the risk of occurrence of a wide-range of possible scenarios in terms of expected unserved energy (EUE) and expensive market purchases required to avoid shedding firm load customers. A wider range of components that contribute to unreliability need to be modeled than would be in an application that was designed for minimizing production cost.

[0003] Almost all reliability issues are expected to occur in the upper 10% of all possible weather, load forecast error, and hydro availability scenarios. In order to achieve statistical significance, a large number of cases need to be run in a simulation that realistically models energy generation and dispatch.

[0004] The invention is directed to a method, system, and program product for quantifying the potential generation reliability risks across a wide range of scenarios. A Monte Carlo frequency and duration model is used to determine expected unserved energy (EUE) and expensive reliability purchases. Historical and projected data concerning how often and for how long existing and future generating units fail provide the basis for estimating the expected number of firm load curtailments at various reserve levels.

[0005] All of the generating unit types have different data that are required to be input into the simulation model. Operational data includes distributions on outage history, capacities and operating levels, derating information, maintenance information, energy limitations, dispatch prices, and service dates. This data must be collected and correctly input into the simulation model.

[0006] The invention differentiates dispatch based on the ratio of demand to supply. This reflects actual operational efforts to conserve energy-limited resources during times of constraint. The digital simulation draws on historical distribution of outages by duration, rather than on an annual or seasonal forecast equivalent force outage rate (EFOR) for each unit. This produces a more accurate reflection of cumulative megawatts forced offline during constrained periods. The digital simulation provides the ability to process hundreds of thousands of iterations of an entire year in a matter of hours. Furthermore, the digital simulation includes dynamic market simulation based on supply/demand, dynamic hydro-operation based on market simulation and hydro-availability, and representation of transmission constraints without load flow modeling to allow for fast processing. Other features include dispatching supplemental modes of operation for combined cycles, and modeling of capacity reduction based on weather.

[0007] In one aspect of the invention, a method, system, and computer program product are provided for quantifying a risk of expected unserved energy in an energy generation system using a computer simulation. An energy load demand forecast is generated based at least in part on a weather year model. A plurality of energy generation resources is committed to meet the energy load demand. An operating status is determined for each committed energy generation resource in the energy generation system. A determination is made as to whether or not the committed resources are sufficient to meet the energy load demand. A dispatch order for a plurality of additional energy resources is selected if the committed resources are not sufficient to meet the energy load demand. Additional resources are committed based on the selected dispatch order until the energy load demand is met. The expected unserved energy is determined and an equivalent amount of energy load demand is shed based at least in part on an expected duration of unserved energy and a customer class grouping. The computer program product implements the method for simulating deployment of a plurality of energy resources in an energy generation system to minimize an expected unserved energy. The system includes a processor executing a plurality of software components for performing the steps of the method.

[0024] The following description of the invention is provided as an enabling teaching of the invention and its best, currently known embodiment. Those skilled in the art will recognize that many changes can be made to the embodiments described while still obtaining the beneficial results of the present invention. It will also be apparent that some of the desired benefits of the present invention can be obtained by selecting some of the features of the present invention without utilizing other features. Accordingly, those who work in the art will recognize that many modifications and adaptations of the invention are possible and may even be desirable in certain circumstances and are part of the present invention. Thus, the following description is provided as illustrative of the principles of the invention and not in limitation thereof since the scope of the present invention is defined by the claims.

[0025] In an embodiment of the invention, the capabilities of an energy generation system during peak load conditions are modeled and analyzed. The modeling and analysis provide insight into the risks and costs during these periods as well as the value of being able to meet peak load conditions. The results of the analysis can be used to assist the planner in evaluating the worth of demand-side options and energy-limited resources with various constraints. Generation reliability determinations can help to mitigate the risks involved as described herein.

[0026] The following definitions of terms used in this description are provided for ease of reference by the reader:

[0027] Availability Factor (AF)—[available hours/period hours]×100(%)

[0028] Available—This is the state in which a unit is capable of providing service, whether or not it is actually in service, regardless of the capacity level that can be provided.

[0029] Available Hours—(a) sum of all service hours, reserve shutdown hours, pumping hours, and synchronous condensing hours, or; (b) period hours (PH) less planned outage hours, forced outage hours, and maintenance outage hours.

[0030] Demand-side Options (DSOs)—Demand-side options are ways that the utility can reduce demand in order to avoid unserved energy. When load is going to be greater than capacity, the options are to increase capacity or reduce load. By calling a non-firm large industrial customer to reduce load or automatically switching off a large block of residential cooling units on demand-side programs, the utility can control demand.

[0031] Economy Purchases—In many hours, there is excess capacity in the market that is below the cost of the incremental unit. This is estimated by using the economy purchase input data to simulate the availability of economy purchases.

[0032] Equivalent Forced Derated Hours—The product of the forced derated hours and the size of reduction, divided by the net maximum capacity.

[0033] Equivalent Forced Outage Rate (EFOR)—[(forced outage hours+equivalent forced derated hours)/(forced outage hours+service hours+equivalent forced derated hours)]×100(%)

[0034] Expected unserved energy (EUE)—This is the amount of firm load that is estimated to be shed in a given hour.

[0035] Forced Derated Hours—Sum of all hours experienced during forced deratings.

[0036] Forced Derating—An unplanned component failure (immediate, delayed, postponed) or other condition that requires the load on the unit be reduced immediately or before the next weekend.

[0037] Forced Outage—An unplanned component failure (immediate, delayed, postponed, startup failure) or other condition that requires the unit be removed from service immediately or before the next weekend.

[0038] Forced Outage Factor (FOF)—[forced outage hours/period hours]×100(%)

[0039] Forced Outage Hours—Sum of all hours experienced during forced outages.

[0040] Forced Outage Rate (FOR)—[forced outage hours/(forced outage hours+service hours)]×100(%)

[0041] Generation Reliability—Generation reliability is the ability of the utility system to be able to meet firm load obligations irrespective of internal transmission constraints.

[0042] Load Forecast Error (LFE)—Load Forecast Error is based on the error in estimating the non-weather related growth in the load from year to year. It is primarily economic growth that is estimated in this component. This distribution can be estimated using historical projections of load compared to actual weather-normalized peak loads.

[0043] Loss of load hours (LOLH)—This is the duration in hours over which there is unserved energy.

[0044] Loss of load probability (LOLP)—This is the probability of an EUE event occurring in a given hour. It is the number of iterations with EUE in a given hour divided by the total number of iterations.

[0045] Maintenance Derated Hours—Sum of all hours experienced during maintenance deratings and scheduled derating extensions of any maintenance deratings.

[0046] Maintenance Derating—The removal of a component for scheduled repairs that can be deferred beyond the end of the next weekend, but requires a reduction of capacity before the next planned outage.

[0047] Maintenance Outage—The removal of a unit from service to perform work on specific components that can be deferred beyond the end of the next weekend, but requires that the unit be removed from service before the next planned outage. Typically, a maintenance outage may occur anytime during the year, have flexible start dates, and may or may not have a predetermined duration.

[0048] Maintenance Outage Hours—Sum of all hours experienced during maintenance outages and scheduled outage extensions of any maintenance outages.

[0049] Net Capacity Factor (NCF)—[net actual generation/(period hours×net maximum capacity)]×100(%)

[0050] Normal Weather—Normal weather is the weather that would be expected to result in the highest load during a year and reflects a 50% probability that the weather would be more severe and a 50% probability that the weather would be less severe.

[0051] Peak Load—Peak load is the highest load for the year. When forecasting the peak load, it is done using the weather-normalized peak load.

[0052] Period Hours—Number of hours a unit was in the active state.

[0053] Planned Derated Hours—Sum of all hours experienced during planned deratings and scheduled derating extensions of any planned deratings.

[0054] Planned Derating—The removal of a component for repairs that is scheduled well in advance and has a predetermined duration.

[0055] Planned Outage—The removal of a unit from service to perform work on specific components that is scheduled well in advance and has a predetermined duration (e.g., annual overhaul, inspections, testing).

[0056] Planned Outage Hours—Sum of all hours experienced during planned outages and scheduled outage extensions of any planned outages.

[0057] Planning Reserve Margin—This is calculated as (expected peak capacity/expected peak load)−1.

[0058] Quick Start Reserves—These are generally combustion turbine units that can be ramped up in 15 minutes.

[0059] Reserve Margin—A measure of available capacity over and above the capacity needed to meet normal peak demand levels. For a producer of energy, it refers to the capacity of a producer to generate more energy than the system normally requires. For a transmission company, it refers to the capacity of the transmission infrastructure to handle additional energy transport if demand levels rise beyond expected peak levels. Regulatory bodies usually require producers and transmission facilities to maintain a constant reserve margin of 10-20% of normal capacity as insurance against breakdowns in part of the system or sudden increases in energy demand.

[0060] Reserve Shutdown—A state in which a unit is available but not in service for economic reasons.

[0061] Reserve Shutdown Hours—Sum of all hours experienced during reserve shutdowns (RS). Some classes of units, such as gas turbines, are not required to report reserve shutdown (RS) events. Reserve shutdown hours for these units may be computed by subtracting the reported service hours, pumping hours, synchronous condensing hours, and all the outage hours from the period hours.

[0062] Scheduled Derated Hours—Sum of all hours experienced during planned deratings, maintenance deratings and scheduled derating extensions of any maintenance deratings and planned deratings.

[0063] Scheduled Deratings—Scheduled deratings are a combination of maintenance and planned deratings.

[0064] Scheduled Outage Factor (SOF)—[scheduled outage hours/period hours]×100(%)

[0065] Scheduled Outage Hours—Sum of all hours experienced during planned outages, maintenance outages, and scheduled outage extensions of any maintenance outages and planned outages.

[0066] Scheduled Outages—Scheduled outages are a combination of maintenance and planned outages.

[0067] Service Factor (SF)—service hours/period hours×100(%)

[0068] Service Hours—Total number of hours a unit was electrically connected to the system.

[0069] Spinning Reserves—A portion of the North American Electric Reliability Council (NERC) required operating reserves must be spinning, meaning that the unit is online but has excess unused capacity that can be accessed quickly.

[0070] Unavailable—State in which a unit is not capable of operation because of the failure of a component, external restriction, testing, work being performed, or some adverse condition.

[0071] Unavailable Hours—Sum of all forced outage hours, maintenance outage hours, and planned outage hours.

[0072] Unplanned Derated Hours—Sum of all hours experienced during forced deratings, maintenance deratings, and scheduled derating extensions of any maintenance deratings.

[0073] Unplanned Outage Hours—Sum of all hours experienced during forced outages, maintenance outages, and scheduled outage extensions of any maintenance outages.

[0074] A Monte Carlo digital simulation quantifies the risk of expected unserved energy (EUE) and the expense of market purchases required to avoid shedding firm-load customers across a wide range of possible scenarios. Unique structure and processing of input and output data enables the digital simulation to consider not only a large number of components that contribute to unreliability, but to process a large number of scenarios quickly. With a large population size, decisions can be made on relative risks between months, hours of the day, weather impacts, unit outage impacts and load forecast errors.

[0075] Generating units (e.g., combustion turbines, combined cycle units) typically operate for a period of time, fail and are repaired, and then operate again. Monte Carlo draws on each generating unit's historical operating performance are used in the invention to determine expected forced outages. Steam units are typically more reliable during the high load seasons (summer for summer peaking utilities and winter for winter peaking utilities) probably because of the emphasis on keeping the units running due to the increased demand. Since the forced outage data includes only a series of observations, multipliers are used to move the data to more realistic values to better reflect annual patterns of reliability. Typical actual data for a generating unit could have 8-12 entries in the time to failure (TTF) input data record ranging from a few hours to several thousand hours. The corresponding entries in the time to repair (TTR) input data record could range from a few hours to many. In one embodiment, the simulation will randomly select time to failure from the first data record and then select a random time to repair duration. Individual unit operation thus reflects historical data over a selected time period for which data is available. Since generating units are independent, multiple units can be down (i.e., failed) concurrently.

[0076] Generating units also periodically experience equipment failures that require the units to operate at reduced output. These partial outages are generally much less significant than full forced outages, but must still be considered when determining system generation reliability. Generating units have been found to have slightly lower reliability in the summer months in terms of partial outages. Partial outages occur more frequently and are repaired more quickly in the summer. The difference may be due to fewer reporting of partial deratings in non-summer months since the units are not called on for economic dispatch during that period. The higher level of partial outages is representative of periods when unserved energy will occur.

[0077] Three data inputs are used to model partial outages for each system generating unit. These inputs are mean time to failure (MTTF), mean time to repair (MTTR) and percent derating. The invention randomly simulates partial outages based on unit service hours, MTTF and MTTR. Partial outages are represented as constants in the model, rather than as a distribution, because of their relatively small effect within the analyses.

[0078] The determination of the reliability impact of conventional hydroelectric “hydro” generation is one of the major reasons for developing a Monte Carlo-based model for system simulation. The operation and flexibility of conventional hydro generation is very complex to model. A system-owned hydro generation capacity can be divided into three components: (1) run-of-river (ROR), (2) scheduled hydro generation, and (3) emergency or “unloaded” hydro generation. Multiple hydro generation scenarios matched with multiple weather scenarios are included in the simulation model. For each scenario, ROR and scheduled hydro generation are modeled based on actual historical results. ROR capacity operates in every hour, and varies in each weather year and with each month. Emergency hydro generation is modeled as a variable amount of system hydro generation capacity that changes based on the availability of peak hydro from year to year and month to month.

[0079] The major constraint in dispatching emergency hydro generation involves the assumptions concerning how willing dispatchers are to hold back the emergency hydro generation. The simulation model calculates the emergency hydro energy available in each day due to natural in-flow. The simulation model also looks back several days (e.g., three) to see if some of the natural in-flow was not used in that period. The daily hydro limit is the sum of today's natural in-flow and any energy not used in the several preceding days. For a series of capacity-constrained days, only the normal in-flow energy will be available near the end of the series each day. This modeling approach results in much higher, but more accurate EUE projections than the traditional production cost approach of simply adjusting loads for hydro operation.

[0080] The pumped hydro storage units are dispatched in reliability order, i.e., units with larger ponds are dispatched first. Pumping should and will occur any time energy is available. In keeping with the goal of calculating EUE, there are no economic tests associated with pumped storage hydro operation. Alternatively, it could be viewed that it is always economical to build up the reservoirs of storage units with any generating asset available if that is what is required to have a unit available to operate to avoid unserved energy.

[0081] Load data is input into the simulation model as the sum of the hourly loads for the entire system being modeled. Temperatures should be input with the hourly loads; for systems that span a wider geographical area, the temperatures for different geographical areas should be weighted by the load in different geographical areas to develop a composite temperature.

[0082] Load management capacity is also included in the simulation analysis. The load management resources include such programs as interruptible service, real-time pricing, direct load control, stand-by generation, excess generation, and supplemental energy. The digital simulation includes the physical constraints (e.g., hours per year, days per week, and hours per day) for these energy-limited resources. These resources occupy specific positions in the dispatch order. The position in dispatch affects the ability of these resources to reduce expected unserved energy and alters the frequency with which they are called.

[0083] Various load management rates, sometimes referred to as active demand-side options (active DSOs), such as interruptible load, cool storage, and direct load control have gained interest by electric utilities over several decades. The interruptible load is handled explicitly in the simulation analysis, but DSOs that cannot be dispatched (passive DSOs) are included in the load forecasts and are more difficult to identify discretely.

[0084] If inexpensive energy is available from neighbors, dispatchers will hold back on hydro and pumped storage, and buy economy energy. By examining historical load shapes, estimates of available economy energy can be developed.

[0085] The unpredictability of weather also impacts system generation reliability. Historical weather patterns for a large number of consecutive years and their associated probabilities of occurrence are utilized in the simulation model. In general, if weather remains normal over time, concerns for system generation reliability are minimized. However, if a system experiences many days of recording abnormal temperatures, system demand would increase significantly.

[0086] The capacity of some fossil and combustion turbines changes based on the ambient air temperature. With each load file a temperature is specified for each hour. In the unit input section, a multiplier is specified for each temperature. During the simulation, the multiplier is used to calculate the hourly capacity for each unit that is online.

[0087] System dispatchers have flexibility regarding the order in which generating units are called to operate. Steam units are committed first, generally beginning with the least expensive in terms of operating costs. When steam units are insufficient or are not the most economical way to meet the electrical demand, the system dispatchers can call on a combination of the following options: economy purchases, normally scheduled hydro, pumped storage hydro, combustion turbines, load management, and emergency hydro. The combination and the order of the options called varies with system conditions and projections of the near future, usually the next two or three days. During most periods of the year, the dispatch order is as follows: (1) all steam units; (2) scheduled hydro; (3) pumped storage; (4) economy ties if available; (5) combustion turbines; (6) load management; and (7) emergency hydro.

[0088] If system conditions are tighter than normal, the pumped storage units could be run before the conventional hydro. If system conditions are even tighter, the combustion turbines can be called before the conventional and pumped hydro. To reflect these options, the simulation model checks the next two days to estimate how tight the system capacity situation is expected to be. If the system peak is expected to be between 85% and 95% of available capacity, including all committed hydro and quick start units, the dispatch order is revised to move the pumped storage units down in the dispatch order. The order of dispatch then becomes: (1) all steam units, (2) economy ties if available, (3) pumped storage, (4) scheduled hydro, (5) combustion turbines, (6) load management, and (7) emergency hydro.

[0089] If the system peak is expected to be above 95% of available capacity, the dispatch order is changed to the generation reliability dispatch. The order of dispatch then becomes: (1) all steam units, (2) economy ties if available, (3) combustion turbines, (4) pumped storage, (5) scheduled hydro, (6) load management, and (7) emergency hydro. Since the simulation model switches dispatch orders dynamically over time, this feature is called the “dynamic dispatching option.” Thresholds and dispatch order may vary from system to system and can be accounted for in the model.

[0090] The cost of EUE is one of the most important and most uncertain of the assumptions in the simulation model. The payment that a customer is willing to make to avoid an hour of sudden, unexpected firm load curtailment on a hot summer afternoon is difficult to estimate. The payment that a customer is willing to take to suffer an hour of sudden, unexpected firm load curtailment on a hot summer afternoon is also difficult to estimate. Whenever EUE is incurred, an estimated societal cost is applied to that energy. This cost is based on surveys and estimates of the impact that unserved energy has on customers. The invention models the cost of EUE based on the duration of load shed events.

[0091] Scenario Builder

[0092] FIG. 1 illustrates a scenario builder tab user interface for creating a scenario. Study data also controls the scenarios that are run for each study. There are four primary inputs on the scenario builder tab that are used to build the studies: load files, system records, number of iterations, and load forecast error. Each load file is the representation of a weather year. The load files are input in the load section, but on the scenario builder tab, the user points to which specific load file to use as well as in which order. The system records are the year identifier in the system data. The user has flexibility to specify different system data for each year. The user can then specify which year to use by selecting an individual or combination of records on this tab. The selection process requires first selecting the system group. Then all the possible records are auto populated in the left list box. The user then selects up to five records for each line. The number of iterations controls how many times the simulation will occur for each scenario. A larger number of iterations will result in a more convergent result. The load forecast error is an estimation of the distribution of errors from forecasting the weather normalized peak load. The probabilities that go with this distribution are used on the control tab. Load forecast error is based on the error in estimating the non-weather related growth in the load from year to year. It is primarily economic growth that is estimated in this component. Using historical projections of load compared to actual weather-normalized peak loads, this distribution can be estimated.

[0093] Each combination of scenarios will correspond to a case number on the control tab. To select the correct cases, it is often too time consuming to search through up to 10,000 cases to find the correct combination. Default cases can be set in a csv file and imported into the application to facilitate easy selection. The case numbers are calculated by taking the scenario building variables in alphabetic order and calculating all the combinations.

[0094] Selected Units

[0095] FIG. 2 illustrates the selected units tab user interface. The first step on this tab is to select the unit group that will be used. The different unit types that can be selected include nuclear, fossil steam, combustion turbine, interruptible units, emergency hydro, scheduled hydro, run of river hydro, and pumped storage hydro. After selecting the unit group, all the possible units will be loaded into the respective unit types. The user is then able to check all the units that he wants to include for the study. The summary control objects keep a running total of the capacity that has been selected. Note that only units that have global values for capacity can be accurately summarized. If a unit's capacity is input seasonally or has a varying capacity based on weather, an accurate total will not be calculated. Units that do not have global capacity values are highlighted.

[0096] Unit information can be input in multiple different formats including global, annual, monthly, seasonal, global monthly, and global seasonal. Unit variables include, but are not limited to, the following: unit peak hour rating; unit continuous hour rating; unit capacity levels, curtailable days per week limit, curtailable hours per day limit, curtailable hours per year limit, unit fixed cost, unit fuel handling cost, unit variable operations and maintenance cost, pumped storage hydro cycle efficiency; unit dispatch type; unit primary fuel number; unit heat rate coefficients; unit incremental heat rates; hydro unit monthly energy; unit in-service dates; curtailable minimum down time; unit maintenance period start, end dates; unit dispatch penalty factor; unit partial outage derating percentage; unit partial outage time to failure; unit partial outage time to repair; pumped storage hydro pond capacity (MWHr); combustion turbine start up probability; steam unit startup time (Hrs); unit time to failure cumulative probability distribution (hours); unit time to failure hourly distribution; unit time to failure multiplier; unit time to failure probability; unit time to failure reference; unit time to repair probability distribution (hours); unit time to repair probability distribution (days); unit time to repair hourly distribution; unit time to repair multiplier; unit time to repair probability; and unit time to repair reference.

[0097] Control Variables

[0098] FIG. 3 illustrates the control variables tab user interface. The control variables in the simulation model include, but are not limited to the following: (1) combustion turbine (MW) counted toward spinning reserves; (2) combustion turbine percentage counted toward spinning reserves; (3) dispatch unit emergency rating; (4) dispatch unit maximum rating; (5) dispatcher's peak estimate look ahead (days); (6) dispatch type calculation look ahead (days); (7) hydro look back period (days); (8) load adder (MW); (9) normal dispatch order; (10) risk-aversion dispatch order; (11) reliability dispatch order; (12) study year; (13) normal risk—aversion dispatch threshold; and (14) risk aversion—reliability dispatch threshold.

[0099] System Variables

[0100] System variables include, but are not limited to, the following: minimum area security requirement (MW); daily peak estimate error distribution; economy purchases by month, hour; fuel cost; hydro hours of operation limitation; neighbor tieline import limit (MW); amount for reserves (MW); reserves as percentage of largest unit; segment size (MW) of energy distributions; and sub-period definition. Every hour of the week needs to fall into one of three sub-periods: weekday, weeknight, or weekend.

[0101] Reports

[0102] FIG. 4 illustrates the reports tab user interface. There are three categories of reports illustrated in the figure: standard reports, customized reports, and iteration-specific reports. Iteration-specific and standard reports cannot be modified by the user. The user must specify the iteration for which the reports should be generated on the iteration-specific reports. These reports are not generally used in the outcome of the study, but are rather used for debugging the simulation to validate different components of the input data or the simulation process.

[0103] The standard reports that are visible in the reporting section are based on the reports selected in the data inputs in the study section. The study must be opened to be able to view the reports. The standard reports that can be selected include monthly energy deficits; annual energy deficits; monthly outage report; annual outage report; multi-study analysis (for certain analyses, reliability costs need to be summarized across all the cases for a study); incremental capacity equivalent (ICE) factor; monthly interruptible service (IS) summary; annual IS summary; monthly reliability metrics; annual reliability metrics; monthly reliability cost; debug report; and unit hourly operation.

[0104] To evaluate the worth of energy-limited resources, the simulation model tracks the “generation” from the demand-side options. The IS report will give the hours and generation for each of the curtailable units. The monthly reliability metrics report contains many of the industry standard reliability variables such as LOLP and LOLH.

[0105] The monthly reliability cost report contains 24 points for the peak day of each month, the sum of all the weekdays, and the sum of all the weekends. Each of the points represents the percentage of all the reliability costs that fell in the corresponding hours for the entire study. It is summed across all scenarios and weighted according to the case probability. The sum of all 72 points for the month represents the monthly capacity worth factors.

[0106] The debug report is primarily used to ensure that the simulation is progressing according to expectations. The debug report contains hourly loads, fossil capacity, combustion turbine capacity, interruptible service generation, scheduled hydro generation, emergency hydro generation, emergency purchases, economy purchases, pumped storage generation, and the capacity offline.

[0107] The unit hourly operation report outputs for every hour, the operating state of each unit.

[0108] This report is typically used for debugging.

[0109] Input Groups

[0110] FIG. 5 illustrates the input groups tab user interface. The user selects Unit Power Sales (UPS) groups and fuel groups using this interface.

[0111] UPS data represent portions of units that are sold. Typically these are sold as blocks but in many hours the entire capacity is not used. Therefore monthly capacities and hourly energy are used to calculate the amount of capacity available. When a unit, which has a portion of its capacity sold, is forced offline, the sales from that unit should be curtailed. If the sale energy in any hour is less than the capacity of the sale, the remaining capacity will be available to the system to meet its load. The UPS sales can vary from study to study, so the data is input in UPS groups. Each UPS sale must have a monthly capacity that corresponds to a unit and a month. Each sale must also have 8760 data points for the sale, i.e., a data point for each hour of the year.

[0112] Each unit should have a fuel assigned to it. This information is primarily for setting the dispatch order. The fuel prices can vary from study to study, so the data is input in fuel groups. Each fuel file must have the referenced unit's identifier as well as a month and year to go with the fuel cost.

[0113] Input Validation

[0114] Input validation information is stored for each case that is run in a study. Much of the data will be the same between cases in a study, but may change drastically depending on the select records that are used. There are five sections in the input validation information: error report, maintenance report, outage report, resources report, and load report. There are three sections in the error report—a note section, a warning section, and an error section. Only an error will stop the simulation. The maintenance report is a summary of all the maintenance information input into the application. The outage report is also a summary of the outage information. This helps to ensure that what was intended is what is actually being used in the study. The resources report summarizes all the units that are being used in the report. The resources are summed by month and by capacity type. This also helps to show changes in capacity based on selected values that are input into the application. For example, if a unit has a global value, but also different monthly values for a certain year, and the year is currently selected, the logic is going to select the correct values. The load report summarizes the load for each month by calculating the peak load, the sum of all the loads. This report is done after the adjustments have been calculated, so the user can see how the load forecast multiplier and load adder and hydro information have affected the loads.

[0115] Hydro Dispatch

[0116] In one embodiment of the frequency and duration model, aggressive assumptions are made regarding the availability of hydro resources and the willingness of dispatchers to dispatch hydro during peak conditions. In general, hydro will be dispatched more equitably throughout the week than has been assumed in the more aggressive reliability model. Also, because of the difference between storage projects and run-of-river projects, capacity may be available at some units when it is unavailable at other units.

[0117] To implement more conservative dispatch assumptions, the logic for scheduled hydro can be modified. Scheduled hydro represents the normal monthly dispatch capacity for a hydro unit, and will be dispatched a week ahead in the conservative dispatch embodiment. Emergency hydro represents the capacity for the hydro unit if there is no other alternative besides EUE.

[0118] Steps performed by the processing logic of the conservative dispatch embodiment to dispatch hydro are as follows:

• • [0119] 1. Take the load array and weekly dispatcher's peak error and multiply times loads;
  • [0120] 2. Schedule minimum MWHrs per day across the peak (scheduled around the expected daily peak);
  • [0121] 3. Sort these new loads;
  • [0122] 4. Until the dispatched hydro energy is greater than the input energy available per week, increment the dispatched hydro capacity to shave peak loads such that the peak hours have the same load;
  • [0123] 5. If the dispatch order reaches emergency hydro and load is still greater than committed capacity, dispatch additional hydro up to emergency capacity;
  • [0124] 6. Apply hydro look-back logic only to emergency hydro dispatch.

[0125] The water level in the hydro storage projects changes from season to season. A rule curve has been established that identifies the range of water levels with which projects can operate. The frequency and duration model does not assume that it is possible to go below the rule curve on any of the projects. To determine the amount of energy available for emergency hydro during a season, an assumption is made that hydro is generally operated at least a small amount above the bottom of the rule curve. The available energy due to this difference and its impact on other hydro units in the same river system is calculated. This available energy is spread over the summer season. If the total emergency hydro energy for the summer season is 50,000 MWh, then each day would receive approximately 500 MWh. Hydro look-back logic is used in dispatching emergency hydro in the simulation model.

[0126] The following points summarize the processing logic for dispatching hydro in the conservative dispatch embodiment:

• • [0127] 1. Scheduled hydro is dispatched a week ahead to shave the peaks. The capacity is set by the analyst for each year. The energy to be scheduled is the historical energy for the year being modeled.
  • [0128] 2. Emergency hydro represents the difference between the scheduled hydro capacity and the declared capacity for hydro. Emergency hydro will be dispatched hourly as needed with seasonal energy limits.

[0129] Dispatching Supplemental Modes of Combined Cycles

[0130] Because the frequency and duration model is not attempting to minimize production cost, incorporating logic for the different modes of combined cycles is not very difficult. However, there are some complicating factors. Because the supplemental modes cannot operate unless the base mode is operating, additional units will be created to represent the supplemental modes. These additional units will then be linked to the base mode using a new variable. Only in hours when the base mode unit's status is operating, are the supplemental modes capable of being dispatched. The supplemental modes will be modeled as combustion turbine units. Another issue is that power augmentation will not be able to operate at temperatures below 60 degrees F., so the impact of dispatching these supplemental modes has to be taken into consideration in the weather/capacity logic.

[0131] Dispatching Interruptible Contracts

[0132] All interruptible contracts must be included in a block loading group. When interruptible contracts are called, they are called in groups to ensure equality among such contracts. Each curtailable unit is assigned a block loading group.

[0133] In actual utility operation, interruptible contracts are called in a rotating manner to ensure equality. Therefore, all available interruptible contracts are sorted in descending order of the time since that contract's previous call.

[0134] Market Purchases

[0135] The true cost of reliability is not only the cost of EUE, but also the incremental cost of market purchases beyond the production cost of a combustion turbine. In the frequency and duration model, there are three components factored into making market purchases: (1) market price, (2) available generating capacity, and (3) available transmission capacity.

[0136] Some of the factors that affect market price are the following: resources—total load; time of day; day of week; alternatives (seller, buyer); elasticity of demand; previous day's market price; natural gas availability; seasonal market price; coal availability; hydro reserves; transmission availability; and weather expectations. The market price should only represent the incremental price above the cost of a combustion turbine.

[0137] The impact of these factors can generally be estimated through two variables: (1) the expected reserve margin for the year and (2) the magnitude of the hourly difference between available resources and load. In other words, estimated cost of market purchases are based on the planning reserve margin, and the hourly shortage of capacity. The market purchase cost data should be input with a reserve margin (RM) and corresponding shortage level with the cost. This must be provided for a sufficient number of data points such that a reasonable estimation can be made.

[0138] FIG. 6 illustrates an exemplary chart for determining the market price. For example, consider the following variable values and the “short” cost data array in Table 1 below:

[0139] Hr: 4409

[0140] Expected Summer Peak Capacity=30,000 MW

[0141] Short: 110 MW

[0142] RM: 15.9%

[0143] RM=(1+LFE)*Calculated Summer Capacity/Expected Summer Peak Load

[0144]

TABLE 1
Short	RM	Cost
100 MWh	16%	$200/MWh
150 MWh	16%	$300/MWh

[0145] Because the cost and reserve margin are inversely proportional, an adjustment is required on the position in the cost array for 15.9% reserve margin case. The adjustment is based on the proximity to the nearest point in the short cost array. This adjustment calculation is as follows:
adjustment=(16%−15.9%)*ExpectedSummerPeakCapacity=0.1%*30,000=30 MW

[0146] The simulation model interpolates between the 100 MWh and 150 MWh points in the short cost table:

[0147] $\mathrm{Short}+\mathrm{adjustment}=110+30=140\mathrm{MW};\frac{\left(140-100\right)}{150-100}*\left(300-200\right)+200=\mathrm{\$280}/\mathrm{MWh}$

[0148] After the market price is determined, the actual energy available for purchasing must be determined. Each of the interfaces from which an electric utility can purchase energy could be modeled in the frequency and duration model. The first factors to determine capacity available are the total resources and projected reserve margin for the control areas on the interface.

[0149] Monthly transfer capacity data is input as a distribution for each neighbor for each month. It is important that each neighbor has points in the distribution that correspond to each other. This is done through the position variable in the input data. Position one in neighbor one must correspond to position one from all the other neighbors. For example, if position one for neighbor one came from the 33rd hour in July, position one for all other neighbors should come from the same hour. Several inputs are required to model neighboring utilities correctly. These include EFOR, number of units, capacity, peak load, and capacity benefit margin (CBM).

[0150] For each hour that energy is needed from outside the electric utility's control area, the following calculation is performed for each interface:

[0151] $\mathrm{AvailableCapacity}=\mathrm{Neighbor\_Capacity}-\left(\frac{\mathrm{NativeLoad}}{\mathrm{ExpectedPeakLoad}}\right)*\mathrm{Neighbor\_Load}-$
random(CumulativeMWOfflineDistribution)−Neighbor_EnergyLimited Resources

[0152] Neighbor_EnergyLimitedResources will be removed from Neighbor_Capacity before input is complete in the frequency and duration model. Thus, Neighbor_Capacity only represents the net fossil resources of the neighbor. Therefore Neighbor_EnergyLimitedResources will not be taken into consideration in the logic of the model.

[0153] CumulativeMWOfflineDistribution is calculated based on the average EFOR and average unit size for each neighbor. The logic is run at the beginning of the simulation and stored as an array for use during the simulation. Pseudocode for the processing logic is generally as follows:

• • [0154] For p=0 to Number of Units in Neighbor
    • [0155] Temp=(1−t)^(n−p)*(t)^p*(n!/(n−p)!p!)
    • [0156] Totalprob=totalprob+temp
    • [0157] MWProb(p)=p*unitsize
    • [0158] PercentProb(p)=totalprob
  • [0159] Next

[0160] In the preceding pseudocode, t represents the average EFOR; p is a counter; n is the Number of Units in the Neighbor; MWProb is an array that stores the associated MW offline at a given probability; PercentProb represents the cumulative probability distribution of number of units being in a forced offline state; and unit size is calculated as Neighbor_Capacity/Number of Units in Neighbor. Neighbor capacity, neighbor peak load, average EFOR, Number of Units in the Neighbor, and CBM are all inputs to the frequency and duration model.

[0161] The final component to the market purchase processing logic is actually an interface with the transmission module. There are two components to the transmission module: internal constraints and interface constraints.

[0162] The logic for modeling constraints on internal interfaces requires the capability of entering load on an area basis and not just for the entire control area.

[0163] Collecting available transfer capacity (ATC) and market purchase data for all of the interfaces to the electric utility allows for the creation of distributions for the availability of transmission capacity at each of those interfaces.

[0164] In summary, market purchases are dispatched twice in the simulation model. The first dispatch is in an economic manner; the second dispatch is in an emergency manner. During the economic dispatch, the available transmission capacity will not receive any special treatment. During the emergency dispatch, the available transmission capacity will reflect calling CBM. Emergency dispatch of market purchases will only occur if all other resources have been expended.

[0165] To determine the expected amount of economic transmission capacity available, a distribution of megawatts available for each interface will be stored monthly. When the model selects values across the interfaces, there will be correlation between the available transmission capacities at different ties to represent the general reality that when transmission capacity is low at one tie, it will likely be low at other ties.

[0166] To calculate the net megawatts purchased, the minimum of short amount, generation capacities available and transmission capacity available will be used to represent the amount of energy purchased.

[0167] Unit Outage Processing Logic

[0168] The most pressing issue in modeling unit outages is the impact of unit outages on reliability convergence. Because a unit outage can overlap multiple iterations of the simulation, each iteration is not independent. If each iteration is not independent, convergence may not occur until a higher number of iterations is completed. Simply re-initializing the position of each unit in the time to repair and time to failure distributions could lead to inordinately high forced outage rates because points are randomly selected out of these distributions. Because a point with a low number of hours could be selected as easily as a point with a high number of hours, the low number points could be chosen more often than they should be chosen statistically.

[0169] In order to model unit outage more reliably, the following algorithm is implemented:

• • [0170] 1. Calculate the forced outage rate (FOR) by taking the average of TTR values for January/(Average of TTR values for January+Average of TTF Values*TTFmlt for January);
  • [0171] 2. Select a random value between 0 and 1;
  • [0172] 3. If random value <FOR, then unit will be on outage; else unit will be online;
  • [0173] 4. Select new random value and multiply times sum of all TTF values or TTR values.
  • [0174] 5. Loop through array of TTF_hrs or TTR_hrs incrementing iteration variable i until result of step 4>outage_total; outage_total increases as the array is stepped through by outage_total=outage_total+TTF_hrs(i) OR TTF_hrs(i).
  • [0175] 6. The starting point of the unit for TTF_hrs or TTR_hrs will be TTF_hrs(i−1) or TTR_hrs(i−1)
    In this algorithm, TTFmlt represents seasonal or monthly multipliers to be applied to an annual time to fail average value for a unit. TTF_hrs array contains all the observed service hours between failures for each unit. TTR_hrs array contains all the observed repair hours during failures.

[0176] Typically only the seasonal maintenance events are considered in the frequency and duration model. If a unit has an operational issue, but is able to stay online until the end of the next weekend, the unit is never sent to a forced outage (FO) state, but rather to a maintenance state. The following pseudocode represents the associated processing logic:

• • [0177] If hrsins(unit)<1 then
    • [0178] If rand<probmaintenance(unitnum)+trigger(unitnum)=0
    • [0179] Hrsins(unit)=Friday afternoon hour−currenthr
  • [0180] Else
    • [0181] Trigger(unitnum)=0
    • [0182] Send unit to FO state
  • [0183] End if
    Hrsins represents the current hour position of Hours to Failure for the current unit. Trigger is a variable that represents whether a unit can be sent to a maintenance outage or must be sent to forced outage.
    Probmaintenance(unitnum) is a variable input for each unit which represents the number of maintenance events/number of total outage events. All of the hours offline for maintenance events will be added to the TTF_hrs array.
    Weather Capacity Relationships

[0184] An important use of the frequency and duration simulation model is the development of incremental capacity equivalent (ICE) factors for interruptible customers. Generally, ICE factors represent the worth of load management resources, such as interruptible service contracts, relative to the value of incremental generating capacity that can be added to the system. To do this accurately, it is important to correctly model the load-resource balance at all hours of a day. The frequency and duration simulation model has the ability to limit the capacity on an hourly basis based on the temperature. In summary, the frequency and duration simulation model determines weather capacity relationships as follows:

• • [0185] 1. Each load file includes a column for temperature;
  • [0186] 2. All combined cycles and combustion turbines will have a unique set of values specifying the capacity multiplier at each degree for all temperatures;
  • [0187] 3. Adjust committed capacity each hour for combined cycles and combustion turbines based on the above set of specified capacity values;
  • [0188] 4. Adjust committed capacity when transferring units to or from committed capacity;
  • [0189] 5. Use the adjusted capacity values of the units for calculating the resources to be committed for that day (day-needed units module).

[0190] EUE Sharing and Accounting

[0191] The cost of EUE is dependent on a number of factors including the number of EUE events in a given year, the duration of the outage event, the customer class split, the duration of the event before rolling to different customers, the day of the week, and the time of day. Not all factors can be modeled efficiently.

[0192] The general philosophy in a firm load shed event is to shed non-essential load first. If there are a very small number of events per year, this philosophy is practical. However, if the electric utility system is forced to shed load more often, the load must be shed on a more equitable basis.

[0193] For each iteration of the frequency and duration model, the LOLH counter will determine which array from which to get the EUE cost. If LOLH<4, then EUE is taken from primarily residential, so the net EUE cost would be relatively low. If LOLH>=4, the EUE is spread across the customer classes based on the peak load ratio, so the impact of commercial and industrial load shed would cause the EUE cost to be much higher.

[0194] If the electric utility is forced to shed firm load, the implied cost to the individual customers starts off very high on a cost per kilowatt hour ($/kwh) basis. As the length of the outage increases, the incremental impact of the outage becomes lower. This effect is shown in FIG. 7.

[0195] The EUE cost calculation is performed at the end of each iteration. Each event based on the consecutive hours of EUE will be matched with the appropriate cost per kilowatt hour from the cost array. The impact of which customers will be cut is taken into account during the determination of the cost of EUE.

[0196] Outages are rolled so that one customer doesn't experience an inequitable share of the unserved energy. As customers roll off the firm load shed, they will experience a significant increase in load as their appliances are in start-up. This will require shedding even more firm load for the subsequent hour. Also, there is a significant impact to the cost of EUE on a cost per kilowatt hour basis depending on whether an individual customer's load is shed for one hour or four hours. This impact can be seen in FIG. 7.

[0197] Input variables are provided for the user to specify the length of each customer's outage in hours as well as for the payback energy penalty. In the simulation model, a counter is implemented for consecutive hours of EUE. Each hour that the counter becomes greater than the input variable, the EUE will increase based on the payback energy penalty, and the counter will be reset.

[0198] If a load shed were to occur on a weekend or at night, there would be a lower cost of EUE. However, because such a very small percentage of EUE will fall on nights and weekends, the increasing complexity to include this logic is not offset by the improvement in accuracy of the model.

[0199] In summary, the frequency and duration simulation model determines EUE as follows:

• • [0200] 1. The EUE for each hour will be assigned to unique customer blocks;
    • [0201] a. In the following hour, if the outage duration has been reached, that customer's EUE block will be set to 0;
    • [0202] b. If the outage duration has not been reached, and the EUE decreases, the EUE for the customer block will decrease to the amount of EUE;
    • [0203] c. If EUE increases in the following hour, the first customer block of EUE will stay constant, and a second customer block will be assigned the additional EUE;
    • [0204] d. When a customer's EUE is reduced, additional load is incurred based on an energy payback input by the analyst. The net impact of bringing a customer group back online is shown in the formula below:
      • [0205] adjusted_eue(current_hr)=adjusted_eue(prev_hr)−(adjusted_eue(prev_hr)−preadjustment eue(current hr))/(1+payback)
    • [0206]  In this formula, adjusted_eue is the final value reported for eue; preadjustment_eue is the result of load—total resources prior to the impact of payback penalty energy; and payback is the percentage energy payback input by the analyst. This formula is applicable only when the EUE for the current hour is less than the EUE for the previous hour.
  • [0207] 2. At the end of the day, the duration of all the events is calculated and assigned an EUE cost. The EUE cost is determined by the duration and how many EUE events have been incurred in the case year.

[0208] Processing Logic for Committing Units

[0209] Exemplary simulation processing logic for committing additional units (block 800) based on the dispatch order is illustrated in FIG. 8. This module determines a dispatch order (block 804) and loops through the dispatch until the load is covered. The dispatch order is determined by means of the threshold ratios among the normal dispatch order, the risk aversion dispatch order and the reliability dispatch order. A test is performed in decision block 808 to determine if the capacity need has been covered for the current hour being simulated. If it has been covered, processing returns to the calling simulation module. If capacity has not been covered, then one of several logic modules will be called according to the dispatch order that has been determined, as indicated in block 812. There is a separate processing logic module for each type of unit that can be dispatched. As can be seen from examination of FIG. 8, the dispatch can include pumped storage 816, combustion turbines 820, emergency hydro 824, curtailable entries (i.e., interruptible contracts) 828, emergency purchases 832 and reliability purchases 836. For dispatching pumped storage hydro 816, the commit pumped storage units module (FIG. 9) is called as indicated in block 840. Combustion turbines are dispatched using the logic of FIG. 10, as indicated in block 844. Similarly, emergency hydro is dispatched using the logic of FIG. 11, as indicated in block 824. For curtailable contracts with residential and industrial customers, interruptible contracts are determined using the logic of FIG. 12, as indicated in block 852. In the event that the dispatch order requires emergency purchases from neighboring energy providers (e.g., Tennessee Valley Authority), a purchase tie energy module is called as indicated in block 856. In the event that the dispatch order requires reliability purchases, a determine reliability purchases module is called as indicated in block 860. Processing logic then loops back to the next unit in the dispatch as indicated in block 864. The commit more units module continues execution until the capacity need has been covered (decision block 808).

[0210] FIG. 9 illustrates exemplary simulation processing logic for committing pumped storage hydro units (block 900). A test is performed in decision block 904 to determine if the capacity need has been covered for the current hour being simulated. If it has been covered, processing returns to the calling simulation module in block 936. If capacity has not been covered, a determination is made in decision block 908, as to whether or not the amount of capacity needed in the next hour is greater than can be dispatched by the pumped storage unit. If the amount of capacity needed is greater than can be dispatched by the pumped storage unit, another test is made in decision block 912 to determine if the unit's pond is full. If the pond is full, then the maximum amount of capacity that can be dispatched in one hour is withdrawn as indicated in block 920. If the pond is not full, all of the capacity that is left in the pond is withdrawn as indicated in logic block 924. From both logic blocks 920 and 924, processing continues in block 932 by going to the next pumped storage unit for analysis. From block 932, processing logic returns to decision block 908 to determine if capacity needed in the next hour has been met.

[0211] If the amount of capacity needed is less than the amount that can be dispatched by the pumped storage unit as determined in decision block 908, another test is made in decision block 916 to determine if the amount of capacity in the pond is greater than the amount of capacity needed? If it is, then the amount needed to cover the required capacity as indicated in bock 928. If the pond capacity is not greater than the needed capacity, then all of the capacity left in the pond is withdrawn as indicated in logic block 924. From both logic blocks 924 and 928, processing continues in block 932 and then loops back to decision block 908 as discussed in the preceding paragraph.

[0212] FIG. 10 illustrates exemplary simulation processing logic for committing combustion turbine units (block 1000). In decision block 1004, a test is made to determine if there are combustion turbines available. If there are combustion turbines available, then a further test is made in decision block 108 to determine if capacity needed has already been dispatched. If it has, processing returns to the calling simulation module as indicated in block 1032. If needed capacity has not been dispatched previously, then the simulation logic generates a random value and compares that value to the startup probability to determine if the combustion turbine will start or fail as indicated in block 1012. The comparison between the random value and startup probability is made in decision block 1016. If the determination is that the combustion turbine will start, then the state of the combustion turbine is changed to “commit” as indicated in block 1020. If the determination is that the combustion turbine will fail, then the state of the combustion turbine is changed to “full out” as indicated in block 1020. From both blocks 1020 and 1024, processing continues with block 1028 which gets the next combustion turbine and then loops back to decision block 1008 to determine if needed capacity has been met.

[0213] FIG. 11 illustrates exemplary simulation processing logic for determining emergency hydro operation (block 1100). This module determines the amount of hydro that can be run based upon certain conditions. One of three scenarios is first selected as indicated in logic block 1104. The three scenarios are represented in blocks 1108, 1112 and 1116, respectively. The first scenario (block 1108) condition is energy available is greater than full gate operation peak. The second scenario (block 1112) is energy available equals full gate operation peak. The third scenario (block 1116) condition is energy available is less than full gate operation peak. If the first scenario has been selected, then the available energy is adjusted based upon whether the current hour is in an operation period, or before or after an operation period, as indicated in logic block 1120. If the second scenario has been selected, then hydro is dispatched within hourly limits as indicated in logic block 1124. If the third scenario has been selected, then the hydro dispatch operation is rescheduled to save full gate operation for the peak as indicated in logic block 1128. From blocks 1120, 1124 and 1128, processing returns to the calling simulation module as indicated in block 1132.

[0214] FIG. 12 illustrates exemplary simulation processing logic for dispatching interruptible services (block 1200). In this embodiment, interruptible contracts are sorted in block loading groups by decreasing order of hours since last call. This sort process is indicated in logic block 1204. In decision block 1208, a determination is made as to whether or not the capacity need has been covered. If it has, processing returns to the calling simulation module in block 1232. If capacity need has not been covered, a determination is made in decision block 1212 as to whether or not the contract can be called. If the contract cannot be called, processing continues by going to the next contract as indicated in block 1228. If the contract can be called in decision block 1212, a test is made in decision block 1216 to determine if the curtailable customer will respond to the call by comparing a random value to the response probability. If the comparison results in no response, an attempt is made the next day until the calls reach the maximum non-response limit, as indicated in block 1220. If the curtailable customer responds in decision block 1216, then the status is changed to commit as indicated in block 1224. Processing then continues by going to the next contract in block 1228.

[0215] Processing Logic for Unit Outages

[0216] FIG. 13 illustrates exemplary simulation processing logic for determining if the time for a unit outage has occurred (block 1300). This module loops through committed units to determine if the time has come for an outage to occur. In decision block 1304, a test is made to determine if the unit being checked has accumulated enough hours to go on full outage. If it has, then a random value is drawn to compare to the maintenance probability input. If a maintenance event occurs, then the time to failure hours are increased by an amount needed to get to the following Friday as indicated in logic block 1308. The test to determine for maintenance is indicated in decision block 1320. If the test is negative for maintenance, then the unit is placed on full outage in block 1328 and processing logic proceeds to check the next committed unit in block 1336. Each time block 1336 is reached, processing logic returns to decision block 1304 to determine if the unit being checked has accumulated enough hours to go on full outage. If the test is positive for maintenance in decision block 1320, then processing logic proceeds to check the next unit in block 1336. If the test made in decision block 1304 determined that the unit being checked has not accumulated enough hours to go on full outage, then in decision block 1312 a test is made to determine if the unit being checked is a combustion turbine. If the unit being checked is a combustion turbine, processing logic continues in block 1336 to check the next committed unit. If the unit being checked is not a combustion turbine, a test is made in decision block 1316 to determine if the unit has accumulated hours to go on partial outage. If the unit has not accumulated enough hours to go on partial outage, then processing continues in block 1336 to check the next committed unit.

[0217] In decision block 1316, if the unit has accumulated enough hours to go on partial outage, a test is made to determine if the unit being checked is nuclear. If the unit is not nuclear, it is placed on partial outage as indicated in block 1332. If the unit being checked is determined to be nuclear in decision block 1320, a test is performed in decision block 1324 to determine if the nuclear is in coast down, or has a derated capacity greater than the nuclear operating capacity. If either of theses conditions is found, then processing logic returns to block 1336 to check the next unit. If neither condition is found, then the nuclear unit is placed on partial outage as indicated in block 1332.

[0218] After checking all committed units to determine if the time for an outage has elapsed, the committed units on partial outage are checked for accumulated hours. For each committed unit on partial outage, a test is performed in decision block 1340 to determine if the unit has accumulated enough hours to go to full outage. If the unit being checked has accumulated enough hours, then it is status is changed to full outage as indicated in block 1344. Otherwise, the next unit on partial outage is checked as indicated in block 1348. This loop continues until all units on partial outage have been checked.

Processing Logic for Optimizing Reserve Margin

[0219] The previous sections have described in detail how the cost of expected unserved energy and costs of market purchases are determined for a specific scenario to quantify generation reliability risks. One application of the frequency and duration model is to determine the optimum reserve margin for an electrical utility system. As illustrated in FIG. 14, the following processing steps are performed:

• • [0220] 1. Select several reserve margins for the electrical system that vary only by the amount of combustion turbine capacity in the fleet of generating units (step 1400). For example, system configurations with 10%, 13%, 15% and 17% would be sufficient for many electrical systems.
  • [0221] 2. Determine the cost of expected unserved energy for each of these selected reserve margins using the frequency and duration simulation model across the probability distributions of weather and hydro scenarios and load forecast errors (step 1402).
  • [0222] 3. Using regression analysis and the results of step 1402, generate a graph that predicts expected unserved energy as a function of the reserve margin (step 1404).
  • [0223] 4. Using economic carrying costs techniques and the annual cost of owning combustion turbines, generate a graph that predicts the cost of owning incremental generating capacity above the minimum reserve margin (e.g., 10%) (step 1406).
  • [0224] 5. Add the results of the graph from step 1404 to the results of the graph from step 1406 to determine the electricity customers' cost of adding new capacity net of the reliability benefit of adding that capacity. The resulting sum can then be plotted as a graph of total incremental cost of reserve margins above the minimum reserve margin, with annual cost on the y-axis, and reserve margin on the x-axis (step 1408).
  • [0225] 6. Determine the minimum point on the graph which corresponds to the optimum reserve margin (step 1410).

[0226] FIG. 15 illustrates an exemplary graph of the sum of capacity cost, purchase cost, and EUE cost as a function of reserve margin.

[0227] The system and method of the present invention have been described as computer-implemented processes. It is important to note, however, that those skilled in the art will appreciate that the mechanisms of the present invention are capable of being distributed as a program product in a variety of forms, and that the present invention applies regardless of the particular type of signal bearing media utilized to carry out the distribution. Examples of signal bearing media include, without limitation, recordable-type media such as diskettes or CD ROMs, and transmission type media such as analog or digital communications links.

[0228] The corresponding structures, materials, acts, and equivalents of all means plus function elements in any claims below are intended to include any structure, material, or acts for performing the function in combination with other claim elements as specifically claimed. Those skilled in the art will appreciate that many modifications to the exemplary embodiment are possible without departing from the spirit and scope of the present invention.

[0229] In addition, it is possible to use some of the features of the present invention without the corresponding use of the other features. Accordingly, the foregoing description of the exemplary embodiment is provided for the purpose of illustrating the principles of the present invention, and not in limitation thereof, since the scope of the present invention is defined solely by the appended claims.