External Business Requirements Specification. Outage Management System Phase 3. June 19, 2012

Transcription

1 External Management System Phase 3 June 19, 2012

2 Disclaimer All information contained in this draft (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 revise or withdraw all or part of this information at any time at its discretion without notice. OMS Phase 3 Project Page 2 of 15

3 Table of Contents 1. INTRODUCTION PURPOSE REFERENCES DETAILS OF BUSINESS NEED/PROBLEM BUSINESS ISSUES BUSINESS PROCESS IMPACTS HIGH LEVEL BUSINESS PROCESS DESCRIPTION ASSUMPTIONS & CONSTRAINTS JUSTIFICATION GENERAL BUSINESS REQUIREMENTS GENERAL / GLOBAL REQUIREMENTS GENERAL TO GENERATION & TRANSMISSION BUSINESS REQUIREMENTS EQUIPMENT ID MAPPING (SPECIFIC TO OMS) BUSINESS REQUIREMENTS GENERATION MODULE BUSINESS REQUIREMENTS GENERAL BUSINESS REQUIREMENTS... 9 OUTAGE APPROVAL... 9 OUTAGE MONITORING OMS WEB CLIENT BUSINESS REQUIREMENTS ARCHITECTURE BUSINESS REQUIREMENTS BUSINESS PROCESS: ARCHITECTURE BUSINESS REQUIREMENTS TRANSMISSION MODULE BUSINESS REQUIREMENTS BUSINESS PROCESS: MANAGE TRANSMISSION AUGMENTATION BUSINESS REQUIREMENTS BUSINESS PROCESS: REPORTING AND NOTIFICATIONS BUSINESS REQUIREMENTS REPORTING MODULE BUSINESS REQUIREMENTS GENERAL REPORTING...15 OMS Phase 3 Project Page 3 of 15

4 1. Introduction 1.1 Purpose The purpose of this document is to provide users and stakeholders with high-level business requirements for the project. The information in this document will serve as inputs to determine the scope of information systems changes to implement the project 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. The ISO s information technology services (ITS) department will identify additional requirements and systems analysis and may produce To Be business process models, system requirements specifications, and use cases to serve as the set of requirements documents used by the ITS development teams to buy, modify, or build the necessary software and hardware systems. In particular, this document is to address the business requirements in two folds. The first set of requirements is to complete the identification of Generation Management requirements. The second purpose of this BRS is to add up the recently developed business requirements and the requirements that have not been implemented during OMS Phase 1 and Phase References All references represent external requirements documents or stakeholder requests developed and submitted by the Business Units. 1. Current stakeholder documents are located in x 2. Details of Business Need/Problem 2.1 Business Issues In 2001, the ISO introduced the Scheduling and Logging system for the CAISO ( SLIC ) application to assist in transmission and generation outage coordination and logging management. Since its introduction, SLIC has gone through a major re-write and several major upgrades in order to keep pace with developing and maturing outage scheduling business practices. To further assist SLIC, ISO introduced the CAISO Modeling Tool ( COMT ) application late COMT was designed to augment transmission outage information into the physical ISO network and market systems. Management Since 2007, the ISO has experienced increased outage transactions. OMS Phase 3 Project Page 4 of 15

5 System Analysis At present, the Management team spends considerable time studying outage impacts on the ISO system. In an effort to expedite outage management studies and decisions, the System Analysis version will capture business requirements to address moving existing manual processes to systematic processes, outage studies, outage volume, resource time savings, et cetera. Re-Rates Management In addition to outage management, SLIC/COMT users have encountered issues when managing permanent and temporary transmission rating changes (re-rates). Economic dispatch, nodal pricing, and stability analysis rely on an accurate representation of the capabilities and current state of the electrical power network. Without an accurate representation of transmission constraints, market systems can produce infeasible dispatches or phantom congestion. Without knowledge of transmission line section re-rates, market systems may generate congestion that must be relieved, which could incur additional overhead. Permanent and temporary transmission line re-rate information can be provided more quickly to network and market models. Furthermore, there is a need to automate several business processes in the development of the Management System. Both line re-rate types are impacting Scheduling with the required time to implement into the network models: OMS 1. Permanent transmission line re-rates At present, implementing this type is a six (6) week network build process. 2. Temporary transmission line re-rates (equipment outage related) At present, this type is implemented via the SLIC application and manual entry into the Siemens Scheduler. The Management System ( OMS ) is a multi-year, strategic effort addressing outage application functionality in a modular approach. This project implements Phase 3 of the OMS effort. OMS will meet the following goals/objectives: North American Electric Reliability Corporation (NERC) Standard TOP Planned Coordination (October 17, 2008) Consolidation of the COMT application and SLIC outage functionality Improve outage management quality, productivity, and data accuracy for the OMS and downstream systems Improve automated line re-rate data synchronization between systems Accelerated market application reporting Provide a high-degree of user functionality through increased system automation and equipment identification mapping Automate identified manual processes (i.e., require fewer business resources through increased system automation) Avoid costly system maintenance through solid system design Generate intuitive reporting Data storage/maintenance savings with a centralized data repository System architecture and framework flexibility Benefits of the OMS Program Transmission Phase Implements a one-stop shop for performing transmission outage workflow: creation to augmentation. OMS Phase 3 Project Page 5 of 15

6 Removes user ambiguity, removes a high degree of manual workflow, and consolidates today s COMT application and SLIC s transmission outage functionality into one base application with additional functionality. Systematically captures transmission line re-rates, which will be passed to network models and market applications for processing. Increases outage processing under system control; e.g., increased data filtering functionality, current manual processes. Increases report functionality, accuracy, and ease of use. Introduces reporting data visually in Gantt-like chart format utilizing a Gantt-like chart generation tool and outage information on geographical maps. Equipment ID Mapping Automates a mapping method to forward and reverse identify an equipment ID regardless if participant is ISO or non-iso. Allows application user to perform ID search by PTO equipment ID (entered via Transmission Register) or search by EMS / CIM equipment ID. Search result will yield both mapped IDs. One-Line Diagrams Provides a visual diagram representing sub-stations (buses, lines, breakers, switches, etc.) that will allow a user to select equipment, open/close switches, etc. and commit any changes from the diagram. Significantly reduces manual interpretation and removes time consuming data searches. System Analysis Phase Provides new system processes for auditing, reproducibility, accuracy, transparency of process, consistency, and timeliness. Allows quicker application/process training. Provides users of different authentication levels different access functionality to the same processes that can accomplish the same goals (i.e., list of approved outages while still maintaining a reliable/efficient system). Provides for efficient outage studies. Generation Phase Removes functionality from SLIC and incorporates into OMS, thus finalizing the creation of a single application that will process an outage in its entirety. Incorporates generation functionality with transmission functionality and all enhanced outage functionality implemented with the transmission phase. Removes data redundancy with the introduction of a single OMS data repository. Data not requiring OMS storage will be referenced from other ISO system repositories. 3. Business Process Impacts 3.1 High Level Business Process Description The OMS Program and the respective versions/sub-versions will require modification or replacement of the ISO documented business processes as each process either references or directly addresses the SLIC and/or COMT applications. The ISO business processes impacted through this OMS Program are listed below. - Close DAM Bidding - Determine Generation of OTC - Evaluate Generation Initial Review & Request - Evaluate Generation Modification Request OMS Phase 3 Project Page 6 of 15

7 - Evaluate Generation Request - Manage Extreme Long-Start Commitment (ELC) - Manage Generation s - Manage Request Submission - Manage Real Time Impacts to ETC & Network Model - Manage Resource Interconnections - Manage Transmission Request Evaluation - Manage Transmission s - Receive SLIC Request 3.2 Assumptions & Constraints The following define OMS program assumptions. # Description 1 Participating Transmission Owner ( PTO ) may initially enter and reference equipment using the Transmission Register naming designation. 2 The source of valid equipment for physical model representation and augmentation selection will utilize existing data whenever possible. 3 Equipment mapping repository or PTO-provided mapping is implemented with the transmission phase. 4 OMS can reference equipment mapping repository. 5 Temporary line section rating decreases will be treated as outage similar to how equipment based transmission outages are handled today. 6 Permanent transmission line section rating changes will be initiated through the PTO and Transmission Register. Temporary transmission line section rating changes will be initiated through a Participant Coordinator or ISO Coordinator. 7 Pseudo outages as a result of temporary line section rating changes will follow the same workflow as a transmission equipment outage 8 To further improve outage processing and ultimately remove OMS outage augmentation functionality, PTO s will be required to submit additional outage data not captured today. 3.3 Justification In additional to the benefits discussed in Section 2.1, the OMS Program will provide advanced technical solutions to current manual and system problems, and increase day-to-day outage management productivity while placing many of today s manual, time consuming processes under system control. With conversion to system controlled processes, realized savings will appear in reduced human error, increased ease-of-use, substantial increase data accuracy and removal of data redundancy, internal and external standards compliance, and alignment with MRTU standards. 4. General Business Requirements The following sections describe the project s business processes and/or business requirements. Each section/sub-section represents high-level functional, non-functional, reporting, performance, and/or security requirements. 4.1 General / Global Requirements OMS Phase 3 Project Page 7 of 15

8 BRQ080 BRQ081 BRQ700 BRQ721 BRQ724 OMS screens will provide each user the ability to establish default settings and/or load with last settings used. OMS GUI will provide ability to load with default screens and locations and/or load with last screen configuration during previous session. OMS will recognize up to 25 screens that can be defined for initial load. OMS must publish outage data according to existing SLIC rules. OMS must provide an API to external users that will retrieve the revision history of actual availability or Pmin value for re-rates including the effective date and time stamps. OMS must update existing outages after receipt of new reference data which includes mapping of old to new equipment. 4.2 General to Generation & Transmission Business Requirements BRQ096 BRQ577 BRQ581 BRQ725 OMS will recognize outage status types: Pending Approved Cancelled Requested Disapproved Withdrawn Scheduled Ready OMS will allow a user to attach one or more files (voice, , etc.) to an outage and open the file(s) from within the outage if the application program that can open/execute the file(s) exists. The ability to manage outages must be restricted to the users (Business Associates) access time-frame: past, present, and future. The OMS must allow for different attribute types, including Boolean and multivalue attributes. 4.3 Equipment ID Mapping (specific to OMS) This section defines requirements that will be implemented within the OMS project if the equipment ID mapping effort is not implemented with or before the OMS project Business Requirements BRQ557 The equipment mapping repository must have record of all equipment used by ISO systems/applications or supporting external (e.g., WECC IDs). OMS Phase 3 Project Page 8 of 15

9 5. Generation Module Business Requirements 5.1 General The general business requirements are global to the generation outage business processes Business Requirements OMS must allow a user to submit, update and view a Generation. BRQ180 BRQ181 OMS must allow a user to submit, view and modify Ancillary Service (AS) Availability, including the following MW values: BRQ183 BRQ184 BRQ185 BRQ186 BRQ187 BRQ188 BRQ189 BRQ191 Spin Non-Spin Regulation Up Regulation Down OMS must allow a user to perform a Quick Find on an outage. OMS must allow a user to search for a generation outage. OMS must display current Generator Reference data for applicable outages, including: Resource Adequacy (RA) indicator Resource current MW availability Use Limited (UL) indicator RA Supply Plan data Resource Bio Net Qualifying Capacity OMS must allow a user to query outage history. OMS must allow a user to submit substitute units for RA when submitting a new/updated outage, which requires the ISO s review and approval. This functionality will be transferred from RAAM to OMS. OMS must allow an authorized user to view outages grouped by: Fuel type User RA Location OMS must allow an authorized user to configure (customize) outage grouping views. Approval OMS must provide auto approval functionality that allows a user to identify and accept outages depending on certain criteria such as type, derate threshold value, etc. that are configurable. OMS Phase 3 Project Page 9 of 15

10 OMS must allow a user to filter outages that have been auto approved by: BRQ192 Approval date start date BRQ193 BRQ196 BRQ197 BRQ198 BRQ199 BRQ201 BRQ202 BRQ203 BRQ204 BRQ205 BRQ249 OMS must allow a user to add and view the reason why an outage was rejected by the ISO. Monitoring OMS must allow aggregate resources to submit and view a single outage for multiple units including black start availability of child resources. OMS must allow a user to optionally submit Pmin availability values for MSG units. OMS must allow the submission of outages on interties and Non-Resource Specific (NRS) resources. OMS must allow a user to view historical outage data, including SLIC data, migrated into OMS at implementation time. OMS must ensure RA MW capacity is displayed for all resources, including generators and NRS units. OMS must provide a test area (sandbox) for Market Participants to model outages without submitting to production, including auto approval functionality. OMS must allow a user to search for cause codes by keywords. OMS must enable submission of a single outage card where availability changes by day/hour over very long time period (e.g. 60 days). OMS must allow a user to submit and view multiple Pmin availability points for units undergoing testing. OMS must allow update of outages with a large number of availability points over a long period of time. BRQ210 BRQ211 OMS will allow outages to be created for PMAX Derates (partial derate or offline), PMIN rerates, RampRate adjustments and Economic Shutdown, and AS derates. In addition to common outage data, generation outages will capture the following operational data: PMAX derates mw profile of maximum generation (MW Availability) for duration of outage PMIN rerates mw profile of minimum generation for duration of the outage Ramp Rates adjustments changes in ramp rates segments for duration of outage Economic Shutdown duration of shutdown MW Curtailment curtailment of generator based on outage Child Resources associated with outage s can be created/edited by ISO personnel based on their security role for any existing/active resource. s can be created/edited by Market Participants based on their security role for only resources that they have permissions for. BRQ212 BRQ213 As defined in MasterFile, resources only have one BA relationship for any OMS Phase 3 Project Page 10 of 15

11 BRQ214 point in time, but OMS will allow the use of SubBA to define additional relationships such that external users from different entities access to all or a subset of a BA s resource portfolio. BRQ215 BRQ217 BRQ218 BRQ219 BRQ220 BRQ221 BRQ222 BRQ223 BRQ224 BRQ225 BRQ227 BRQ228 BRQ230 Note that during 2012 the ISO will no longer allow new SubBAs to be created. Market Participants can have access to multiple BA and/or SubBA. Access to each BA/SubBA can have either Read/Write or Read-Only access. The OMS must be able to receive and store multiple future network models and process planned outages against the resources in the future model(s) including the resources commercially not available (in other words, though the commercial model is not ready yet). s cannot be created with start times before configurable offset from the current time. OMS must allow date/time backdating to be configurable. For example, outages cannot be created with start time before 7 days in the past. s can be created by Market Participants for dates when their BA/SubBA access has a relationship with the resource. For example if a BA takes ownership on 12/1, a user from the BA/SubBA cannot create an outage starting on 11/30. Resources can have overlapping outages. Only one version of generation operational data (MW Availability, PMIN rerates, Ramp rates) exists per resource, for each point in time. If resources have overlapping outages, making changes in one outage will change the resource s data for that outage s time period. Changes to that resource s data will be reflected in all overlapping outages, for given time period, without requiring changes to the overlapping outages. Each change to outage by either ISO personnel or via request from MP requires a reason code selected from a list of valid codes, reason text describing why outage is being updated and in case of an MP request, a contact phone number. All requests from Market Participants to create or update outages will not change any data until it has been accepted by ISO personnel or auto-accepted by OMS system based on the business rules. All requests to create or update outages that have not been accepted into OMS will be available in a display for ISO personnel to process. All requests to create or update outages that have not been accepted into OMS can either by accepted or disapproved (with a reason) by ISO personnel or withdrawn by the Market Participant. Certain types of requests will be auto-accepted by OMS. The types should be configurable. Types or requests that will be auto-accepted include but not limited to: Real time generation forced immediate outages Real time generation availability changes Real time generation end outage requests not exceeding 30 minute deviation from scheduled end time Real time generation non-operational information changes Ambient derate less than a certain MW that is configurable Auto accepted requests will be shown in a display for user review and acknowledgement. Market Participants must submit a Start request within configurable amount of time before the outage starts in order to get a last confirmation that the outage is ok to start. If request is accepted, OMS will change status to OMS Phase 3 Project Page 11 of 15

12 OUTOK. BRQ231 Market Participants must submit an End request within configurable amount of time before the outage ends in order to get a last confirmation that the outage is ok to end. If request is accepted, OMS will change status to INOK. BRQ232 BRQ233 BRQ729 BRQ730 BRQ731 BRQ732 BRQ588 OMS will automatically change the status of an outage, which has not received a start/end outage request, to ETOTIMEOUT/ETRTIMEOUT at a configurable time before the outage starts/ends. OMS will generate alarms/notifications when a generator outage is created where availability conflicts with other outages that require generator to be available. OMS must have the ability to configure (add) additional information for use limited generation outage including, but not limited to, limit duration, hourly run limit, and start time. OMS must be able to denote an outage on the generation resource s PSS and/or AVR with an Affects PSS/AVR flag. An outage with this flag selected will trigger a warning, alerting the dispatcher that a VRCC notification might be required. OMS must be able to generate a warning for any outage on a Blackstart resource that removes the resource s Blackstart capability (e.g. availability = 0), alerting the dispatcher that a VRCC notification might be required. OMS must be able to denote an outage derating ancillary service ( AS ) capability of a resource with an Affects A/S flag, and for the external user to list its available AS capacities of the resource by commodity, e.g. Regulation Up, Regulation Down, Spin and Non-spin. This type of outage will automatically populate the Market Systems and will exclude the resource from being scheduled for any AS. This type of outage will also generate a warning, alerting the user of reduced AS capability. The system should allow PMIN Rerate cards to support multiple point OR allowing availability points to be set in all outage cards for both the max AND min limits of the card. 5.2 OMS Web Client Web Client requirements are specific to the external facing (i.e., publicly exposed) piece of OMS application Business Requirements BRQ243 BRQ244 BRQ246 BRQ247 OMS Web Client will contain no OMS system/administration access. OMS Web Client will be a secure, Internet accessible site that will require an ISO provided certificate(s) and user authorization to access. Until the new OMS web client is implemented, OMS must utilize the existing web client and/or API to gather outage information from Market Participants (both PTO and SC). OMS must provide web client users the ability to print to the users recognized printers. OMS Phase 3 Project Page 12 of 15

13 BRQ248 BRQ251 BRQ253 BRQ257 BRQ250 BRQ252 From within OMS web client, external customers must be able to alter transmission and/or generation outage times according to business rules. OMS Web Client will not be coupled to OMS system (utilize the API framework to enter outage information no direct line of communication data). OMS Web Client will allow a user to perform the following outage tasks: Create outage Modify outage including cancel or delete (the data that can be modified will depend on business rules) View outage details View request details Notify user when watched outage or request has been updated Search for outages Search for requests on outages Display current tasks for user to perform Allow for quick entry of outage with minimal data inputs View generation operational data (MW Availability, PMIN rerates, RampRate Adjustments) for resource View API xml requests / responses made during web client session to aid in API development Download base data used by web client and necessary for API development. For example one download would be the list of resources and supporting data OMS Web Client will be available for regulatory users who have read-only access to all outages. OMS must provide API data that is consistent with data provided on the GUI. OMS must allow retrieval of cause codes by API. 6. Architecture Business Requirements 6.1 Business Process: Architecture The following requirements represent enhancements to OMS architecture to meet current ISO standards Business Requirements BRQ525 OMS must support standardized web services (SOAP/XML, ISO s XSD), https for external; JMS for internal. OMS Phase 3 Project Page 13 of 15

14 7. Transmission Module Business Requirements 7.1 Business Process: Manage Transmission Augmentation The following requirements represent planned enhancements to Transmission that were not implemented in Phase 2. This section s transmission outage requirements seek to enhance transmission outage management by increasing system responsibility, reducing/removing manual process(es), and incorporating the user of equipment ID mapping. The following reflect OMS inputs and outputs specific to transmission outage management: OMS Inputs: SLIC Web Client outage information will become OMS Web Client Temporary re-rate information Alerts, Warning, Events system information Master File data Equipment source database (GDB) will become mapped equipment IDs (TR CIM) Network model build information GDB/EMS physical network model data for graphical displays of equipment for validation and future selection OMS Outputs: Date range of outage Equipment detail Megawatt Value during outage Transmission Line De-Rate information Downstream data Reports Business Requirements BRQ140 BRQ150 BRQ551 On a daily basis, OMS system will systematically send all active outages to the WECC COS/EIDE systems using WECC s predefined APIs. Additionally, OMS will allow a user to manually execute the send process. OMS must maintain the entire history of each outage from inception to completion/cancellation. OMS must receive and apply external area outages from WECC EIDE data. This will require a mapping file between the WECC defined branch and generator names and those in the ISO Network Model. A process will need to be developed to receive outage information from the WECC EIDE application and include them with other ISO transmission owner submitted schedules. 7.2 Business Process: Reporting and Notifications Reporting and notification requirements will define how OMS will handle and improve informing a user from the business level. OMS s initial goal is to convey information to online/offline authorized OMS users and nonauthorized OMS users via online, softcopy, and/or hardcopy media. OMS Phase 3 Project Page 14 of 15

15 7.2.1 Business Requirements BRQ701 BRQ179 BRQ710 BRQ742 OMS user notifications are a subscription based service. OMS must provide individual users and/or user groups the ability to subscribe/un-subscribe to notification (e.g., Customers, Coordinators, Dispatchers, etc.) OMS must provide external customers the ability to generate outage reports for their own data. OMS must send an alarm to subscribers when these conditions apply: begins in five minutes (time configurable) ends in five minutes (time configurable) Forced Report due in three days (time configurable) Forced Report missing OMS will dynamically send an external user the outage status through the external user s API when the external user request the status report. 8. Reporting Module Business Requirements The reporting module addresses the physical output (reporting) of data that has been presented to a user. Reports can be canned or user defined. 8.1 General Reporting BRQ560 BRQ561 OMS will be able to be configured to generate regulatory reports and compliance reports for Rules of Conduct to CPUC, CEC, WECC, NERC, FERC, other regulatory agencies when required. OMS must allow a user to search for and view outages on all units that the user has access to. OMS Phase 3 Project Page 15 of 15