Comments Received and Peak Response. General Comments

Transcription

1 Response to Comments IRO Data Request and Specifications for Data Provision Version 12 Document February 21, 2017 Peak Reliability (Peak) would like to thank those who responded to the request for comments on the Peak Reliability IRO Data Request and Specifications for Data Provision (Data Request) document. Comments have been sorted by the section of the document to which they pertain. Specific responses to a single comment are provided directly below the comment. Comments Received and Peak Response General Comments Entity Peak Comment/Response understands that it is Peak Reliability s intention to retain the same requirement numbering from one version of the Data Specification to the next. supports this direction and would like to underscore how important this is to entities having to comply with the data specification. When the data requirements are retired, we recommend a note be used to indicate the requirement has been retired as opposed to re-assigning the number to a new/different requirement. In light of the number of items in the specification, renumbering introduces a heightened level of administration on the part of the entities to monitor and track their provision of data in a consistent manner. Peak appreciates the comment from and recognizes this is an area deserving of further discussion. As such, this will be a topic Peak will collaboratively address with the IRO-010 Stakeholder team. (Peak the following comment from is in reference to the ICCP Data Format bullet 3 in the Applicable Entity Obligations section on page 2 which states, If real-time ICCP data transfer is unavailable for any reason, the responsible entity will provide critical real-time system data via phone to the RC real-time desk. ) supports Peak Reliability s need for critical real-time data. In the event there is a loss of ICCP data transfer, what constitutes critical real-time system data? Logistically, a phone call to report data points by exception is possible; e.g. forced outages of elements; however, reporting real-time measurements would not. Would Peak provide additional clarification as to what is meant by critical real-time system data to ensure we know what to report and when? Would RMT be an acceptable alternative to phone? PEAK RELIABILITY CORPORATE OFFICE 7600 NE 41 st STREET SUITE 150 VANCOUVER WASHINGTON HAHNS PEAK DRIVE SUITE 120 LOVELAND COLORADO

2 Peak Critical real-time system data is the data required by the Reliability Coordinator necessary to prevent instability, uncontrolled separation, or Cascading outages that adversely impact reliability. Phone is the method requested due to the criticality of the situation/data. supports Peak Reliability s need for data needed to ensure reliability. That said, in accordance with the ongoing development of NERC Standards TOP-001-4, R10 and IRO-002-5, R5, would prefer to see Note 1, point 2 read as follows: Measurement data for non-bes Facilities/equipment that impact the BES, including but not limited to parallel sub-100 kv systems, as determined by the TOP and by Peak as being necessary to support the accuracy of Real-time Assessments or to determine SOL exceedance on BES Facilities. As currently provides Peak Reliability with its entire 69 kv model, Peak Reliability has this information available. That said, s 69 kv system may not be modeled in its entirety in Peak s model. As a result, when it comes to knowing (or identifying) when a non-bes element has an impact on the BES system in s Transmission Operator Area, is in a better position to identify this using its model and would prefer the decision to request new non-bes data points be made collaboratively between the TOP and Peak. Similar comments for Note 8. Reference Excerpts: TOP-001-4, R10. Each Transmission Operator shall perform the following for determining System Operating Limit (SOL) exceedances within its Transmission Operator Area: Monitor non-bes facilities within its Transmission Operator Area identified as necessary by the Transmission Operator; Obtain and utilize status, voltages, and flow data for non-bes facilities outside its Transmission Operator Area identified as necessary by the Transmission Operator. TOP-001-4, Rationale for Requirement R10: The non-bes facilities that the TOP is required to monitor are only those that are necessary for the TOP to determine SOL exceedances within its Transmission Operator Area. Analysis which may be specified in the RC's outage coordination process that leads the TOP to identify a non-bes facility that should be temporarily monitored for determining SOL exceedances. February 21, 2016 Page 2

3 Peak Peak IRO-002-5, R5. Each Reliability Coordinator shall monitor Facilities, the status of Remedial Action Schemes, and non-bes facilities identified as necessary by the Reliability Coordinator, within its Reliability Coordinator Area and neighboring Reliability Coordinator Areas to identify any System Operating Limit exceedances and to determine any Interconnection Reliability Operating Limit exceedances within its Reliability Coordinator Area. Peak will continue to collaborate with entities but feels that the language as written provides the flexibility required for either entity to receive the data required to perform accurate Real-time Assessments. Peak reviews its Data Request whenever new or revised NERC Reliability Standards are approved and will continue to do so in the future. (1.5, 5.5, 5.7, and 5.9) recommends that Peak Reliability consider a return to the SOL language as opposed to Total Transfer Capability (TTC) as the more accurate means of ensuring system reliability. recognizes this change may also require a change to Peak Reliability s underlying SOL Methodology for the Operations Horizon document. Even the SOL Methodology for the Operations Horizon document seems to recognize this as supported by the following statements: Page 12: While Path TTC respects SOLs, Path TTC is not an SOL. Page 11: While it is expected that TTC respect pre- and post- Contingency reliability limitations associated with Facility Ratings, System Voltage Limits and stability limitations, the determination and communication of TTC is outside the scope of Peak s SOL Methodology. The data specification requires TOPs to provide TTC to Peak. In essence, today s Path SOL are being recharacterized as being path TTCs as of April 1, This TTC data will be used to provide situational awareness for Peak engineers and operators. It is envisioned that TTC could provide RC System Operators additional awareness of when heavy Path flows might be the cause of an SOL exceedance. Peak will not use TTC as a means to ensure system reliability, but rather as a means to provide additional information to RC System Operators to supplement their overall objective of achieving reliable pre- and post-contingency operations. Section 1 Real-Time Network Measurement Data NWMT For request #1.5, is Peak RC asking for the actual real power flow on WECC Transfer Paths, the Scheduled MW on the WECC Transfer Paths, and the Total Transfer Capability (TTC) for the WECC Transfer Paths? If the TTC is required in addition to the Scheduled MW can you explain how the TTC value will be used by Peak Reliability? Peak Please review Section J in the SOL Methodology for the Operations Horizon Version 8.0 document. February 21, 2016 Page 3

4 Section 2 Real-Time Balancing Authority Data YCWA Since 2.11 applies to BA or GOP, would it be fair to assume that Peak RC is or will be getting this data from our BA (CAISO) as it has all our information since 5/1/16? Peak For flexibility purposes, there is sufficient reason for this data to be provided by either the BA or GOP. The BA and GOP are expected to coordinate who will provide this requested data to Peak. Peak is currently reviewing this stance with the IRO-010 Stakeholder Team. As such, there may be a change in direction documented in future revisions. spower Can you confirm the definition of Status when mentioned in 2.21 Change in Status? Peak A status change would be equipment being unavailable, available in reduced capacity from normal, or a controlling method change. spower Does the status change only apply to the AVR (as implemented in software and hardware), or are there any circumstances where static capacitive/reactive resource status changes, or dynamic reactive power capability that support AVR should be included? Peak Varying degrees of the scenario you re describing are covered by Peak s data request, Outage Coordination process, and the response provided above. spower When the change takes effect on April 1, 2017, I assume that the intent is for all GOP reporting of AVR status changes are to be made exclusively to the BA, with the BA s defining how they want to receive that information form the GOPs? Peak Effective April 1, 2017, AVR status changes are only being requested by Peak from the BAs. Section 3 Forecast Data NWMT For request #3.2, is Peak RC requesting the hourly contingency reserve forecast for the BA area, the RSG Contingency Reserve Obligation (CRO), the Total Spinning CRO, or all three data points? Peak Peak is requesting the Total CRO Spinning and Total CRO required. If a BA is not a part of an RSG then it would simply be the BA CRO. If the BA is part of an RSG, it would then be the BA RSG CRO obligation. Section 4 Documentation and Procedures No specific comments related to this section. February 21, 2016 Page 4

5 Section 5 Scheduled and Unscheduled Outage Information (5.5) recommends that Peak Reliability consider deleting this requirement from its data specification as an entity would never take a planned outage of its AVR/PSS equipment and run its unit; i.e. there would be a planned outage of the unit as well. Peak Peak believes the data request as written allows for flexibility in the event a planned outage is taken and the unit remains in service for some reason. ( ) Note that Req.#s request information regarding any telemetering and control equipment, defined in the footnote 3 as: Equipment in this category contains, but is not limited to SCADA, RTU, communications channels and ICCP. believes the existing language, requiring reporting for any telemetering and control equipment, is overly broad as it necessitates informing Peak of single RTU unit outages. This requirement stems from NERC Standard TOP-001-3, R9 (effective: 4/1/2017) which requires RC notification for telemetering and control equipment outages. The standards development documentation indicates the intent of R9 is to notify the RC and neighboring entities of losses that have a material impact on situational awareness: e.g. loss of RTCA or AGC. As the loss of a single RTU is typically immaterial, would interpret the standard (at its lowest level) as requiring the reporting of unplanned loss of relay communications when we are down to one string in service with no redundancy. Is this acceptable? requests Peak provide additional clarification. Reference Excerpts: TOP-001-3, R9. Each Balancing Authority and Transmission Operator shall notify its Reliability Coordinator and known impacted interconnected entities of all planned outages, and unplanned outages of 30 minutes or more, for telemetering and control equipment, monitoring and assessment capabilities, and associated communication channels between the affected entities. Rationale for TOP-001-3, R9 from Final Draft: Additional terms added in response to SW Outage Report recommendation 15. Peak Recommendation #15 from SW Outage Report: TOPs should ensure procedures and training are in place to notify WECC RC and neighboring TOPs and BAs promptly after losing RTCA capabilities. Requests 5.10 and 5.11 provide Peak data used for Real-time Assessments and Operational Planning Analyses. Reference the February 21, 2016 Page 5

6 Telemetering and Control definition in Section 5 of Data Request v12.1 for additional clarity and guidance. Anonymous Per TOP-001-3, R9 (effective April 1, 2017), each BA and TOP shall notify its RC and known interconnected entities of all planned outages, and unplanned outages of 30 minutes or more, for telemetering and control equipment, monitoring and assessment capabilities, and associated communication channels between the affected entities. We believe this standard compels the BA/TOP to notify the RC and others of all planned outages regardless of duration and of unplanned outages if the outage duration is equal to or greater than 30 minutes. Peak Requests 5.10 and 5.11 provide Peak data used for Real-time Assessments and Operational Planning Analyses. Requests 5.10 and 5.11 were revised to provide additional clarity. Balancing Authority and Transmission Operator guidance related to TOP R9 was provided via footnote. TPWR There are two footnote 3 s in Section 5. Peak The footnotes weren t duplicates but format revisions were made to address potential confusion. POPUD Item 5.6 states, Any Automatic Voltage Regulator (AVR) or Power System Stabilizer (PSS) outage (other than planned outages, and 30 min or more in duration) on a BES facility. Which on the surface sounds pretty self-explanatory; however, I am confused about the parenthetical clause. Does this mean that the outage must meet both criterions in the parentheses to be applicable to this item? For example, an outage of AVR must be unplanned and 30 minutes or more in duration for this item? Or an outage of AVR must be other than planned (unplanned) and then 30 minutes or more (<30 min.) to be applicable to this item? There are other items that have this same language (5.3, 5.8, 5.11) and I want to be clear when training on the requirements set forth. Peak The first interpretation is correct. An outage of an AVR must be unplanned AND be 30 minutes or more in duration. To note, requests 5.10 and 5.11 have been revised. Section 6 Power System Modeling Information ( ) requests clarification as to the reliability need for this information. How will this be used for reliability purposes; e.g. geomagnetic disturbances? Who has access to this information? Peak Peak utilizes the requested information in our visualization platform. This data contributes to enhanced situational awareness during geomagnetic disturbance, fire, tsunami and weather events. Section 7 Other Operational Information No specific comments received for this section. February 21, 2016 Page 6