WECC-0118 Posting 3 IA Removal Posting 2 redlined to Posting 3 Posting... · Web viewEach Sink...

WECC Criterion – INT-020-WECC-CRT-2Interchange Schedule Backup Process

Removal of Interchange AuthorityPosting 23

June 6July 25 through July 6August 25, 2016

Criterion Development Timeline

This section is maintained by the drafting team during the development of the criterion and will be removed upon final disposition.

Description of Current Draft

In accordance with the original Standard Authorization Request WECC-0118, this project is de-signed to remove all references to the Interchange Authority (IA) from the Applicability section and the affected WECC Requirements and WECC Measures. The original scope was expanded by the WECC Standards Committee to include general maintenance and clean-up of the docu-ment. Details of the expanded scope are explained in the Standard Authorization Request (SAR) posted on the project page SAR accordion.

Overview

To meet the specifications of the SAR, WECC Changes in Posting 3

In Posting 3, a number of changes were made.

The Purpose statement was shortened to be more generic. In WR3, WR7 and WM7 prepositions were changed from “by” to “with.” In WR5: 1) suspicion was replaced with the task of reporting atypical output, 2) a 15-

minute response window was added as was a requirement to contact the Reliability Coordinator as well as the software vendor.

In WR6, a 15-minute response window was added. In the Guidance Section sections were added: 1) describing nature of the generic

software (as opposed to the “WIT”), 2) the distinction between WR5 and WR6, and 3) the standard-of-review for WR5.

Requirements WR1, WR7, and WR17 of Version 1.2 were deleted as part of Posting 1. These WRs called for the Interchange Authority to (WR1) monitor the real-time status of the interchange software, and to (WR7) report the failure and (WR17) restoration of the interchange software. The drafting team concluded these functions are protected and preserved in peripheral documents such as the contract between OATI and Peak; therefore, retention of the WRs is not “necessary to implement, to augment, or to comply with Reliability

WESTERN ELECTRICITY COORDINATING COUNCIL155 North 400 West, Suite 200

Salt Lake City, Utah 84103-1114

WECC Criterion – INT-020-WECC-CRT-2, Interchange Schedule Backup Process of 17Posting 2 June 63 July 25 through July 6August 25, 2016

Standards.”1 The DT has suggested the language could migrate to the WECC Interchange Tool Functional Requirement (WITFR) document; however, direct migration of the language is outside of the scope of this project.2

For readability, the document was restructured grouping WRs by time window such as during and after an interchange software failure. Version 1.2, WR8 and WR18 required the Reliability Coordinator (RC) to declare the start and termination of an interchange software failure and also mandated how that declaration would be communicated. These two WRs were combined into Version 2, WR6 of Posting 1 that now requires the RC to notify its Balancing Authorities whenever the interchange software fails and again when the software is restored. Posting 2 does not specify how that notification is to be implemented; rather, the drafting team opted to leave that discretion with the RC in order to provide flexibility to meet the circumstances of the software failure.

Implementation Plan

The Reliability Standards Development Procedures (Procedures) require that an implementa-tion plan be posted with at least one posting of the project. Because the proposed changes are largely clarification and the proposed new requirements carry a minimal burden, the drafting team is requesting an effective date as of “The first day of the first month following WECC Board of Directors approval.”

Expansion of Scope

The drafting team is aware some of the proposed changes are currently outside of the scope of the current SAR and will seek permission to expand the scope of the SAR when the WECC Stan-dards Committee (WSC) meets in June 2016. If the WSC does not expand the SAR, those changes falling outside of the scope of the original SAR will be retracted and the project posted for comment based solely on the SAR as originally drafted.

The expansion of scope request includes:

Change/delete affected defined terms; Use of generic language instead of defined terms wherever possible;1 Per NERC “Regional Criteria” means reliability requirements developed by a Regional Entity that are necessary to implement, to augment, or to comply with Reliability Standards, but which are not Reliability Standards. 2 On October 21, 2010, WECC received a series of Standard Authorization Requests (SARs) requesting review and update of the then-approved INT WECC Criteria. The effort was supported by the Interchange Scheduling and Ac-counting Subcommittee (ISAS) under the auspice of the Operating Committee. The project was colloquially known as the INT Rewrite Project. On concluding its review, the INT Rewrite Drafting Team (DT) identified a number of WECC Requirements that specified software features and concluded these software specifications were better ad-dressed in a technical document designed for that purpose. As a result, those software specifications were re-moved from the associated WECC Criteria and drafted into the WECC Interchange Tool Functional Requirements document.

W E S T E R N E L E C T R I C I T Y C O O R D I N A T I N G C O U N C I L


Conformity of language and sentence structures to match current drafting conventions; Among other things, the Measures should be conformed from “shall provide” to “will have evidence”;

Possessive references to WECC’s software should be changed to non-possessive; General non-substantive changes added for clarity.



Completed Actions Date

WECC-0118 Standard Authorization Request (SAR) received 1/12/2016

WECC Standards Committee (WSC) approved the SAR 1/28/2016

Drafting Team (DT) solicited 1/28/2016

WSC approved the DT 3/8/2016

First DT meeting 4/5/2016

Posting 1 Open 4/7/2016

Posting 1 Closed 5/23/2016

DT Meets to Respond to Comments 5/31/2016


WSC Expands Scope 6/14/2016


DT meets to answer Comments 7/14/2016





Anticipated Actions Date

WSC Meets (TBA) DT requests ballot TBA September 2016



New or Modified Term(s) Used in the WECC Glossary for WECC Criteria and Naming Conventions (WECC Glossary).

This section includes terms for use in the proposed criterion as well as terms proposed for deletion.If approved, the defined term Interchange Authority Emergency would be deleted and replaced with the more generic phrase “interchange software failure.” This avoids confusion associated with declaration of emergency conditions and provides greater discretion as to what constitutes failure. Although the existing definition contains a substantial list of triggering events, the DT concluded it was not exhaustive – nor should it be.

If approved, the defined term Interchange Authority Software Provider would be deleted and replaced with the generic phrase “software provider.” Deletion of the defined term also eliminates the incorrect inclusion of a requirement inside of a defined term (i.e. “Contact information will be provided on the homepage of the WECC Interchange Tool.”) Upon approval by the WECC Board of Directors (Board), this section will be removed and the WECC Glossary will be adjusted accordingly.

Term(s) proposed for Deletion:

Interchange Authority Emergency Interchange Authority Software Provider

Term WECC Board Ap-proval

Approved Definition Term Origin

Interchange Au-thority Emergency

July 29, 2010 A failure of the Interchange Authority software system that prevents the distri-bution of e-Tags to Reliability Coordina-tors, Balancing Authorities, Transmission Service Providers, Purchasing-Selling En-tities, Load-Serving Entities and Inter-change Authorities for assessment of confirmed interchange transactions, for distribution of confirmed interchanged transactions, or both.

INT-020-WECC-CRT-1.2

Interchange Au-thority Software Provider

July 29, 2010 The Help Desk of the Software Vendor who is supporting the Interchange Authority Software System (WECC Interchange Tool).

INT-020-WECC-CRT-1.2



Contact information will be provided on the homepage of the WECC Interchange Tool.


WECC CriterionINT-020-WECC-CRT-2

A. Introduction

1. Title: Interchange Schedule Backup Process

2. Number: INT-020-WECC-CRT-2

[3.] Purpose: The purpose of this document is to establish a coordinated back-stop sched-uling process that protects the reliability of the grid during Interchange-soft-ware failure that prevents the distribution of e-Tag information for assess-ment of confirmed interchange transactions, distribution of confirmed inter-changed transactions, or both.

3.[4.] Applicability:

4.1. Functional Entities:

4.1.1. Reliability Coordinators

4.1.2. Balancing Authorities

4.1.3. Transmission Service Providers

4.1.4. Purchasing-Selling Entities

4.[5.] Effective Date: The first day of the first month following WECC Board of Directors approval.

WESTERN ELECTRICITY COORDINATING COUNCIL155 North 400 West, Suite 200

Salt Lake City, Utah 84103-1114

INT-020-WECC-CRT-2 Interchange Schedule Backup Process of 17

B. Requirements and Measures

WR1. Each Transmission Service Provider shall maintain a record of the transactions on its paths for the current hour plus the next four consecutive hours.

WM1. Each Transmission Service Provider will have a record of all transactions on its paths for the hour reviewed in accordance with WR1 plus the following four consecutive hours.

WR2. Each Purchasing Selling Entity shall maintain a record of its interchange schedules for the current hour plus the next four consecutive hours.

WM2. Each Purchasing Selling Entity will have a record of all of its interchange schedules for the hour reviewed in accordance with WR2 plus the following four consecutive hours.

WR3. Each Balancing Authority shall maintain a duplicate copy of its aggregate Net Scheduled In-terchange (NSI) as previously confirmed bywith the interchange software for the current hour plus the next four consecutive hours.

WM3. Each Balancing Authority will have evidence that it retained a duplicate copy of its aggregate Net Scheduled Interchange (NSI) as previously confirmed bywith the inter-change software for the hour reviewed in accordance with WR3 and the following four consecutive hours.

WR4. Each Balancing Authority shall store a duplicate copy of its aggregate NSI on a storage sys-tem independent from the interchange software tool.

WM4. Each Balancing Authority will have evidence that storage of its aggregate NSI takes place on a storage system independent from the interchange software tool, per WR4.

WR5. Each Balancing Authority and Purchasing -Selling Entity shall report to the interchange soft-ware provider any suspected failureatypical operation of the interchange software. to the Reliability Coordinator and the interchange software provider within 15 minutes of that de-termination, or in accordance with the reporting times established by the software provider, whichever is longer.

WM5. Each Balancing Authority and Purchasing Selling Entity will have evidence that it re-ported to the interchange software provider any suspected failure of the inter-change software,of reports made per WR5. If no failures were suspected attesta-tion ofEvidence may include, but is not limited to, any electronic or hard copy docu-mentation between the parties containing the prescribed report and the time win-dows associated with that fact is sufficient evidence. communication.



For purposes of WR5, what constitutes atypical operation of interchange software is interchange software performance other than that which the software was designed to create. (Please see Guidance Section.)

WR6. Each Reliability Coordinator shall notify its Balancing Authorities wheneverwithin 15 min-utes of confirming that the interchange software failshas failed, and again whenwithin 15 minutes of receiving notification that operation of the interchange software has been re-stored.

WM6. Each Reliability Coordinator will have evidence that it notified its Balancing Authori-ties each time the within 15 minutes of confirming interchange software failedfail-ure, and again whenwithin 15 minutes of receiving notification that operation of the interchange software washas been restored, per WR6. .



The following requirements only apply during failure of the software system(s) designed to dis-tribute interchange information within the Western Interconnection.

WR7. Each Balancing Authority shall operate to the most recent duplicate copy of its aggregate NSI as last confirmed bywith the interchange software (net of all individual adjacent NSI’s).

WM7. Each Balancing Authority will have evidence that it operated to the data contained in its most recent duplicate copy of its aggregate NSI as last confirmed bywith the in-terchange software (net of all individual adjacent NSI’s) or as adjusted by changes al-lowed in this criterion for each specified period covered during interchange software failure, per WR7.

WR8. Each Balancing Authority shall exhaust all of its internal and dynamically scheduled or pseudo-tied external resources before requesting new interchange.

WM8. Each Balancing Authority will have evidence that it exhausted all of its internal and dynamically scheduled or pseudo-tied external resources before it requested a new interchange for each specified period covered during interchange software failure, per WR8.

WR9. Each Sink Balancing Authority shall implement new interchange transactions when neces-sary to maintain load-to-generation balance, reserve requirements, or to maintain reliabil-ity.

WM9. Each Sink Balancing Authority will have evidence that it implemented new inter-change transactions that were necessary to maintain load-to-generation balance, re-serve requirements, or to maintain reliability, for each specified period covered dur-ing interchange software failure, per WR9.

WR10. Each Sink Balancing Authority shall create new interchange by verbally communicating and confirming with the Source Balancing Authority and the Transmission Service Providers that are parties to the transaction.

WM10. Each Sink Balancing Authority will have evidence that, the Sink Balancing Author-ity created and confirmed new interchange with the Source Balancing Authority and the Transmission Service Providers that were parties to the newly created transaction, for each specified period covered during interchange software failure, per WR10.

WR11. Each Sending Balancing Authority that is a party to the newly created interchange transac-tion shall verbally communicate and confirm with each Receiving Balancing Authority and Transmission Service Provider involved in the transaction created by the Sink Balancing Au-thority.



WM11. Each Sending Balancing Authority that is a party to the newly created interchange transaction will have evidence that it communicated and confirmed the newly cre-ated interchange transaction with each Receiving Balancing Authority and Trans-mission Service Provider involved in the transaction created by the Sink Balancing Authority, for each specified period covered during interchange software failure, per WR11.

WR12. Each Balancing Authority shall verbally communicate upward adjustments to existing non-dynamic transactions with each Balancing Authority and each Transmission Service Provider that is a party to the transaction, as if those adjustments were a new transaction.

WM12. Each Balancing Authority will have evidence that upward adjustments to existing non-dynamic transactions were arranged by verbally communicating with each Balancing Authority and each Transmission Service Provider that is a party to the transaction, as if the upward adjustment were a new transaction, for each speci-fied period covered during interchange software failure, per WR12.

WR13. Each Balancing Authority and each Transmission Service Provider shall verbally communi-cate downward adjustments or curtailments to existing non-dynamic transactions with each Balancing Authority and each Transmission Service Provider that is a party to the transac-tion.

WM13. Each Balancing Authority and each Transmission Service Provider will have evi-dence that downward adjustments or curtailments to existing non-dynamic trans-actions were arranged by verbally communicating with each Balancing Authority and each Transmission Service Provider that is a party to the transaction, for each specified period covered during an interchange software failure, per WR13.

WR14. Each Balancing Authority and each Transmission Service Provider shall complete the Trans-action Data Template (Attachment A) for each new transaction.

WM14. Each Balancing Authority and each Transmission Service Provider will have evi-dence that it completed the Transaction Data Template (Attachment A) for each new transaction created during each specified period covered during an inter-change software failure, per WR14.

The following requirements only apply after restoration of software system(s) designed to dis-tribute interchange information within the Western Interconnection.

WR15. Each Sink Balancing Authority shall submit or cause to have submitted an after-the-fact e-Tag, after termination of each interchange software failure and before the end of the after-the-fact e-Tag submission deadline, for each transaction implemented during each inter-change software failure.



WM15. Each Sink Balancing Authority will have evidence that it submitted an after-the-fact e-Tag after termination of each interchange software failure and prior to the end of the after-the-fact e-Tag submission deadline, for each transaction implemented during each interchange software failure, per WR15.

WR16. Each Sink Balancing Authority shall update or cause to have updated its dynamic tags, after termination of each interchange software failure and before the end of the dynamic tag ad-justment deadline, using the actual interchange values that occurred during the interchange software failure.

WM16. Each Sink Balancing Authority will have evidence that it updated or caused to be updated its dynamic tags, after termination of the interchange software failure and before the end of the dynamic tag adjustment deadline, using the actual inter-change values that occurred during the interchange software failure, per WR16.



Version History

Version Date Action Change Tracking

1 June 10, 2010 Operating Committee Approved Developed as WECC-0054. Initial version

1 July 29, 2010 WECC Board of Directors Approved Initial version

1 September 5, 2012 WECC Board of Directors changed designation from “CRT” to “RBP”

Designation change

1.1 January 16, 2013 Errata In Attachment A, the word “Western” was changed to “WECC” in regards to the “WECC Interchange Tool.” In the Purpose statement, the term “Criterion” was changed to “document”. Attachment A was reformatted from Landscape to Portrait. Conformed to current template.

1.1 June 25, 2014 WECC Board of Directors changed designation from “RBP” to “CRT”

Designation change

1.2 January 28, 2016 Errata “WIAB” was added to the Title to match the header. In Attachment A, references to INT-020-WECC-RBP-1 and its location on the WECC Web sites were removed as they are out of date. Reference to the project tracking number was removed from the Attachment and relocated into the document header to match the current template.

2 TBD WECC Board of Directors Approved Developed as WECC-0118. “Interchange Authority” was removed from the Applicable Entity section and affected WECC Requirements and Measures.

When used to describe software, the same term was replaced with “WECC interchange tool.” WECC requirements WR1, WR7, and WR17 were deleted. The RC’s requirement to declare software status was changed to a requirement to communicate that status. PENDING

Disclaimer

WECC receives data used in its analyses from a wide variety of sources. WECC strives to source its data from reliable entities and undertakes reasonable efforts to validate the accuracy of the data used. WECC believes the data contained herein and used in its analyses is accurate and reliable. However,



WECC disclaims any and all representations, guarantees, warranties, and liability for the information contained herein and any use thereof. Persons who use and rely on the information contained herein do so at their own risk.



Attachments

Attachment ATransaction Data Template

WECC Interchange Authority Back-Up (WIAB)

TagID:__________ DateTime Prepared:____________ TimeZone:__________________________

StartDate: _______ StopDate: ____________________ Transaction Type: ____________________

Contact: ________ Phone: _______________________ Fax: _______________________________

Comment: ______________________________________________________________________________

WECC Reserve Requirements Entity: _____________WECC Reserve Requirement Percent:_____________

Generation

Source BA GEN PSE SourcePoint MW Profile Contracts GenProduct

Transmission Segments

S. Entity TransOwner POR POD MW Profile TP TransProduct

Oasis Number

Load

Sink BA Load PSE Sink Point Product Contracts

MarketPath

PSE Product Contract Misc.

Expanded Energy Profiles

StartDate StartTime StopDate StopTime Cur.MW RampDur

Stacked Transmission Allocation Profiles

TP: POR: POD:



StartDate StartTime StopDate StopTime MWLevel TC Oasis#



Rationale

A Rationale section is optional. If Rationale Boxes were used during the development of this project, the content of those boxes appears below.

Guidance Section

The Generic use of Interchange Software

Throughout the Western Interconnection, the interchange software used is colloquially known as the WECC Interchange Tool (WIT), even though WECC neither owns, controls, nor contracts for the software package. The interchange software currently falls under the purview of Peak Reliability. Further, there is an expanded spectrum of the services offered under the contract that are not specifically contemplated in this document.

This document recognizes that the name and attributes of the interchange software, its origin, and its vendor will change from time-to-time. To ensure the viability of this document, the generic term “interchange software” has been used instead of the specific name (proper noun) of the interchange software package.

It is this interchange software package that is used to authorize the implementation of valid and balanced Interchange Schedules between Balancing Authority Areas, and ensures communication of Interchange information for reliability assessment purposes.

RequirementsRationale Boxes were not developed for this project.

WR5 is designed to create an early warning system that incorporates the variable of informed judg-ment. Ideally, this communication loop enhances the ability to identify and remedy interchange soft-ware anomalies before they result in complete software failure. To accommodate this variable, the standard-of-review threshold for adherence to WR5 is to be based on the knowledge and experience of the specific software user at the time the determination was made.

The Requirement and particularly the associated Measure also recognize that although the typical or designed performance of the software can objectively be measured by comparison to the software’s specifications: 1) not all users will have the same knowledge depth regarding the software’s perfor-mance specifications, and 2) the specific software provider may have its own established communica-tion protocols through which a suspected failure or observation of atypical performance should be re-ported. In the latter case, the Requirement is designed to default to the reporting time windows of the software provider should the reporting time windows exceed the prescribed 15-minute window.

Unlike WR5 that is designed for early warning, WR6 addresses confirmed failure of the interchange software. The 15-minute time window was added to Version 2 to ensure a timely dissemination of information.


WECC-0118 Posting 3 IA Removal Posting 2 redlined to Posting 3 Posting... · Web viewEach Sink...

Documents

Transcript of WECC-0118 Posting 3 IA Removal Posting 2 redlined to Posting 3 Posting... · Web viewEach Sink...