Business Requirements Specification

Size: px
Start display at page:

Download "Business Requirements Specification"

Transcription

1 Business Requirements Specification Pricing Enhancements Date Created: 3/20/2015 Doc ID: GNFDMDEHU6BB Page 1 of 16

2 Disclaimer All information contained in this draft Business Requirements Specification (BRS) as provided by the California Independent System Operator Corporation (ISO) is prepared for discussion and information purposes only. The draft BRS is provided as is without representation or warranty of any kind, including, without limitation, a representation or warranty as to accuracy, completeness, or appropriateness for any particular purpose. The draft BRS shall be revised as the development and review of the business requirements progresses. The ISO assumes no responsibility for the consequences of any errors or omissions. The ISO may revise or withdraw all or part of this information at any time at its discretion without notice. Doc ID: GNFDMDEHU6BB Page 2 of 16

3 Table of Contents 1. INTRODUCTION PURPOSE DETAILS OF BUSINESS NEED/PROBLEM DESCRIPTION BUSINESS PROCESS IMPACTS HIGH LEVEL DESCRIPTION OF BUSINESS PROCESS JUSTIFICATION BUSINESS REQUIREMENTS BUSINESS PROCESS: ADMINISTRATIVE PRICING DAY-AHEAD MARKET Business Requirements BUSINESS PROCESS: ADMINISTRATIVE PRICING REAL-TIME MARKET Business Requirements BUSINESS PROCESS: SYSTEM EMERGENCIES, FORCE MAJEURE, AND SETTLEMENT IMPLICATIONS Business Requirements BUSINESS PROCESS: PRIORITY OF SELF SCHEDULES WITH EXISTING TRANSMISSION RIGHTS Business Requirements BUSINESS PROCESS: COMPOUND PRICING OF MULTIPLE CONTINGENCIES Business Requirements APPENDIX B: EXAMPLES Doc ID: GNFDMDEHU6BB Page 3 of 16

4 1. Introduction 1.1 Purpose The purpose of this document is to capture and record a description of what the Users and Business Stakeholders of the project wish to obtain by providing high-level business requirements. This document establishes the basis for the agreement between the initiators and implementers of the project. The information in this document serves as input to determining the scope of Information Systems projects and to all Business Process Modeling and System Requirements Specifications efforts. These requirements will serve as the initial set of business unit requirements for the appropriate software application/systems development effort. It is understood that additional requirements and systems analysis may produce To Be Business Process Models, System Requirements Specifications, and Use Cases to serve as the set of requirements documents used by the development teams to buy, modify, or build the necessary software and hardware systems. The Business Unit(s) involved in the project will have an opportunity to review and approve all requirements documentation produced. Management proposes market rule changes to improve pricing efficiency in four areas: administrative pricing rules that apply when market clearing prices are not available; validation of self-schedules supported with transmission contract or ownership rights; formulation of contingency-related constraints; and formulation of market constraints to ensure unique market clearing prices. Administrative pricing is used during market disruptions or suspensions for when prices cannot be generated through its normal market clearing mechanism. After the September 8, 2011 southwest outage, the ISO committed to revise its administrative pricing rules that would apply for similar system emergencies or market disruptions. The ISO launched this effort in August 2012, and resumed it in June 2014 as part of a broader stakeholder process that led to the proposed changes. The current rule is to use the last available price produced in the market, referred to as the last best price. Management now proposes a tiered approach for administrative pricing that will provide simple and practical rules and price certainty, and have minimum impact on the market as a whole. The proposal also addresses settlements implications for both physical and financial resources and will clarify market participants financial obligations for force majeure events. Doc ID: GNFDMDEHU6BB Page 4 of 16

5 2. Details of Business Need/Problem 2.1 Description Implement Administrative Pricing rules Three additional items related to pricing in the ISO markets that will be included in the scope: Scheduling Priority for ETC/TORs: The ISO has observed cases where a market participant submitted an ETC/TOR self-schedule but used an erroneous contract reference number, in which case the wheel through becomes unbalanced and the ETC/TOR self-schedule loses its scheduling priority and are treated as the self-schedules are passed to the market system as regular price taker self-schedules, producing unintended consequences for the market as well as the ETC/TOR holder. Compounding Pricing Methodology in Event of Multiple Contingencies: Since 2013, with the introduction of more contingency-related constraints and with tighter conditions in the system, there have been several instances where a transmission constraint is binding for base case and/or multiple contingency cases. The ISO has observed cases where the solution is the constraint-relaxation region because there are insufficient economic controls to manage the congestion on the transmission constraints using only economic bids. When this occurs, the same constraint may be binding and relaxed for the base case and/or multiple contingencies cases. Each of these cases will reflect a shadow price associated with the relaxation. Since each contingency case is treated as a separate constraint, each contingency and base case will have a shadow price that will in turn be reflected accordingly in the marginal congestion component of the various locations based on the shift factors thereby compounding the cost of the congestion component of the LMP. For instances where the solution is based on the administrative constraint relaxation parameters, such pricing of compounded congestion may not be sending a proper price signal. Rather, it is a by-product pricing of multiple relaxations based on administrative relaxation parameter prices. Under these conditions, it is expected that only the most severe contingency would be binding and priced. Multiplicity of Prices Under Degenerate Conditions: Management proposes an alternative solution formulation that will eliminate the condition leading to multiple prices and enable the market optimization to select the optimal price. That is, if the market clearing problem is limited by any constraint, the market clearing process would create a price for the constraint only when the relaxation of the constraint would result in a reduction in the total cost to operate the system. To do so, the existing linear programming model would be modified into a quadratic programming model using a new slack variable in both the objective cost function and in the constraint definition, which guarantees the uniqueness of prices associated with the various constraints in the system, including intertie constraints. The new formulation will ensure the price attained is consistent with existing least-cost dispatch principles already embodied in the ISO tariff. The new formulation will also ensure that for those cases in which the intertie is derated to a zero limit in only one direction, the resulting price does not create artificial congestion that creates complications for other products settled on the basis of the cost of congestion at the applicable locations. Doc ID: GNFDMDEHU6BB Page 5 of 16

6 3. Business Process Impacts 3.1 High Level Description of Business Process The Pricing Enhancement initiative impacts the following existing business process diagram: Manage Market & Grid: For when DA market is not available, our real time market system must use the prior day-ahead solution for bids/prices/awards. 3.2 Justification As part of the continued effort to improve the efficiency of its markets, the ISO has identified three items related to pricing in the ISO markets. These three items, together with the scope of the Administrative Pricing initiative compose the scope of the Pricing Enhancements initiative. The project will specifically focus on: Administrative Pricing Rules Pricing Rules Emergency Tariff Authority Force Majeure Scheduling Priority for Existing Transmission Rights Schedules Compounding Pricing Methodology in the Event of Multiple Contingencies Multiplicity of Prices Under Degenerate Conditions 4. Business Requirements The sections below describe the Business Processes and the associated Business Requirements involved in the project. These may represent high level functional, non-functional, reporting, and/or infrastructure requirements. These business requirements directly relate to the high level scope items determined for the project. 4.1 Business Process: Administrative Pricing Day-Ahead Market Administrative pricing is currently implemented in the real-time market and uses the prices from the interval immediately preceding the interval in which the market disruption occurred or the ISO has effectuated a market suspension. The ISO occasionally experiences minor market disruptions in the real-time market due to software maintenance or unexpected software issues, these occur under normal and non-emergency situations. The ISO can also intervene in the ISO markets during system emergencies or to prevent system emergencies and suspend or disrupt the market and operate the system manually, in which case the Administrative price will also apply for purposes of settling imbalance energy. Doc ID: GNFDMDEHU6BB Page 6 of 16

7 4.1.1 Business Requirements ID# Business Feature Requirement Type Potential Application(s) Impacted BRQ001 The administrative pricing shall apply to any market or product including the day-ahead market, RTD, and RTPD markets. Core IFM/RTM BRQ002 If the DA solution is not available by 18:00hrs, the ISO shall trigger specific provisions listed in the following requirement (see BRQ003). Core IFM/RTM Doc ID: GNFDMDEHU6BB Page 7 of 16

8 ID# Business Feature Requirement Type Potential Application(s) Impacted BRQ003 In case of a market disruption or market suspension, such as a software issue that results in a complete failure to clear the market and post results for that day, the ISO shall use one of the following approaches: In case of a market disruption or market suspension, such as a software issue that results in a complete failure to clear the market and post results for that day, the ISO shall use one of the following approaches: Core IFM/RTM 1. Use the day-ahead results (both awards and prices) from the previous day. 2. If based on the expected system conditions it is found that using the previous day will not provide a reasonable profile of schedules to meet the needs of the real time (Monday is a different load profile or transmission condition than Sunday), and the real-time market is operating well, the ISO shall leave the entire market up to the real-time market, with the need to manually dispatch long start units, and other units as needed, and adjust conditions based on manual instructions. Business Rule: Selection of item 1 above will depend on the evaluation of the expected system conditions and the schedules from the previous day ahead to determine that the previous day dispatches are within a reasonable scope to be used for the missing day. The ISO shall also look at the health of the real-time market when making the determination. Business Rule: If there is an event also impacting the real-time market, the real-time market also defaults to use the day-ahead results. Business Rule: The scope of this initiative only covers CAISO area entities and not EIM entities. The EIM enhancements initiative shall consider rules associated with EIM entities. Doc ID: GNFDMDEHU6BB Page 8 of 16

9 4.2 Business Process: Administrative Pricing Real-Time Market Administrative pricing is currently implemented in the real-time market and uses the prices from the interval immediately preceding the interval in which the market disruption occurred or the ISO has effectuated a market suspension. The ISO occasionally experiences minor market disruptions in the real-time market due to software maintenance or unexpected software issues, these occur under normal and non-emergency situations. The ISO can also intervene in the ISO markets during system emergencies or to prevent system emergencies and suspend or disrupt the market and operate the system manually, in which case the Administrative price will also apply for purposes of settling imbalance energy Business Requirements ID# Business Feature Requirement Type Potential Application(s) Impacted BRQ004 A three-tiered approach shall be used for administrative pricing for the real-time markets (please refer to Appendix B for examples): Core IFM/RTM 1. If the 15 minute market prices are missing for less than four consecutive intervals or if the 5 minute interval dispatch market prices are missing for less than 12 consecutive intervals, then the ISO shall preserve the current administrative pricing of using the last best price for each market accordingly. 2. If the 15 minute market prices are missing for more than three consecutive intervals or the 5 minute market prices are missing for more than 11 consecutive intervals under normal system conditions then: a. If the real time interval (RTD) dispatches prices are not available but the 15 minute market prices are available, then the missing RTD prices will be filled in with the 15 minute markets, regardless of how many intervals are missing as long as the missing prices are related to a market disruption and the market is unable to produce prices. If the 15 minute prices are missing but the 5 minute market prices are available, the 5 minute prices shall be used to fill in the 15 minute prices by using the simple average of the three RTD prices. Doc ID: GNFDMDEHU6BB Page 9 of 16

10 ID# Business Feature Requirement Type Potential Application(s) Impacted BRQ004 (cont.) o There may be conditions in which both the 15 minute nor the 5 minute market prices are not available and the replacement process described in (a) cannot be implemented. The ISO shall use the day-ahead price for the same trading date and hours which would provide certainty of what prices are being used if administrative pricing is triggered, and will also minimize imbalances charges across markets when a real-time market disruption happens. Core IFM/RTM; Settlements 3. The logic described in 1 & 2 above shall cover non-emergency instances of market disruptions where prices are missing and an administrative price is required. The third tier is designed to address instances where an administrative price is required to deal with atypical scenarios not covered in the above two tiers. This approach shall only be triggered under conditions where the ISO has suspended the market. This could occur under two scenarios: a. the market could fail as a result of catastrophic software failure; or b. the market results are of such poor quality that system operations cannot rely on them for reliable operations of the grid. The ISO shall use the day-ahead prices. Since there will be no real-time market functionality, for purposes of settlements the bids from the day-ahead market will be used as well. BRQ005 The ISO shall copy over applicable prices from the relevant location, resources, and market. Core IFM/RTM 4.3 Business Process: System Emergencies, Force Majeure, and Settlement Implications Business Requirements Doc ID: GNFDMDEHU6BB Page 10 of 16

11 ID# Business Feature Requirement Type Potential Application(s) Impacted BRQ006 The ISO shall make the appropriate tariff amendments to explicit that force majeure events do not excuse any financial obligation to resources participating in the market. Tariff N/A BRQ007 The ISO shall make the appropriate tariff amendments to define settlement implications regardless of whether a system emergency is due to a force majeure or not. Tariff N/A Doc ID: GNFDMDEHU6BB Page 11 of 16

12 4.4 Business Process: Priority of Self Schedules with Existing Transmission Rights Currently, all existing transmission contract (ETC) and transmission ownership rights (TORs) are exempt from any congestion charges for their schedules in the day-ahead and real-time market. The ISO reserves the capacity associated with such rights on interties but does not do so on internal locations. SCs submit specific types of selfschedules in order to be eligible for such treatment. SIBR validates that only holders of such rights receive exemptions from congestion charges by validating that the ETC/TOR self-schedule is associated with specific contract reference numbers. The ISO has observed specific cases where a market participant submitted an ETC/TOR self-schedule but used an erroneous contract reference number, in which case the wheel through becomes unbalanced and the ETC/TOR self-schedule loses its scheduling priority and are treated as self-schedules are passed to the market system as regular price-taker self-schedules, producing unintended consequences for the market as well as the ETC/TOR holder Business Requirements ID# Business Feature Requirement Type Potential Application(s) Impacted BRQ012 If a SC submits an ETC self-schedule on a contract path with a zero entitlement (due to a derate or outage) the system must have the capability to reject the ETC/TOR self-schedule. Core SIBR BRQ013 System must validate that the ETC/TOR selfschedule does not exceed the registered maximum for the resource. Existing Rule Master File BRQ014 Market Participants shall be notified if their schedule is rejected. Existing Rule SIBR Doc ID: GNFDMDEHU6BB Page 12 of 16

13 4.5 Business Process: Compound Pricing of Multiple Contingencies Business Requirements ID# Business Feature Requirement Type Potential Application(s) Impacted BRQ015 System must change the model of how the ISO prices the transmission constraint. Previously, the slack variable was associated with the individual transmission constraint including contingency constraints. After the project, the slack variable must be associated with the flowgate. All constraints related to this flowgate must have the same slack variable. This applies to all market processes. Core IFM/RTM Doc ID: GNFDMDEHU6BB Page 13 of 16

14 5. Appendix B: Examples Doc ID: GNFDMDEHU6BB Page 14 of 16

15 Doc ID: GNFDMDEHU6BB Page 15 of 16

16 Doc ID: GNFDMDEHU6BB Page 16 of 16