IRO-002-5: Reliability Coordination – Monitoring and Analysis
Purpose: To provide System Operators with the capabilities necessary to monitor and analyze data needed to perform their reliability functions.
Functional Entities
4.1.1. Reliability Coordinators
Effective Date: See Implementation Plan
Requirements and Measures
R1. Each Reliability Coordinator shall have data exchange capabilities with its Balancing Authorities and Transmission Operators, and with other entities it deems necessary, for it to perform its Operational Planning Analyses. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning]
M1. Each Reliability Coordinator shall have, and provide upon request, evidence that could include, but is not limited to, a document that lists its data exchange capabilities with its Balancing Authorities and Transmission Operators, and with other entities it deems necessary, for it to perform its Operational Planning Analyses.
R2. Each Reliability Coordinator shall have data exchange capabilities, with redundant and diversely routed data exchange infrastructure within the Reliability Coordinator’s primary Control Center, for the exchange of Real-time data with its Balancing Authorities and Transmission Operators, and with other entities it deems necessary, for performing its Real-time monitoring and Real-time Assessments. [Violation Risk Factor: High] [Time Horizon: Same-Day Operations, Real-time Operations]
M2. Each Reliability Coordinator shall have, and provide upon request, evidence that could include, but is not limited to, system specifications, system diagrams, or other documentation that lists its data exchange capabilities, including redundant and diversely routed data exchange infrastructure within the Reliability Coordinator’s primary Control Center, for the exchange of Real-time data with its Balancing Authorities and Transmission Operators, and with other entities it deems necessary, as specified in the requirement.
R3. Each Reliability Coordinator shall test its primary Control Center data exchange capabilities specified in Requirement R2 for redundant functionality at least once every 90 calendar days. If the test is unsuccessful, the Reliability Coordinator shall initiate action within two hours to restore redundant functionality. [Violation Risk Factor: Medium ] [Time Horizon: Operations Planning]
M3. Each Reliability Coordinator shall have, and provide upon request, evidence that it tested its primary Control Center data exchange capabilities specified in Requirement R2 for redundant functionality, or experienced an event that demonstrated the redundant functionality; and if the test was unsuccessful, initiated action within two hours to restore redundant functionality as specified in Requirement R3. Evidence could include, but is not limited to: dated and time-stamped test records, operator logs, voice recordings, or electronic communications.
R4. Each Reliability Coordinator shall provide its System Operators with the authority to approve planned outages and maintenance of its telecommunication, monitoring and analysis capabilities. [Violation Risk Factor: High] [Time Horizon: Operations Planning, Same-Day Operations, Real-time Operations]
M4. Each Reliability Coordinator shall have, and provide upon request evidence that could include, but is not limited to, a documented procedure or equivalent evidence that will be used to confirm that the Reliability Coordinator has provided its System Operators with the authority to approve planned outages and maintenance of its telecommunication, monitoring and analysis capabilities.
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. [Violation Risk Factor: High] [Time Horizon: Real-Time Operations]
M5. Each Reliability Coordinator shall have, and provide upon request, evidence that could include, but is not limited to, Energy Management System description documents, computer printouts, SCADA data collection, or other equivalent evidence that will be used to confirm that it has monitored 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.
R6. Each Reliability Coordinator shall have monitoring systems that provide information utilized by the Reliability Coordinator’s operating personnel, giving particular emphasis to alarm management and awareness systems, automated data transfers, and synchronized information systems, over a redundant infrastructure. [Violation Risk Factor: High] [Time Horizon: Real-time Operations]
M6. The Reliability Coordinator shall have, and provide upon request, evidence that could include, but is not limited to, Energy Management System description documents, computer printouts, SCADA data collection, or other equivalent evidence that will be used to confirm that it has monitoring systems consistent with the requirement.
Compliance
Compliance Monitoring Process
1.1. Compliance Enforcement Authority:
“Compliance Enforcement Authority” means NERC or the Regional Entity, or any entity as otherwise designated by an Applicable Governmental Authority, in their respective roles of monitoring and/or enforcing compliance with mandatory and enforceable Reliability Standards in their respective jurisdictions.
1.2. Evidence Retention:
The following evidence retention period(s) identify the period of time an entity is required to retain specific evidence to demonstrate compliance. For instances where the evidence retention period specified below is shorter than the time since the last audit, the Compliance Enforcement Authority may ask an entity to provide other evidence to show that it was compliant for the full-time period since the last audit.
The applicable entity 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.
- The Reliability Coordinator shall retain its current, in force document and any documents in force for the current year and previous calendar year for Requirements R1, R2, and R4 and Measures M1, M2, and M4.
- The Reliability Coordinator shall retain evidence for Requirement R3 and Measure M3 for the most recent 12 calendar months, with the exception of operator logs and voice recordings which shall be retained for a minimum of 90 calendar days.
- The Reliability Coordinator shall keep data or evidence for Requirements R5 and R6 and Measures M5 and M6 for the current calendar year and one previous calendar year.
.3. Compliance Monitoring and Enforcement Program
As defined in the NERC Rules of Procedure, “Compliance Monitoring and Enforcement Program” 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.
Rationale
During development of IRO-002-5, text boxes are embedded within the standard to explain the rationale for various parts of the standard. Upon Board adoption of IRO-002-5, the text from the rationale text boxes will be moved to this section.
Rationale text from the development of IRO-002-4 in Project 2014-03 follows. Additional information can be found on the Project 2014-03 project page.
Changes made to the proposed definitions were made in order to respond to issues raised in NOPR paragraphs 55, 73, and 74 dealing with analysis of SOLs in all time horizons, questions on Protection Systems and Special Protection Systems in NOPR paragraph 78, and recommendations on phase angles from the SW Outage Report (recommendation 27). The intent of such changes is to ensure that Real-time Assessments contain sufficient details to result in an appropriate level of situational awareness. Some examples include: 1) analyzing phase angles which may result in the implementation of an Operating Plan to adjust generation or curtail transactions so that a Transmission facility may be returned to service, or 2) evaluating the impact of a modified Contingency resulting from the status change of a Special Protection Scheme from enabled/in-service to disabled/out-of-service.
Rationale for Requirements:
The data exchange elements of Requirements R1 and R2 from approved IRO-002-2 have been added back into proposed IRO-002-4 in order to ensure that there is no reliability gap. The Project 2014-03 SDT found no proposed requirements in the current project that covered the issue. Voice communication is covered in proposed COM-001-2 but data communications needs to remain in IRO-002-4 as it is not covered in proposed COM-001-2. Staffing of communications and facilities in corresponding requirements from IRO-002-2 is addressed in approved PER-004-2, Requirement R1 and has been deleted from this draft.
Rationale for R2:
Requirement R2 from IRO-002-3 has been deleted because approved EOP-008-1, Requirement R1, part 1.6.2 addresses redundancy and back-up concerns for outages of analysis tools. New Requirement R4 (R6 in IRO-002-5) has been added to address NOPR paragraphs 96 and 97: “…As we explain above, the reliability coordinator’s obligation to monitor SOLs is important to reliability because a SOL can evolve into an IROL during deteriorating system conditions, and for potential system conditions such as this, the reliability coordinator’s monitoring of SOLs provides a necessary backup function to the transmission operator….”
Rationale for Requirements R1 and R2:
The proposed changes address directives for redundancy and diverse routing of data exchange capabilities (FERC Order No. 817 Para 47).
Redundant and diversely routed data exchange capabilities consist of data exchange infrastructure components (e.g., switches, routers, servers, power supplies, and network cabling and communication paths between these components in the primary Control Center for the exchange of system operating data) that will provide continued functionality despite failure or malfunction of an individual component within the Reliability Coordinator’s (RC) primary Control Center. Redundant and diversely routed data exchange capabilities preclude single points of failure in primary Control Center data exchange infrastructure from halting the flow of Real-time data. Requirement R2 does not require automatic or instantaneous fail-over of data exchange capabilities. Redundancy and diverse routing may be achieved in various ways depending on the arrangement of the infrastructure or hardware within the RC’s primary Control Center.
The reliability objective of redundancy is to provide for continued data exchange functionality during outages, maintenance, or testing of data exchange infrastructure. For periods of planned or unplanned outages of individual data exchange components, the proposed requirements do not require additional redundant data exchange infrastructure components solely to provide for redundancy.
Infrastructure that is not within the RC’s primary Control Center is not addressed by the proposed requirement.
Rationale for Requirement R3:
The revised requirement addresses directives for testing of data exchange capabilities used in primary Control Centers (FERC Order No. 817 Para 51).
A test for redundant functionality demonstrates that data exchange capabilities will continue to operate despite the malfunction or failure of an individual component (e.g., switches, routers, servers, power supplies, and network cabling and communication paths between these components in the primary Control Center for the exchange of system operating data). An entity’s testing practices should, over time, examine the various failure modes of its data exchange capabilities. When an actual event successfully exercises the redundant functionality, it can be considered a test for the purposes of the proposed requirement.
Rationale for R4 (R6 in IRO-002-5):
The requirement was added back from approved IRO-002-2 as the Project 2014-03 SDT found no proposed requirements that covered the issues.