html5-img
1 / 54

Bob Harshbarger Volunteer

Bob Harshbarger Volunteer. Industry Updates January 29-30, 2013 Sunny Salt Lake?. Traditional Moment for Raymond. TBD. Traditional Moment for Raymond. TBD. Traditional Moment for Raymond. Wholesale Gas Quadrant (WGQ) Retail Gas & Electric Quadrant Wholesale Electric Quadrant (WEQ)

ronli
Download Presentation

Bob Harshbarger Volunteer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Bob HarshbargerVolunteer Industry Updates January 29-30, 2013 Sunny Salt Lake?

  2. Traditional Moment for Raymond TBD

  3. Traditional Moment for Raymond TBD

  4. Traditional Moment for Raymond

  5. Wholesale Gas Quadrant (WGQ) Retail Gas & Electric Quadrant Wholesale Electric Quadrant (WEQ) Joint Electric Scheduling Subcommittee (JESS) OASIS Subcommittee (OS) Business Practices Subcommittee (BPS) NAESB Business Practice 003 Class North American Energy Standards Board (NAESB)

  6. e-Tag 1.8.1.1 Roll-out e-Tag 1.8.2 & Multiple Reliability Limit Profiles WEQ-004 Coordinate Interchange Business Practice Standards Electric Industry Registry NAESB WEQ JESS

  7. 1.8.1.1 incorporates WEQ-012 Public Key Infrastructure (PKI) requirements - certificate-based security August 8th 2013 1st interoperability test August 29th 2013 2nd interoperability test September 5th 2013 3rd interoperability test September 12th 2013 4th interoperability test October 1st 2013 1st cut-over attempt e-Tag 1.8.1.1 Testing and Roll-out

  8. October 4th 2013 1st vendor & select entities coordination call October 11th 2013 2nd vendor & select entities coordination call October 18th 2013 3rd vendor & select entities coordination call October 25th 2013 4th vendor & select entities coordination call e-Tag 1.8.1.1 Testing and Roll-out

  9. November 4th 2013 – 2:30 pm PPT “delay” message created for evening cut-over November 4th 2013 – 2:52 pm PPT Cal ISO resolves final issues November 4th 2013 – 3:05 pm PPT Cal ISO uncomfortable with moving ahead due to ISO’s tagging recovery process November 5th 2013 2nd cut-over attempt cancelled e-Tag 1.8.1.1 Testing and Roll-out

  10. November 5th 2013 Cal ISO declares ready November 5th 2013 vendor & select entities coordination call November 7th 2013 2nd cut-over attempt succeeds! e-Tag 1.8.1.1 Testing and Roll-out

  11. Interoperability testing is between vendors’ development systems. Roll-out is between to production systems.  Some vendors provide delivered systems Each of their clients have a variety of implementations – different operating systems, hardware, firewalls, support staff, procedures, etc. Took time for each client/vendor to work through these implementations. e-Tag 1.8.1.1 Testing and Roll-out

  12. Modifications for Network Integration Transmission Service on OASIS Many other stuff (next two slides) e-Tag 1.8.2 & Reliability Limits

  13. Modified 6.1.1 Transaction Types to include Recallable Clarified ramp duration validation in 6.1.4. Included 2 graphics. Modified 6.1.5 to allow multiple PSEs and a single Transmission Service Provider (stacked tags). Modified 1.4.7 to reference a single Transmission Service Provider. Clarified processing of after-the-fact adjustments for DYNAMIC and PSEUDOTIE e-Tags in multiple sections Modified 6.1.1 definition of PSEUDOTIE transaction type Created Appendix B – After-The-Fact Timing Considerations Removed references to 168 hours and one hour durations and replaced them with a reference to Appendix B. e-Tag 1.8.2 & Reliability Limits

  14. Created Appendix C – XML e-Tag examples Clarified ramp overlap and assorted related topics. Modified Section 6.1.5 for tagging of NITS Resources. Modified Section 4.6.1.2 to allow any Market Operator on the Physical Path to adjust the Market Level Profile. Deleted Interchange Transaction definition; added Tagged Transaction definition in Section 1.2. Added Section 1.7, Service Transfers Added Creating Purchasing Selling Entity (CPSE) definition e-Tag 1.8.2 & Reliability Limits

  15. Voted out of JESS on March 6, 2013 Posted for 30-day formal comment on March 7, 2013 Received 4 comments JESS met April 23, 2013, developed responses to comments JESS has, in its late comments to the WEQ EC, recommended the specification be remanded back to JESS for further development. e-Tag 1.8.2 & Reliability Limits

  16. The WEQ EC remanded back to JESS and asked that two issues be worked upon: Address standard request R13004 from BPA and CISO for consideration of expanded role of registered Market Operators in e-Tag Address the long-standing multiple control of a single reliability limit profile per tag issue e-Tag 1.8.2 & Reliability Limits

  17. Request R13004: BPA and the CA ISO identified in both e-Tag 1.8.1.1 and 1.8.2 and in NAESB WEQ-004 a lack of guidance for use of tagging fields in both the Market Segment and Physical Segment when entities sell to or buy from a Market Operator (i.e., ISOs and RTOs). JESS participants at the July meeting considered revising “allowed” entities in various roles within an e-Tag, but some pointed-out that approach would require significant work. JESS participants then suggested the registration of product codes in the EIR such as “Market”. e-Tag 1.8.2 & Reliability Limits

  18. BPA and CISO were asked to consider this option and they agreed JESS created a “no action” recommendation on R13004 (since no standard would be changing). The new EIR products can be requested via an EIR Enhancement Request form submitted to the NAESB office. e-Tag 1.8.2 & Reliability Limits

  19. Issue: a single reliability limit profile per tag but multiple entities can request an adjustment. ISAS leadership and representatives are seeking to resolve the long-standing issue. At the July 2013 JESS meeting reviewed five possible approaches. At the Aug 2013 JESS meeting settled on “option 5”, the most complicated but most effective approach. At the Oct 2013 JESS meeting reviewed specification modifications by Brian Lewis (OATI). e-Tag 1.8.2 & Reliability Limits

  20. In Dec 2013 JESS modified and posted 1.8.2 specification and schema for informal comments. Jan 10th call JESS reviewed informal comments. JESS voted for 30 day formal comments. Currently posted for formal comment due Feb 11th. Feb 12thcall the JESS will address any formal comments and submit “late” comments to WEQ Executive Committee for consideration. WEQ EC meets Feb 18, 2014. We expect approval Then JESS works on testing & roll-out. e-Tag 1.8.2 & Reliability Limits

  21. Recent modifications to support Order 764 approved and ratified Western Timing Table WEQ-017 default ramp durations Changes for NITS on OASIS considered Corresponding changes related to NERC INT Rewrite effort (Project 2008-12) And general clean-up WEQ-004 Coordinate Interchange Business Practice Standards

  22. Recently rolled-out: Moved WECC registry into EIR Stopped csv and mdb format publications Implemented automatic emergency publication WEQ Electric Industry Registry

  23. Current tasks: Working removing legacy items Document timeline for publication Considering three enhancement requests: Support registration of Pseudo-ties Provide notice of pending publication removal New energy product code WEQ Electric Industry Registry

  24. NAESB WEQ JESS

  25. Pre-emption/competition continued FERC Order 890 related Revisiting SAMTS Target for a recommendation in 2nd Q, 2014 The “Entergy ruling” re: firm redirects & conditionality They also have a dozen other “Not Started” items NAESB WEQ OASIS Subcommittee

  26. NAESB WEQ OS

  27. Once cuts are needed, who gets cut and in what order – based on transmission service priority Methods to include un-tagged flows Coordinating with the Association on IDC modifications Posted for informal comments until Jan 31st NAESB WEQ BPS - Parallel Flow Visualization

  28. Class held December 16-17, 2013 at NAESB offices in Houston Intended to high-light differences between version 2.1 and 3.0 in the 22 sets of business practice standards and glossary Approximately 20 attendees Wide variety in presenters Probably do it again NAESB WEQ Version 003 Standards

  29. MOD-A, Project 2012-05, ATC Standards, modification to MOD-001, 004, 008, 028, 029, 030 “Informal Development” first half of 2013 Standards drafting team formed in July Ballot and non-binding poll in August Comment period in October Another ballot in November Final ballot in December with 87.16% quorum, 86.40% approval Board of Trustees in February NERC Standards Activities – MOD A

  30. MOD-001-2 Rationale for R1: TFC and TTC are the starting points for the AFC and ATC values. AFC and ATC values influence Real‐time conditions and have the ability to impact Real‐time operations. A TOP shall clearly document its methods of determining TFC and TTC so that any TOP or Transmission Service Provider that uses the information can clearly understand how the values are determined. The TFC and TTC values shall account for any reliability‐related constraints that limit those values as well as system conditions forecasted for the time period for which those values are determined. The TFC and TTC values shall also incorporate constraints on external systems when appropriate, in addition to constraints on the TOP’s own system. Requirement R1 sets requirements for the determination of TFC or TTC, but does not establish if a TOP must determine TFC or TTC. NERC Standards Activities – MOD A

  31. MOD-001-2 Rationale for R2: A TSP must clearly document its methods of determining AFC and ATC so that TOPs or other entities can clearly understand how the values are determined. The AFC and ATC values shall account for system conditions at the time those values would be used. Each TSP that uses the Flowgate Methodology shall also use the AFC value determined by the TSP responsible for an external system constraint where appropriate. Requirement R2 sets requirements for the determination of AFC or ATC, but does not establish if a TSP must determine AFC or ATC. NERC Standards Activities – MOD A

  32. MOD-001-2 Rationale for R3: Capacity Benefit Margin (CBM) is one of the values that may be used in determining the AFC or ATC value. CBM is the amount of firm transmission transfer capability preserved by the transmission provider for LSEs, whose Loads are located on that TSP’s system, to enable access by the LSEs to generation from interconnected systems to meet resource reliability requirements. A clear explanation of how the CBM value is developed is an important aspect of the TSP’s ability to communicate to other entities how that AFC or ATC value was determined. Therefore, anytime CBM is used (non‐zero) a CBMID is required to communicate the method of determining CBM. NERC Standards Activities – MOD A

  33. MOD-001-2 Rationale for R4: Transmission Reliability Margin (TRM) is one of the values that may be used in determining the AFC or ATC value. TRM accounts for the inherent uncertainty in system conditions and the need for operating flexibility to ensure reliable system operation as system conditions change. An explanation by the TOP of how the TRM value is developed for use in the TSP’s determination of AFC and ATC is an important aspect of the TSP’s ability to communicate to other entities how that AFC or ATC value was determined. Therefore, anytime a TOP provides a non‐zero TRM to a TSP, a Transmission Reliability Margin Implementation Document (TRMID) is required to communicate the method of determining TRM. NERC Standards Activities – MOD A

  34. MOD-001-2 Rationale for R5: Clear communication of the methods of determining AFC, ATC, CBM, TFC, TRM, and TTC are necessary to the reliable operation of the Bulk‐Power System. A TOP and TSP are obligated to make available their methodologies for determining AFC, ATC, CBM, TFC, TRM, and TTC to those with a reliability need. The TOP and TSP are further obligated to respond to any requests for clarification on those methodologies, provided that responding to such requests would not be contrary to the registered entities confidentiality, regulatory, or security concerns. The purpose of this requirement is not to monitor every communication that occurs regarding these values, but to ensure that those with reliability need have access to the information. Therefore, the requirement is very specific on when it is invoked so that it does not create an administrative burden on regular communications between registered entities. NERC Standards Activities – MOD A

  35. MOD-001-2 Rationale for R6: This requirement provides a mechanism for each TOP or TSP to access the best available data for use in its calculation of AFC, ATC, CBM, TFC, TRM, and TTC values. Requirement R6 requires that a TOP or TSP share their data, with the caveat that the TOP or TSP is not required to modify that data from the form that they use or maintain it in. For data requests that involve providing data on a regular interval, the TOP or TSP is not obligated to provide the data more frequently than either (1) once an hour, or (2) as often as they update the data. The data provider is also not obligated to provide data that would violate any of its confidentiality, regulatory, or security obligations. The purpose of this requirement is not to monitor every data exchange that occurs regarding these values, but to ensure that those with reliability need have access to the information. Therefore, the requirement is very specific on when it is invoked so that it does not create an administrative burden on regular communications between registered entities. NERC Standards Activities – MOD A

  36. Coordinate Interchange Standards Draft Team, Project 2008-12, INT rewrite Started in 2008 and put on the shelf end of 2009 Reactivated in March 2013 Posted for comment July 2013 Ballot & non-binding polls November 2013 Additional ballots non-binding polls January 2014 Ballots end Jan 22nd & 27th Board of Trustees in February 2014 NERC Standards Activities – INT Rewrite

  37. New standards INT-004-3 Dynamic Transfers INT-006-4 Evaluation of Interchange Transactions INT-009-2 Implementation of Interchange INT-010-2 Interchange Initiation and Modification for Reliability INT-011-1 Intra-BA Transaction Identification NERC Standards Activities – INT Rewrite

  38. INT-004-3 – Rationale for R1 This Requirement is intended to ensure that an RFI is submitted for a Dynamic Schedule or Pseudo-Tie. If a forecast is available, it is expected that the forecast will be used to indicate the energy profile on the RFI. If no forecast is available, the energy profile cannot exceed the maximum expected transaction MW amount. R1 allows alternative means for Pseudo-Tie information into congestion management. NERC Standards Activities – INT Rewrite

  39. INT-004-3 – Rationale for R2 This requirement does not preclude tags from being updated at any time. The requirement specifies conditions under which the tag must be updated. R2 is about keeping the tagged values up-to-date. NERC Standards Activities – INT Rewrite

  40. INT-004-3 – Rationale for R3 This Requirement is intended to ensure that a Pseudo-Tie is properly established prior to its implementation. Transparency of all Pseudo-Ties ensures proper modeling by all impacted entities. This requirement will become effective when the NAESB Electric Industry Registry (EIR) accepts Pseudo-Tie registrations. Requirements for Pseudo-Tie registration will be defined in NAESB business practices which are developed through open industry practices. All existing Pseudo-Ties will need to be registered and verified. This will be addressed in the Project 2008-12 implementation plan. NERC Standards Activities – INT Rewrite

  41. INT-006-4 – Rationale for R1 Balancing Authorities must take action on a received Arranged Interchange within a certain time frame. Requirement R1, Parts 1.1 and 1.2 provide reliability-related reasons that a Balancing Authority must deny an Arranged Interchange, but Balancing Authorities may deny for other reasons. If the conditions described in Requirement R1, Parts 1.1 or 1.2 are recognized after approval is granted, the Balancing Authority may curtail the Confirmed Interchange prior to implementation. NERC Standards Activities – INT Rewrite

  42. INT-006-4 – Rationale for R2 TSPs must take action on a received Arranged Interchange within a certain time frame. Requirement R2, Part 2.1 provides reliability-related reasons that a TSP must deny an Arranged Interchange, but TSPs may deny for other reasons. If the conditions described in Requirement R1, Part 2.1 are recognized after approval is granted, the TSP may curtail the Confirmed Interchange prior to implementation. NERC Standards Activities – INT Rewrite

  43. INT-006-4 – R3 Paraphrased The Source and Sink BAs shall approve or deny a an adjustment to the reliability limit within a certain time frame. If a BA denies a reliability adjustment, the BA must communicate the denial to their RC within 10 minutes. NERC Standards Activities – INT Rewrite

  44. INT-006-4 – R4 Paraphrased The Sink BA shall confirm that none of the following conditions exist prior to transitioning an Arranged Interchange to Confirmed Interchange: For curtailment request, neither Source nor Sink BA has denied the request or failed to respond. For any request, none of the BAs or TSPs have failed to communicate their approval. For any request, no entity has communicated a denial. NERC Standards Activities – INT Rewrite

  45. INT-006-4 – R5 Paraphrased For each Arranged Interchange that is transitioned to Confirmed Interchange, the Sink BA shall notify the following entities of the on-time Confirmed Interchange such that the notification is delivered in time to be incorporated into scheduling systems prior to ramp start as specified in the timing tables: BAs TSPs PSEs NERC Standards Activities – INT Rewrite

  46. INT-009-2 – R1 Paraphrased Each BA shall agree with each of its Adjacent BAs that its Composite Confirmed Interchange with that Adjacent BA, at mutually agreed upon time intervals, excluding Dynamic Schedules and Pseudo-Ties and including any Interchange per INT-010-2 not yet captured in the Composite Confirmed Interchange, is: 1.1. Identical in magnitude to that of the Adjacent BA, and 1.2. Opposite in sign or direction to that of the Adjacent BA. NERC Standards Activities – INT Rewrite

  47. INT-009-2 – Paraphrase & Rationale for R2 Attaining and Native BAs shall use a dynamic value emanating from an agreed upon common source to account for the Pseudo-Tie in the Net Interchange Actual (NIA) term of their respective control ACE (or alternate control process). While R12.3 of BAL-005-2b addresses common metering for Dynamic Schedules and Pseudo-Ties, it does not address their implementation into ACE. And R2 is parallel to R10 of BAL-005-2b which only addresses Dynamic Schedules. R2 helps fill the gap in the BAL standards for Pseudo-Ties. NERC Standards Activities – INT Rewrite

  48. INT-009-2 – R3 Paraphrased Each BA in whose area the high-voltage DC tie is controlled shall coordinate the Confirmed Interchange prior to its implementation with the transmission operator of the high-voltage DC tie. During R3 development, it was pointed-out that many times the DC operator is probably the BA operator. NERC Standards Activities – INT Rewrite

  49. INT-010-2 In general, INT-010 deals with instances where Interchange is initiated/changed without a tag. If the Interchange will persist more than 60 minutes, then a tag needs to issued. NERC Standards Activities – INT Rewrite

  50. INT-010-2 – R1 Paraphrase For certain events where an energy sharing agreement is used to exchange energy, and it exceeds 60 minutes, a RFI needs to be issued with a start time less than 60 minutes from the event. An existing requirement with a slight terminology change and additional explanation on the sharing agreement meaning. NERC Standards Activities – INT Rewrite

More Related