2018 Annual Plan Items

1. 2018 Annual Plan Items Assigned to the WEQ OASIS and BPS Subcommittees

2. History of Major Work Efforts • BPS • Parallel Flow Visualization • ATC calculations • OASIS • NITS on OASIS • Service Across Multiple Transmission Systems • Preemption and Competition • Long-Term Competition • PTP Rollover Rights

3. 2018 API Summary

4. 2018 Annual Plan Item 2ai1 Posting of additional curtailment information on OASIS

5. API 2ai1 • FERC initiated in Order 890 • Assigned jointly to OASIS and BPS • BPS worked initially to identify scope and data availability • OASIS subcommittee work was delayed while working through other critical Business Practice Standards development. • BPS and OASIS have refined the scope in light of OASIS templates that exist and have begun work to identify additional template structures and Business Practice Standards

6. API 2ai1 FERC Initiated in Order 890 P. 1627 We agree with suggestions for the posting of additional curtailment information on OASIS and, therefore, require transmission providers, working through NAESB, to develop a detailed template for the posting of additional information on OASIS regarding firm transmission curtailments. Transmission providers need not implement this new OASIS functionality and any related business practices until NAESB develops appropriate standards. These postings must include all circumstances and events contributing to the need for a firm service curtailment, specific services and customers curtailed (including the transmission provider’s own retail loads), and the duration of the curtailment.

7. API 2ai1 P. 1628 …our requirement that OASIS templates for curtailment information be developed that will report occurrences of all levels of TLRs. This will enable the Commission and customers to monitor TLR patterns and frequency...

8. API 2ai1 P 1629 …Transmission providers should continue to use the OASIS Schedule Details template to post information on the scheduled uses of the transmission system and any curtailments and interruption thereof…

9. API 2ai1Current Work Effort • Focus on interconnection-wide curtailments • List of data available through TLR information in Eastern Interconnection • List of data available through WECC information in the Western Interconnection • Progress underway in developing NAESB Business Practice Standards

10. API 2ai1Current Work Effort (continued) • Data must be provided by outside agencies (EIDSN & WECC) • Questions about whether data will be provided by agencies for public dissemination • Data elements have been identified for Eastern Interconnection • Expect that similar information is available for Western Interconnection

11. API 2ai1Current Work Effort (continued) • Informal discussions by OS/BPS members with IDC Working Group and WECC to identify options • Verify that data exists. (Are we asking for something that can’t be provided?) • Can desired data be delivered? If so, how can it be delivered? • Will organizations provide the data? (confidentiality question) • How soon could the other organizations provide the information after FERC orders it? • Outside organizations provide info in an appropriate structure?

12. API 2ai1Next Steps • Finalize list of information to be posted • There may be differences between Eastern and Western Interconnections • Determine mechanism for making data available for posting • Identify reasonable time to implement • Finalize OASIS Business Practice Standards (WEQ-000, 001, 002, 003, 008, and 013) • Prepare recommendation

13. 2018 Annual Plan Item 3a Requirements for OASIS to Use Data in the Electric Industry Registry

14. API 3a Requested in 2012 -- R12001 (link) Transmission providers are required to register certain information in the Electric Industry Registry. However, there are no requirements for OASIS to use or obtain that same data from EIR. For consistency and transparency, create requirements for OASIS to obtain and use information from the EIR. Use of Proposed Standard or Enhancement:  Transmission providers’ OASIS would download EIR information for use in template and GUIs. Consistent use of point names and other information will be ensured between OASIS and e-Tagging.. Benefits: Consistent use of point names and other information will be ensured between OASIS and e-Tagging. Transparency and consistency between EIR and OASIS and e-Tagging.

15. API 3a • Normal need, high effort • OASIS and webRegistry do not currently “talk” to each other • Initial Focus was on Tagging components (e.g., POR, POD, Source, Sink) • Additional items for consideration: • Entity codes • Pseudo-Tie information • Other WEQ-003 Data Elements that are permitted to be “registered” • Need to work though differences between tagging and reservation definitions (e.g., Source) • Need to work through differences in data element formats (e.g. # of characters) • webRegistry’s data structure in some instances isn’t compatible with OASIS requirements • Some items listed as “Registered” in OASIS are not being captured in webRegistry

16. 2018 Annual Plan Item 3b Define Specific Lists for Query/Response Templates in OASIS

17. API 3b • New in 2018 -- assigned to the OASIS subcommittee • Low need, low effort, low hanging fruit • Specific lists which needed expanded query options were identified and Business Practice Standards drafted • Recommendation submitted for EC consideration in August meeting • Due 4thqtr 2018 – completed in 2ndQtr

18. 2018 Annual Plan Item 3c Dynamic Notification for the Rollover Rights Renewal Deadline (PTP)

19. API 3c • New in 2018 -- assigned to the OASIS subcommittee • Moderate need, normal effort, low hanging fruit • Much interest in the subcommittee in this API • Simple approach considered by the subcommittee but additional complexity is desired

20. API 3c • Working though documentation of desired scope • How to communicate • Frequency of communications • Who to receive communications • What information to communicate • Required or optional communication by Transmission Provider • Opt-in or opt-out by customers with rollover rights • Will develop with an eye toward being able to establish similar functionality for NITS in conjunction with API 3d • Due 3rdqtr 2018 --- propose to move to 4thqtr 2018

21. 2018 Annual Plan Item 3d Review and Make Needed Modifications to NITS on OASIS

22. API 3d • New in 2018 -- assigned to the OASIS subcommittee • High need, high effort • Due 2019 • 3 categories of effort • Minor Corrections – typos, etc • Minor OASIS Issues (Technical modifications only) • Eight (8) issues identified in first subcommittee discussion • Major OASIS Issues (Business Practice Standards & Technical modifications) • Seventeen (17) issues identified in first subcommittee discussion

23. 2018 Annual Plan Item 3e OASIS Practices to Ensure Reservation Capacity of Untagged Pseudo-Ties is Preserved for That Purpose

24. API 3e • OASIS document the acquisition and e-tagging documents the use of Transmission Service. • OASIS documents the following: • Process of requesting and granting of reservations • Allocation/modification of reservation’s capacity • PTP: RESALE, MATCHING, DEFERRAL, REDIRECT, RELINQUISH, FULL_TRANSFER, PART_TRANSFER, RECALL, CONSOLIDATION • NITS DNR: temporary or indefinite termination

25. API 3e Validation of Requests to Modify Firm Reservations Prior to accepting a request to modify PTP reservation the Transmission Provider checks to see that the reservation’s transmission capacity is not already used (tagged) and is not otherwise modified (encumbered). Prior to accepting a request to terminate a DNR the Transmission Provider checks to see that the transmission capacity already tagged (encumbered).

26. API 3e If these checks aren’t performed and the modification is granted, then the Transmission Customer would be able to use the reservation’s capacity more than once or use capacity that should no longer be reserved. This could lead to unreserved use penalties. Here are 3 examples.

27. API 3e Example 1: Customer A has a 100 MW reservation. Customer A redirects original 100 MW to path AB Customer A redirects original 100 MW to path CD Customer tags 100 MW on path AB Customer tags 100 MW on path CD Validity check should have prevented the redirect to path CD because the reservation’s capacity had already been redirected to path AB

28. API 3e Example 2: Customer A has a 100 MW reservation. Customer tags original 100 MW Customer A redirects original 100 MW to path CD Customer tags 100 MW on path CD Validity check should have prevented the redirect to path CD because the reservation’s capacity had already been used (tagged) on the original path

29. API 3e Example 3: Customer A has a 100 MW reservation. Customer uses original 100 MW capacity to facilitate an untagged Pseudo-Tie Customer A redirects original 100 MW to path CD Customer tags 100 MW on path CD Validity check should have prevented the redirect to path CD because the reservation’s capacity had already been committed for use on the original path. However, there is nothing on OASIS or the e-tagging system to document the use of the reservation for the untagged Pseudo-Tie.

30. API 3e Primary Focus of API 3e Transmission Providers and Transmission Customers need to be able to recognize when a firm reservation’s capacity is dedicated for use in a purpose that is not yet documented on OASIS or e-tagging, like the untagged Pseudo-Tie. • Perform validation checks to address potential unreserved use situations • Prevent the Transmission Provider from releasing the “unscheduled” reservation capacity as non-firm ATC or AFC.

31. API 3e Key Attributes Business Practice Standards Under Development for API 3e A new itemcalled a Managed Encumbrance (ME) is established to document dedicated use of reserved capacity ME is not a reservation but instead is a declaration of a set-aside of reservation capacity for a given purpose The Transmission Customer may adjust the capacity set-aside The Transmission Provider will treat the ME the same as if it were tagged (no release of capacity to non-firm ATC/AFC)

32. API 3e New Defined Term Managed Encumbrance An allocation of unconditional (not subject to Preemption) Firm Transmission Services that is set-aside in part or full and is treated in a manner similar to firm scheduled use of reserved capacity.

33. API 3e • Managed Encumbrance will be used to document encumbrances that are not otherwise recognized by OASIS. • Broadly defined and implemented so that it can be used for encumbrances in addition to an untagged Pseudo-Tie that may be identified in the future • Only unconditional Firm PTP and DNR reservations may be encumbered by an ME. • ME may encumber capacity from multiple reservations (similar to a stacked tag) • A reservation may be partially encumbered by multiple MEs • Future capacity encumbered on reservations by the ME may be adjusted at any time by the Transmission Customer (examples to be provided such as when a generator is to be out of service for a period of time) • Special requirements added when it is for an untagged Pseudo-Tie

34. API 3e • Special requirements added when the Managed Encumbrance (ME) is for an untagged Pseudo-Tie • ME must show the Pseudo-Tie ID that was assigned to it when it was registered in the EIR (webRegistry) • Pseudo-Tie ID may only be shown in one ME

35. API 3e Example of how it would work for an untagged Pseudo-Tie • The Transmission Customer makes arrangements with Transmission Providers for an untagged Pseudo-Tie and documents the arrangement in webRegistry • webRegistry assigns a unique ID to the Pseudo-Tie • The Transmission Customer documents the encumbered reservation capacity of the untagged Pseudo-Tie on OASIS (e.g., if a 5 year arrangement, document the reservations being set aside for the untagged Pseudo-Tie for the 5 year period)

36. API 3e Example of how it would work for an untagged Pseudo-Tie (continued) • As conditions change the Transmission Customer may request adjustment any future increment of the ME • Could release or reduce day-ahead for single day if full capacity is not going to be used • Could release or reduce for extended period if generator is to be out of service • Could reinstate from a previously encumbered reservation if generator is returned to service earlier than anticipated. • Could add capacity if the Pseudo-Tie parameters change (e.g. Pseudo-Tied load increases faster than initially anticipated).

37. API 3e Example of how it would work for an untagged Pseudo-Tie (continued) • The Transmission Provider must approve or deny each ME request (new and adjustments) • Check for a valid Pseudo-Tie ID • Check that Uncommitted Capacity available from each PTP reservation • Check that the reservation to be encumbered is on the same path as the ME • If denied, give a reason for the denial • If approved, adjust the Uncommitted Capacity for the PTP reservations that were encumbered.

38. API 3e WEQ-001 uses several terms to refer to these dedicated uses. Redirect standards refer to the defined term Uncommitted Capacity Resale standards refer to “reductions to the capacity available for scheduling” Partial Transfer standards refers to “reductions to the capacity available for scheduling” Full Transfer standards refer to “encumbrances” CCO standards refer to “encumbrances” Consolidation standards refer to “Uncommitted Capacity” Termination of a DNR refers to “unscheduled capacity”

39. API 3e Modified Defined Term Uncommitted Capacity The granted capacity of a PTP reservation at the time of Transmission Customer confirmation (CAPACITY_GRANTED) less all confirmed reassignments (e.g., Resales), confirmed Redirects on a firm basis, confirmed Redirects on a non-firm basis, displacements, approved schedules, approved MEs and confirmed Consolidations.

40. 2018 Annual Plan Item 3f Evaluate Need for Standards for Coordination of Partial Path Reservations

41. API 3f • New in 2018 -- assigned to the OASIS subcommittee • Low need, normal effort • TBD completion • A high level presentation of the concept has been made to subcommittee • Nice to have – lowest priority

42. 2018 API Summary

43. API 3f Questions and/or guidance from the Executive Committee?