IRO-014-3 – Coordination Among Reliability Coordinators
Purpose
To ensure that each Reliability Coordinator’s operations are coordinated such that they will not adversely impact other Reliability Coordinator Areas and to preserve the reliability benefits of interconnected operations.
Applicability
Effective Date
See the Implementation Plan.
Background
See Project 2014-03 project page.
Requirements and Measures
R1. Each Reliability Coordinator shall have and implement Operating Procedures, Operating Processes, or Operating Plans, for activities that require notification orcoordination of actions that may impact adjacent Reliability Coordinator Areas, tosupport Interconnection reliability. These Operating Procedures, Operating Processes, or Operating Plans shall include, but are not limited to, the following: [Violation Risk Factor: Medium] [Time Horizon: Operations Planning, Same-Day Operations]
1.1. Criteria and processes for notifications.
1.2. Energy and capacity shortages.
1.3. Control of voltage, including the coordination of reactive resources.
1.4. Exchange of information including planned and unplanned outage information to support its Operational Planning Analyses and Real-time Assessments.
1.5. Provisions for periodic communications to support reliable operations.
M1. Each Reliability Coordinator shall have available the latest approved documented version of its Operating Procedures, Operating Processes, and Operating Plans that require notifications, or the coordination of actions among impacted Reliability Coordinators for conditions or activities that may impact adjacent Reliability Coordinator Areas. This documentation shall include dated, current in force documentation with the specified elements, and notes from periodic communications.
R2. Each Reliability Coordinator shall maintain its Operating Procedures, Operating Processes, or Operating Plans identified in Requirement R1 as follows: [Violation Risk Factor: Low] [Time Horizon: Operations Planning, Same-Day Operations]
2.1. Review and update annually with no more than 15 months between reviews.
2.2. Obtain written agreement from all of the Reliability Coordinators required to take the indicated action(s) for each update.
2.3. Distribute to all Reliability Coordinators that are required to take the indicated action(s) within 30 days of an update.
M2. Each Reliability Coordinator shall have dated evidence that its Operating Procedures, Operating Processes, and Operating Plans that require one or more other Reliability Coordinators to take action were maintained as specified. This evidence may include but is not limited to dated documentation with confirmation of receipt, dated notice of acceptance or agreement to take specified actions, or dated electronic communications with confirmation of receipt and acceptance or agreement to take specified actions.
R3. Each Reliability Coordinator, upon identification of an expected or actual Emergency in its Reliability Coordinator Area, shall notify other impacted Reliability Coordinators. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning, Same Day Operations, Real-time Operations]
M3. Each Reliability Coordinator shall have and provide evidence which may include but is not limited to operator logs, voice recordings, or transcripts of voice recordings, electronic communications, or equivalent dated documentation, that will be used to determine that it, upon identification of an expected or actual Emergency in its Reliability Coordinator Area, notified other impacted Reliability Coordinators. R4. Each impacted Reliability Coordinator shall operate as though the Emergency exists during each instance where Reliability Coordinators disagree on the existence of an Emergency. [Violation Risk Factor: High] [Time Horizon: Operations Planning, SameDay Operations, Real-time Operations]
M4. Each Reliability Coordinator shall have and provide evidence which may include but is not limited to operator logs, voice recordings or transcripts of voice recordings, electronic communications, or equivalent documentation, that will be used to determine that it operated as though an Emergency existed during each instance where Reliability Coordinators disagreed on the existence of an Emergency.
R5. Each Reliability Coordinator that Identifies an Emergency in its Reliability Coordinator Area shall develop an action plan to resolve the Emergency during those instances where impacted Reliability Coordinators disagree on the existence of an Emergency. [Violation Risk Factor: High][Time Horizon: Operations Planning, Same-Day Operations, Real-time Operations]
M5. Each Reliability Coordinator that identifies an Emergency in its Reliability Coordinator Area shall have evidence that it developed an action plan during those instances where impacted Reliability Coordinators disagreed on the existence of an Emergency. This evidence may include but is not limited to operator logs, voice recordings or transcripts of voice recordings, electronic communications, or equivalent dated documentation.
R6. Each impacted Reliability Coordinator shall implement the action plan developed by the Reliability Coordinator that identifies the Emergency during those instances where Reliability Coordinators disagree on the existence of an Emergency, unless such actions would violate safety, equipment, regulatory, or statutory requirements. [Violation Risk Factor: High][Time Horizon: Operations Planning, Same-Day Operations, Real-time Operations]
M6. Each impacted Reliability Coordinator shall have and provide evidence which may include but is not limited to operator logs, voice recordings or transcripts of voice recordings, electronic communications, or equivalent dated documentation, that will be used to determine that it implemented the action plan developed by the Reliability Coordinator who identifies the Emergency when Reliability Coordinators disagree on the existence of an Emergency unless such actions would have violated safety, equipment, regulatory, or statutory requirements.
R7. Each Reliability Coordinator shall assist Reliability Coordinators, if requested and able, provided that the requesting Reliability Coordinator has implemented its emergency procedures, unless such actions cannot be physically implemented or would violate safety, equipment, regulatory, or statutory requirements. [Violation Risk Factor: High] [Time Horizon: Real-time Operations]
M7. Each Reliability Coordinator shall make available upon request, evidence that requested assistance was provided, if able, to requesting Reliability Coordinators unless such actions could not be physically implemented or would violate safety, equipment, regulatory, or statutory requirements. Such evidence could include but is not limited to dated operator logs, voice recordings or transcripts of voice recordings, electronic communications, or other equivalent evidence in electronic or hard copy format. If such a situation has not occurred, the Reliability Coordinator may provide an attestation.
Compliance
1. Compliance Monitoring Process
1.1. Compliance Enforcement Authority:
As defined in the NERC Rules of Procedure, “Compliance Enforcement Authority” (CEA) means NERC or the Regional Entity in their respective roles of monitoring and enforcing compliance with the NERC Reliability Standards.
1.2. Compliance Monitoring and Assessment Processes
As defined in the NERC Rules of Procedure, “Compliance Monitoring and Assessment Processes” refers to the identification of the processes that will be used to evaluate data or information for the purpose of assessing performance or outcomes with the associated reliability standard.
1.3. Data Retention
The Reliability Coordinator shall keep data or evidence to show compliance as identified below unless directed by its Compliance Enforcement Authority to retain specific evidence for a longer period of time as part of an investigation:
- Each Reliability Coordinator shall retain its current, in force document and any documents in force since the last compliance audit for Requirements R1 and R2 and Measures M1 and M2.
- Each Reliability Coordinator shall retain its most recent 12 months of evidence for Requirement R5 and Measure M5.
- Each Reliability Coordinator shall retain 3-calendar years plus current calendar year of evidence for Requirement R6 and Measure M6.
- Each Reliability Coordinator shall retain evidence for 90-calendar days for operator logs and voice recordings and for the period since the last compliance audit for other evidence for Requirements R3, R4, and R7 and Measures M3, M4, and M7.
If a Reliability Coordinator is found non-compliant, it shall keep information related tothe non-compliance until found compliant, or for the time period specified above, whichever is longer.
The Compliance Enforcement Authority shall keep the last audit records and all requested and submitted subsequent audit records.
1.4. Additional Compliance Information
None.
Associated Documents
Operating Plan – An Operating Plan includes general Operating Processes and specific Operating Procedures. It may be an overview document which provides a prescription for an Operating Plan for the next-day, or it may be a specific plan to address a specific SOL or IROL exceedance identified in the Operational Planning Analysis (OPA). Consistent with the NERC definition, Operating Plans can be general in nature, or they can be specific plans to address specific reliability issues. The use of the term Operating Plan in the revised TOP/IRO standards allows room for both. An Operating Plan references processes and procedures, including electronic data exchange, which are available to the System Operator on a daily basis to allow the operator to reliably address conditions which may arise throughout the day. It is valid for tomorrow, the day after, and the day after that. Operating Plans should be augmented by temporary operating guides which outline prevention/mitigation plans for specific situations which are identified day-to-day in an OPA or a Real-time Assessment (RTA). As the definition in the Glossary of Terms states, a restoration plan is an example of an Operating Plan. It contains all the overarching principles that the System Operator needs to work his/her way through the restoration process. It is not a specific document written for a specific blackout scenario but rather a collection of tools consisting of processes, procedures, and automated software systems that are available to the operator to use in restoring the system. An Operating Plan can in turn be looked upon in a similar manner. It does not contain a prescription for the specific set-up for tomorrow but contains a treatment of all the processes, procedures, and automated software systems that are at the operator’s disposal. The existence of an Operating Plan, however, does not preclude the need for creating specific action plans for specific SOL or IROL exceedances identified in the OPA. When a Reliability Coordinator performs an OPA, the analysis may reveal instances of possible SOL or IROL exceedances for pre- or post-Contingency conditions. In these instances, Reliability Coordinators are expected to ensure that there are plans in place to prevent or mitigate those SOLs or IROLs, should those operating conditions be encountered the next day. The Operating Plan may contain a description of the process by which specific prevention or mitigation plans for day-to-day SOL or IROL exceedances identified in the OPA are handled and communicated. This approach could alleviate any potential administrative burden associated with perceived requirements for continual day-to-day updating of “the Operating Plan document” for compliance purposes.
Guidelines and Technical Basis
Rationale:
During development of this standard, text boxes were embedded within the standard to explain the rationale for various parts of the standard. Upon BOT approval, the text from the rationale text boxes was moved to this section.
Rationale for Terminology:
Terminology changed from Adverse Reliability Impact to Emergency for consistency amongst standards. Emergency is a more inclusive term.
Rationale for Requirement R7:
Language added for consistency with proposed TOP-001-3, Requirement R7.