Ancillary Services Table

The Ancillary Services Table is used to define ancillary service products and enable the use of the logic. Product types and parameters are defined in this table and then referenced by generators in the Resources table.

Aurora has the ability to co-optimize the allocation of resources to meet ancillary services and energy requirements. It uses a mixed-integer program to minimize total system cost while adhering to all transmission, energy, ancillary, and other input constraints. The model solves to find an optimal solution on a daily basis, determining how resources commit, dispatch, and provide ancillary requirements for each hour of the day. The Ancillary Services Table is used to define ancillary service products and enables the use of the logic.

There are two types of products that can be defined: Up and Down.

Up type products require that enough excess capacity be online or available within a short time horizon to be ramped up to meet unexpected load increases.
Down type products require that enough capacity be online and available to ramp down within a short time horizon to meet unexpected load decreases.

The Time Length parameter is used to specify how fast the resources need to be able to ramp up or down to meet the requirement, and in conjunction with the resource ramp rates, it governs how much each resource can contribute to the product.

Each hour the model will calculate each product’s total requirement based upon the MW Requirement, Demand Requirement, Generation Requirement, and Largest Unit List input values. Using the final MW value the model will add a constraint to the optimization to ensure that the requirement is met if possible. Individual resources participate in each product based upon the Ancillary Services column in the Resources table, and each resource’s available contribution is based upon the product Time Length as well as the resource ramp rate, output level, and Max Operating Reserve. The co-optimization will determine the best allocation of resources to meet both the energy and ancillary requirements. For any given product the MW value of ancillary services provided to the product plus the energy produced to serve load cannot be more than the underlying resource capability. Furthermore, Aurora will add constraints to limit the simultaneous contribution of the resource to its Up type products, as well as to its Down type products, in which it participates.

Hydro and storage resources can both participate in ancillary services, but they act differently than standard resources:

Hydro: Hydro plants are able to contribute to Up type reserves between their output and original capability (i.e. capacity derated for forced outage and maintenance). The original capability will generally be higher than the capability determined in advance by the Hydro logic that schedules the plants on a monthly basis. Hydro plants can also contribute to Down type reserves in the standard way. In general it is expected that hydro plants which are flexible enough to provide reserves would have the Use Daily Optimization column set to True in the corresponding hydro set to allow complete flexibility in dispatch.
Storage: When using the commitment optimization logic, the model automatically dispatches the storage based upon system needs for each day. The week ahead storage logic produces a generation/charging pattern for each hour that will not be strictly honored but rather sets a guideline for the ending contents for each day for each storage project. If a storage unit participates in ancillary services, then the logic will work as follows:
- When the unit is at 0 output (i.e. not charging or generating), then if the value in Offline Ancillary Up Time is less than the time length for the product, the unit is defined to be “flexible” and can provide reserves in either direction. Otherwise it is not flexible and cannot provide reserves when not operating.
- For Up type products:
- - If the unit is generating, then the amount of reserves it can provide is equal to the max generation possible minus the current output.
  - If the unit is charging, then the amount of reserves it can provide is equal to
  - - the MWh currently being drawn from the grid in order to store energy if it is not flexible.
    - the MWh currently being drawn from the grid in order to store energy plus the max generation possible if it is flexible.
- For Down type products:
- - If the unit is generating, then the amount of reserves it can provide is equal to
  - - the amount it is generating if it is not flexible.
    - the amount it is generating plus the maximum amount of MWh it could draw from the grid if charging at full capacity if it is flexible.
  - If the unit is charging, then the amount of reserves it can provide is equal to the difference between the amount of MWh currently being drawn from the grid and the maximum amount of MWh it could draw from the grid if charging at full capacity.

By default the ancillary prices are derived based upon the shadow prices from the LP that is solved after commitment is determined. As an alternative, the Input Price column may be used to specify the ancillary prices for a given product. The ancillary price (whether solved for or entered input) is used to determine ancillary revenue for resources that provide reserves. Ancillary bid prices can be specified for individual resources using the Ancillary Services Bid Price column in the Resources table.

When ancillary services are specified for candidate new resources in a long-term simulation, Aurora will estimate the ancillary service contribution for the new resource options which are not in the system during the iterative dispatch. This is done by comparing each candidate resource’s ancillary bid price to the observed ancillary price for each hour and allocating available capability on the unit to an ancillary product when the bid price is less than or equal to the observed price. Any projected revenue gained from participating in ancillary services will be part of the project NPV of each resource that is used in making the build decisions.

NOTE: In general, it is recommended to use Commitment Optimization logic with ancillary services. If traditional commitment is used in conjunction with ancillary services, pool commitment is strongly recommended.