Texas Nodal
TN.MMS
Requirements Specification
For Outage Scheduler
Version 1.10
0927 FebruaryApril, 2007
Texas Nodal TN.MMS / Version: 1.10Requirements Specification For Outage Scheduler / Date: 042/2709/2007
Revision History
Date / Version / Description / Author08/03/2006 / 0.01 / New document based on template version 1.2 for requirements and use case specification / ABB Outage Scheduler Team
08/25/2006 / 0.02 / R. Matlock (ERCOT) and ABB-generated changes. Template version 1.2 / ABB Outage Scheduler Team
08/30/2006 / 0.03 / R. Matlock updated FRs / Robert Matlock
09/01/2006 / 0.04 / R. Matlock removed use cases / Robert Matlock
10/25/2006 / 0.05 / New document based on template version 1.4 received from ERCOT on 23 October and ERCOT feedback till October 24, 2006 / ABB Outage Scheduler Team
11/02/2006 / 0.06 / Reintroduced FR1-5, FR1-6, FR1-7, FR1-8, FR1-9, FR1-11, and FR3-3. Incorporated changes recommended by ERCOT as of November 02, 2006 / ABB Outage Scheduler Team
11/14/2006 / 0.07 / Incorporated changes recommended by ERCOT as of November 13, 2006 / ABB Outage Scheduler Team
11/21/2006 / 0.08 / Incorporated changes recommended by ERCOT including those from the IDA as of November 21, 2006 / ABB Outage Scheduler Team
01/09/2007 / 0.09 / Incorporated ERCOT and TPTF comments and recommended changes – summarized in e-mail from Venkat Gajjela on January 8, 2007 – including the removal of FR1-7 and FR1-11 (i.e., Disable Continuous Outage and Convert Tentative Outage, respectively) / ABB Outage Scheduler Team
01/19/2007 / 0.10 / Incorporated changes recommended by ERCOT and input provided by ABB and discussed with ERCOT in telephone conversation on January 18, 2007 (Robert Matlock and the ABB team) – This document includes red-lining for all changes since version 0.08 (draft 0.09 and 0.10) / ABB Outage Scheduler Team
01/24/2007 / 0.11 / Changes made from outcome of TPTF meeting 01/22/2007 / Sai Moorty
02/21/2007 / 0.12 / Incorporated changes communicated by ERCOT in the February 16 e-mail and from the ERCOT/ABB conference call on February 19, 2007 to reflect agreements with the TPTF / ABB Outage Scheduler Team
02/26/2007 / 1.0 / Incorporated changes communicated by ERCOT in the February 26 e-mail and from the ERCOT/ABB conference call on February 26, 2007 to reflect final and minor changes to be approved by TPTF. This includes the change in FR3-1 (a new bullet for the RSA statistics) and updates in Table 1 in Section 5.
04/096/2007 / 1.1 / Incorporated the new definitions of Transmission and Resource Opportunity Outages and the corresponding changes to the state diagram and warning procedures as of April 9, / ABB Outage Scheduler Team
Document Approval
Date / Approved/Rejected / Approved/Rejected By / Signature
(indicate if electronic approval)
<Name>
<Role
Table of Contents
1. Introduction 6
1.1 Purpose 6
1.2 Objective 6
1.3 Traceability 6
1.4 Definitions and Acronyms 6
2. System Scope 77
2.1 As Is Sub-Process for the Outage Scheduler System 77
2.2 To Be Sub-Process for the Outage Scheduler System 77
2.3 Differences between the As Is and To Be Sub-Process 88
2.4 Assumptions and Dependencies 88
3. Functional Requirements 99
3.1 External Client Requirements 1010
3.1.1 FR1-1 Submit Outage Request 1010
3.1.2 FR1-2 Edit Outage Request 1212
3.1.3 FR1-3 Cancel Outage Request 1212
3.1.4 FR1-4 Create Outage Extension 1313
3.1.5 FR1-5 Create Recurring Outages 1313
3.1.6 FR1-6 Copy Existing Outage 1313
3.1.7 FR1-7 Create Opportunity Outage 1415
3.1.8 FR1-8 Create Outage Group 1616
3.1.9 FR1-9 Respond to Warning (External Client) 1717
3.2 Internal ERCOT Requirements 1717
3.2.1 FR2-1 Study Outage 1717
3.2.2 FR2-2 Approve, Accept or Reject Outage 1818
3.2.3 FR2-3 Withdraw Outage 1818
3.2.4 FR2-4 Respond to Warning 1919
3.2.5 FR2-5 Manage Unit Relationship 1919
3.3 Information Exchange Requirements 2020
3.3.1 FR3-1 Post Outage Information 2020
3.3.2 FR3-2 Interface of Outage Information to Other ERCOT Systems 2021
3.3.3 FR3-3 Export Outage Data 2021
3.3.4 FR3-4 Import Transmission Element Names 2021
3.3.5 FR3-5 Programmatic Interface 2223
3.4 Administration Requirements 2223
3.4.1 FR4-1Manage Users and Roles 2223
3.4.2 FR4-2 Manage Outage Versions 2424
4. Supplementary Requirements 2525
4.1 SR-1 Performance Requirements 2525
4.2 SR-2 Legal and Regulatory Requirements 2525
4.3 SR-3 System and Communication Requirements 2626
4.4 SR-4 System Security Requirements 2626
4.5 SR-5 Back Up and Recovery Requirements 2626
4.6 SR-6 Availability and Redundancy Requirements 2626
4.7 SR-7 Maintainability Requirements 2626
4.8 SR-8 Training and Documentation Requirements 2626
4.9 SR-9 Usability Requirements 2727
4.10 SR-10 Use of Rules Engine 2727
5. Protocol Coverage 2828
6. Sub-Process Coverage 3232
A. Definitions and Acronyms 3333
A.1 Definitions 3333
A.2 Acronyms 3636
B. Outage Life-Cycle Matrix 3838
C. Outage State Transitions 3939
D. Configurable Rules 4242
D.1 User Role Rules 4242
D.2 Validation Rules for Submitting Outages 4242
D.3 Submittal Time Line Rules 4343
D.4 Outage Editing Rules 4343
D.5 State/Status Rules 4343
D.6 Outage Extension Rules 4444
D.7 Outage ID and Version Tracking Rules 4444
D.8 User Preferences Rules 4444
E. Outage Submission and Approval Requirements and Guidelines 4545
Requirements Specification
(This Requirements Document is Subordinate to and Compliant with the Texas Nodal Protocols effective May, 2006.)
1. Introduction
The primary authority directing the operational characteristics and behavior of the Outage Scheduler system is the Texas Nodal Protocols. This requirements document is provided as a supplement to assist in the implementation of this system which includes all processes, tools (hardware and software), and operations and constraints necessary for full compliance to the Texas Nodal Protocols. The Texas Nodal Protocols with this set of requirements documents completes the System “Design To” definition for implementation, test, and operation of a fully compliant Market Management System.
1.1 Purpose
The requirements for the document Texas Nodal Market Management Systems (MMS) Requirement Specification for Outage Scheduler and its associated processes are described in the Texas Nodal Protocols. This supplemental specification describes the external behavior of this specific sub-system. The Texas Nodal Protocols (Protocols) and this document together with all applied vendor provided products’ functional specifications, describe both functional and nonfunctional requirements, design constraints, and other factors, in order to provide a complete and comprehensive description of the operational performance to be delivered. All statements or requirements specified in this document are subordinate to the Protocols.
1.2 Objective
The objective of this set of documents is to provide a clear, concise and unambiguous set of requirements together with the Texas Nodal Protocols which provides the complete required technical description of this Texas Nodal Sub-System to allow the developer/implementer to deliver a fully operational, compliant and robust Texas Nodal System.
1.3 Traceability
All requirements are traceable to the Nodal Protocols, and/or regulations such as NERC and FERC.
1.4 Definitions and Acronyms
A definition of terms and acronyms used in this document is provided in Appendix A. This list is exclusive of those defined in the “ERCOT Nodal Protocols Section 2: Definitions and Acronyms, May 2006”.
2. System Scope
This section describes the As Is and To Be sub-processes of the Outage Scheduler system. ERCOT has provided the Outage Scheduler team with two sub-process maps, as illustrated in Figure 1Figure 1 and Figure 2Figure 2. Figure 1Figure 1 demonstrates the As Is sub-process, while Figure 2Figure 2 demonstrates the To Be sub-process.
2.1 As Is Sub-Process for the Outage Scheduler System
The current sub-process for managing Outages is illustrated in the As Is sub-process in Figure 1Figure 1. Activities within the Outage Scheduler are highlighted with dashed borders. Outage management activities lead to the creation of an updated Outage Schedule.
The Transmission Network Model, Load Forecast, and Generation Plan together with the Approved Outages are used to evaluate any security or reliability violation linked to the requested Outage(s). If there are no violations, the Outage Request(s) are accepted and the Outage Schedule is updated. Actual Market Operational Data, Estimated Market Data, Registration Data, and Additional Adjustments are input into the Outage Scheduler process.
Figure 1: As Is sub-process for managing Outage activities
2.2 To Be Sub-Process for the Outage Scheduler System
Figure 2Figure 2 illustrates the To Be sub-process for the Outage Scheduler system. In the process diagram below, each process or information source which is hosted by the Outage Scheduler application is labeled “Outage Scheduler” in parentheses. Activities within the Outage Scheduler are represented in the process P-4 and output of the Outage Scheduler is illustrated by the box labeled I-6. The dashed boxes (I-2, P-4 and I-6) represent the Outage Scheduler. Light yellow color (lighter shade) indicates existing processes and dark yellow color (darker shade) indicates new processes.
The TSP or QSE (i.e., the Outage Requestor) submits Outage Requests using the Outage Scheduler. The ERCOT Outage Coordinator creates a Date Determinate Power Flow Model, which includes Approved, Accepted, and Requested Outages, Generation Plan, and Load Forecast. The ERCOT Outage Coordinator then uses this model to perform contingency analysis.
For most Outages, if any requested Outage under evaluation causes pre or post contingent limit violations, the ERCOT Outage Coordinator consults with the Outage Requestor and determines if there is an acceptable solution (i.e., remedial action, generation adjustment, etc). If an acceptable solution exists, the Outages will be Approved or Accepted, if not, the Outage will be Rejected or Withdrawn and rescheduled at a better time.
Figure 2: To Be sub-process for managing Outage activities
2.3 Differences between the As Is and To Be Sub-Process
The To Be sub-process includes Power Flow Analysis for evaluation of the requested Outage(s) using Energy and Ancillary Market Data and Current Operating Plan information in place of what is Generation Plan data in the As Is sub-process.
2.4 Assumptions and Dependencies
Outage Scheduler is a critical application that maintains Transmission and Resource Element availability information. Accuracy and availability of this information to such systems as EMS, MMS and CRR (through the NMMS) is essential for ERCOT market operation. The requirements and assumptions regarding availability, security, performance, and information accessibility for the Outage Scheduler are described in the following chapters in this document.
3. Functional Requirements
This section contains the Functional Requirements for the Outage Scheduler system.
The Functional Requirements have been grouped according to the view of the user. The first group – External Client Requirements - focuses on the originator of an Outage - the Transmission Service Provider (TSP) and the Qualified Scheduling Entity (QSE). The second group – Internal ERCOT Requirements - focuses on the role of ERCOT itself and how Outage Requests are managed by ERCOT. The third group – Information Exchange Requirements - deals with the acceptance and dissemination of Outage data. Finally the fourth group – Administration Requirements - deals with general administrative issues in the system, not directly involved with the submission and management of Outages.
The numbering convention for the Functional Requirements is “FR”, followed by the group number and the intra-group requirement number separated by a dash. For example, FR1-1 addresses the first requirement in the group of External Client Requirements.
To assist in understanding the Requirements Specification document, the following background information is provided.
ERCOT, as an Independent System Operator (ISO) for a large portion of Texas, is required to review and approve, accept or reject Transmission and Resource Outages. The criterion for approval, acceptance, or rejection is adherence with NERC Transmission Security Standards and ERCOT protocols and guidelines. ERCOT has developed and is continuing to develop tools to assist Outage Coordinators in evaluating the transmission security impact of Outages. These tools are described in a companion requirement document “Texas Nodal Energy Management System Requirements Specification for Outage Evaluation”. The Outage Scheduler application described in this document is the operational interface between participants, particularly TSPs and QSEs and Outage Coordination personnel at ERCOT.
3.1 External Client Requirements
3.1.1 FR1-1 Submit Outage Request
Requirement ID / FR1-1Protocol Reference / NP Section 3.1.2, 3.1.3.1, 3.1.3.2, 3.1.4.2, 3.1.4.8, 3.1.5.1, 3.1.5.2, 3.1.5.9, 3.1.5.12, 3.1.6, 3.1.6.1, 3.1.6.2, 3.1.6.8, 3.1.7, NERC Standards IRO-002-1, TOP-003-0, TOP-004-0, TOP-005, TPL-002-0, TPL-003-0, TPL-004-0
Coverage of Protocol / Full – NP section 3.1.2
Partial – all others
Traceability to Sub-Process / P4
Sub-Process Element Coverage / Partial
Description:
Each TSP and QSE shall have the ability to submit to ERCOT their Outage Elements in a timeframe that is a function of the Outage Category and Type. TSPs shall be permitted to submit Outage Requests within the Transmission Category, while QSEs shall be permitted to submit Outage Requests within the Resource Category (Generation and Load).
Refer to Appendix A.1 for Transmission Outage Types. A Forced Extension can only be created from an original Forced Outage that cannot be submitted as a Planned Outage according to ERCOT protocol time lines. Unavoidable Extension can only be created from an original Planned or Maintenance Outage that cannot be submitted as a Planned or Maintenance Outage according to ERCOT protocol time lines. Outage submission time lines according to ERCOT protocols are listed in Appendix E, Table 3. When creating an Outage on a Transmission Element, the TSP shall have the capability of choosing from a list of associated electrical buses, switches and/or breakers for that Transmission Element. The data required to populate these selection lists is provided by the NMMS to the Outage Scheduler.
Refer to Appendix A.1 for Resource Outage Types. Planned Outages are handled differently, whether they are submitted eight days or less, or more than eight days. A Forced Extension can only be created from an original Forced Outage that cannot be submitted as a Planned Outage according to ERCOT protocol time lines. Unavoidable Extension can only be created for an original Planned or Maintenance Outage that cannot be submitted as a Planned or Maintenance Outage according to ERCOT protocol time lines. Outage submission time lines according to ERCOT protocols are listed in Appendix E, Table 3.
Opportunity Outages are a special category of Planned Outages and are described in FR1-7.
The following information shall be provided in an Outage Request for the Transmission Category (varies somewhat based on Outage Category):
· Identification of primary and alternate telephone numbers for the TSP Single Point of Contact, the name of the individual submitting the Outage Request (i.e., Outage Requestor), and location (i.e., TSP)