WECC Criterion – INT-020-WECC-CRT-2, WECC Interchange Authority Backup Page 1 of 14

Posting 1 April 7 through May 23, 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 Standard Authorization Request WECC-0118, this project is designed to remove all references to the Interchange Authority (IA) from the Applicability section and the affected WECC Requirements and WECC Measures.

To meet the specifications of the SAR, WECC Requirements WR1, WR7, and WR17 of Version 1.2 were deleted. 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 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, and if implemented, would likely be redundant.[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. Further, the proposed WR6 no longer mandated how the RC shall communicate the status thereby increasing the RC’s flexibility.

Implementation Plan

The Reliability Standards Development Procedures (Procedures) require that an implementation 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 DT is requesting an effective date as of the first day of the first month following WECC Board of Director approval.

Expansion of Scope

The DT is aware some of the proposed changes are outside of the scope of the current SAR and will seek permission to expand the scope of the SAR when the WECC Standards 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;
  • 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
Anticipated Actions / Date
Posting 1 Open / 4/7/2016
Posting 1 Closed / 5/23/2016
DT meets to answer Comments / 5/31/2016
WSC Meets (TBA) / 6/14/2016

Western Electricity Coordinating Council

WECC Criterion – INT-020-WECC-CRT-2

WECC Interchange Authority Backup (WIAB)

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

This section included 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 Director (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 Approval / Approved Definition / Term Origin
Interchange Authority Emergency / July 29, 2010 / A failure of the Interchange Authority software system that prevents the distribution of e-Tags to Reliability Coordinators, Balancing Authorities, Transmission Service Providers, Purchasing-Selling Entities, Load-Serving Entities and Interchange Authorities for assessment of confirmed interchange transactions, for distribution of confirmed interchanged transactions, or both.
/ INT-020-WECC-CRT-1.2
Interchange Authority Software Provider / July 29, 2010 / The Help Desk of the Software Vendor who is supporting the Interchange Authority Software System (WECC Interchange Tool). Contact information will be provided on the homepage of the WECC Interchange Tool. / INT-020-WECC-CRT-1.2

Western Electricity Coordinating Council

INT-020-WECC Criterion –-CRT-2 WECC-0054Page Interchange Authority Backup (WIAB) Page1 of 14

A.Introduction

  1. Title: WECC Interchange Authority Backup (WIAB)
  2. Number:INT-020-WECC-CRT-1.2
  3. Purpose:The purpose of this document is to establish a coordinated back-stop scheduling process that protects the reliability of the grid during an Interchange Authority Emergency.
  4. Applicability:
  5. Functional Entities:
  6. Reliability Coordinators
  7. Balancing Authorities
  8. Transmission Service Providers
  9. Purchasing-Selling Entities

4.1.5.Interchange Authority

  1. Effective Date: October 27, 2010

B.Requirements and Measures

WR1.Each Interchange Authority shall monitor the real-time operational status of the Interchange Authority software.

WM1.Each Interchange Authority shall provide evidence that it monitored the real-time operational status of the Interchange Authority software.

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

WM2WM1.Each Transmission Service Provider shall produce a record of all transactions on its paths for a specified audit hour plus the next four consecutive hours.

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

WM3WM2.Each Purchasing Selling Entity shall produce a record of all of its interchange schedules for a specified audit hour plus the next four consecutive hours.

WR4WR3.Each Balancing Authority shall maintain a duplicate copy of its aggregate Net Scheduled Interchange (NSI) as previously confirmed by the Interchange AuthorityWECC interchange toolfor the current hour plus the next four consecutive hours.

WM4WM3.Each Balancing Authority shall produce its retained duplicate copy of its aggregate Net Scheduled Interchange (NSI) as previously confirmed by the Interchange AuthorityWECC interchange toolfor a specified audit hour plus the next four consecutive hours.

WR5WR4.Each Balancing Authority shall store a duplicate copy of its aggregate NSI on a storage system independent from the Interchange Authority.WECC interchange tool.

WM5WM4.Each Balancing Authority shall produce evidence that storage of its aggregate NSI takes place on a storage system independent from the Interchange Authority.WECC interchange tool.

WR6WR5.Each Balancing Authority and Purchasing Selling Entity shall report suspected failure of the Interchange Authority WECC interchange tool to the software to the Interchange Authority Software Provider.provider.

WM6.WM5. Each Balancing Authority and Purchasing Selling Entity shall produce all reports, if any, submitted to thesoftware providerInterchange Authority Software Providerthat indicated suspected failure of the Interchange Authority softwareWECC interchange tool.

WR6.WR7.Each Interchange Authority shall report confirmed failure of the Interchange Authority software to the Reliability Coordinator.

WM7.Each Interchange Authority shall produce all reports, if any, submitted to the Reliability Coordinator that indicated confirmed failure of the Interchange Authority shall notify its Balancing Authorities whenever the interchange software fails and again when the interchange software. has been restored.

WR8.Each Reliability Coordinator shall declare the start of an Interchange Authority Emergency using the WECC Net messaging system or alternate method.

WM8WM6.Each Reliability Coordinator shall produce evidence that it used the WECC Net messaging system or alternate method to communicate the start of all Interchange Authority Emergencies.

notified its Balancing AuthoritiesWR9.During an IA Emergency,each time the interchange software failed, and again when the interchange software was restored.

The following WECC Requirements only apply during failure of the software system(s) designed to distribute WECC’s interchange information.

WR7.Each Balancing Authority shall operate to the most recent duplicate copy of its aggregate NSI as last confirmed by the Interchange AuthorityWECC interchange tool(net of all individual adjacent NSI’s) or as adjusted by changes described in below.).

WM9WM7.Each Balancing Authority shall produce evidence that it operated to the data contained in its most recent duplicate copy of its aggregate NSI as last confirmed by the Interchange AuthorityWECC interchange tool(net of all individual adjacent NSI’s) or as adjusted by changes allowed in this criterion for each specified period coveredby an Interchange Authority Emergency.during interchange software failure.

WR8.EachWR10.During an IA Emergency, each Balancing Authority shall exhaust all of its internal and dynamically scheduled or pseudo-tied external resources before requesting new interchange.

WM10WM8.Each Balancing Authority shall produce 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 by an Interchange Authority Emergency.during interchange software failure.

WR9.WR11.During an IA Emergency, eachEach Sink Balancing Authority shall implement new interchange transactions when necessary to maintain load-to-generation balance, reserve requirements, or to maintain reliability.

WM11WM9.Each Sink Balancing Authority shall produce evidence that it implemented new interchange transactions that were necessary to maintain load-to- generation balance, reserve requirements, or to maintain reliability, for each specified period covered by an Interchange Authority Emergency.during interchange software failure.

WR10.EachWR12.During an IA Emergency, 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.

WM12WM10.Each Sink Balancing Authority shall produce evidence that, the Sink Balancing Authority 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 by an Interchange Authority Emergency.during interchange software failure.

WR11.EachWR13.During an IA Emergency, each Sending Balancing Authority that is a party to the newly created interchange transaction shall verbally communicate and confirm with each Receiving Balancing Authority and Transmission Service Provider involved in the transaction created by the Sink Balancing Authority.

WM13WM11. Each Sending Balancing Authority that is a party to the newly created interchange transaction shall produce evidence that it communicated and confirmed the newly created interchange transaction with each Receiving Balancing Authority and Transmission Service Provider involved in the transaction created by the Sink Balancing Authority, for each specified period covered by an Interchange Authority Emergency.during interchange software failure.

WR12.EachWR14.During an IA Emergency, 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.

WM14WM12.Each Balancing Authority shall provide 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 specified period covered by an Interchange Authority Emergency.during interchange software failure.

WR13.WR15.During an IA Emergency, eachEach Balancing Authority and each Transmission Service Provider shall verbally communicate downward adjustments or curtailments to existing non-dynamic transactions with each Balancing Authority and each Transmission Service Provider that is a party to the transaction.

WM15WM13.Each Balancing Authority and each Transmission Service Provider shall provide evidence that downward adjustments or curtailments 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, for each specified period covered by an Interchange Authority Emergency.during an interchange software failure.

WR14.WR16.During an IA Emergency, eachEach Balancing Authority and each Transmission Service Provider shall complete the Transaction Data Template (Attachment A) for each new transaction.

WM16WM14.Each Balancing Authority and each Transmission Service Provider shall produce a completed Transaction Data Template (Attachment A) for each new transaction created during each specified period covered by an Interchange Authority Emergency.during an interchange software failure.

WR17.Each Interchange Authority shall report confirmedThe following WECC Requirements only apply after restoration of the Interchange Authority softwareto the Reliability Coordinator.

WM17.Each Interchange Authority shall produce its report of confirmed restoration of the Interchange Authority software to the Reliability Coordinator.

WR18.Each Reliability Coordinator shall declare the termination of an Interchange Authority Emergency using the WECC Net messaging system or alternate method(s) designed to distribute WECC’s interchange information.

WM18.Each Reliability Coordinator shall produce evidence that it used the WECC Net messaging system or alternate method to declare the termination of an Interchange Authority Emergency.

WR19WR15.Each Sink Balancing Authority shall submit or cause to have submitted an after-the-fact e-Tag, after termination of each Interchange Authority Emergencyinterchange software failureand before the end of the after-the-fact e-Tag submission deadline, for each transaction implemented during eachInterchange Authority Emergency.interchange software failure.

WM19WM15.Each Sink Balancing Authority shall produce evidence that it submitted an after-the-fact e-Tag after termination of eachInterchange Authority Emergencyinterchange software failureand prior to the end of the after-the-fact e-Tag submission deadline, for each transaction implemented during eachInterchange Authority Emergency.interchange software failure.

WR20WR16.Each Sink Balancing Authority shall update or cause to have updated its dynamic tags, after termination of the Interchange Authority Emergencyeach interchange software failureand before the end of the dynamic tag adjustment deadline, using the actual interchange values that occurred during the Interchange Authority Emergency.interchange software failure.

WM20WM16.Each Sink Balancing Authority shall provide evidence that it updated or caused to be updated its dynamic tags, after termination of theInterchange Authority Emergencyinterchange software failureand before the end of the dynamic tag adjustment deadline, using the actual interchange values that occurred during theInterchange Authority Emergency.interchange software failure.

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.

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 A

Transaction 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