About NERC Standards Compliance Assessments Events Analysis Programs
 

 

 





Individual or group.  (29 Responses)
Name  (17 Responses)
Organization  (17 Responses)
Group Name  (12 Responses)
Lead Contact  (12 Responses)
Contact Organization  (12 Responses)
Question 1  (25 Responses)
Question 1 Comments  (29 Responses)
Question 2  (25 Responses)
Question 2 Comments  (29 Responses)
Question 3  (21 Responses)
Question 3 Comments  (29 Responses)
Question 4  (22 Responses)
Question 4 Comments  (29 Responses)
Question 5  (21 Responses)
Question 5 Comments  (29 Responses)
Question 6  (20 Responses)
Question 6 Comments  (29 Responses)
Question 7  (23 Responses)
Question 7 Comments  (29 Responses)
Question 8  (21 Responses)
Question 8 Comments  (29 Responses)
Question 9  (21 Responses)
Question 9 Comments  (29 Responses)
Question 10  (20 Responses)
Question 10 Comments  (29 Responses)
Question 11  (19 Responses)
Question 11 Comments  (29 Responses)
Question 12  (19 Responses)
Question 12 Comments  (29 Responses)
Question 13  (21 Responses)
Question 13 Comments  (29 Responses)
Question 14  (20 Responses)
Question 14 Comments  (29 Responses)
Question 15  (19 Responses)
Question 15 Comments  (29 Responses)
Question 16  (19 Responses)
Question 16 Comments  (29 Responses)
Question 17  (20 Responses)
Question 17 Comments  (29 Responses)
Question 18  (20 Responses)
Question 18 Comments  (29 Responses)
Question 19  (29 Responses)
 
Individual
Kris Manchur
Manitoba Hydro
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
No
I do not agree with the way IRO-001-2 R1 is written. In the present form the requirement may infer that directing action is not an action. It may also infer that the RC is only required to do '"act "or "direct actions" but not both. The way it is written also leads to problems with the VSLs. Perhaps R1 can be edited along the lines of: R1. The Reliability Coordinator shall act to prevent or mitigate the magnitude or duration of events that result in Adverse Reliability Impacts. When required, the actions initiated by the Reliability Coordinator will inlude, but is not limited to, directing the actions to be taken by Transmission Operators, Balancing Authorities, Generator Operators, Transmission Service Providers, Load-Serving Entities, Distribution Providers and Purchasing-Selling Entities within its Reliability Coordinator Area. I agree with the other Requirements in IRO-001-2 with the exception of the "High" Violation Risk Factor assigned to IRO-001-2 requirement R5. This should be a "Medium" VRF at the most. If the emergency has been mitigated, and the entities are not aware, they will still be operating to restrictions which means the grid is operating well within limits. Not notifying the entities that the problem has been mitigated may have some financial implications but it should not place the grid at risk.
Yes
 
No
IRO-001-2 R1 VSLs: You can not split "shall act" and "or direct actions" into separate VSLs. They are one and same. If the RC directs action then they have acted. If the RC failed to direct action or have failed to other wise act then they have failed to act appropriately. Perhaps the VSLs can be drafted along the lines of the following: IRO-001-2 R1 High VSL… The Reliability Coordinator's action was incomplete in that it failed to demonstrate a specific action to prevent or mitigate the magnitude or duration of Adverse Reliability Impacts. IRO-001-2 R1 Severe VSL… The Reliability Coordinator failed to act to prevent or mitigate the magnitude or duration of Adverse Reliability Impacts. IRO-001-2 R2 VSLs: (1) Entities may be justified in an intentional delay in respnding to an RC directive. A justified intential delay may due be equipment problems, a generators ramp rate or system voltage adjustments prior to large system reconfiguration or large transmission loading changes. (2) An entity cannot be faulted for not following an RC directive because to it would violate safety, equipment, regulatory or statutory requirements. Perhaps the VSLs can be drafted along the lines of the following: Moderate VSL… should be deleted. High VSL… The responsible enity followed the Reliability Coordinators directive but with an unjustified delay. Severe VSL… no edits required. IRO-001-2 R5 VSLs: Perhaps the VSLs can be drafted along the lines of the following to reflect to what degree the RC missed the mark: Lower VSL…The Reliability Coordinator failed to notify <25% of its impacted Transmission Operators and Balancing Authorities when the transmission system problem had been mitigated. Moderate VSL… The Reliability Coordinator failed to notify >24% but <50% of its impacted Transmission Operators and Balancing Authorities when the transmission system problem had been mitigated. High VSL…The Reliability Coordinator failed to notify >49% but <75% of its impacted Transmission Operators and Balancing Authorities when the transmission system problem had been mitigated. Severe VSL… The Reliability Coordinator failed to notify >74% of its impacted Transmission Operators and Balancing Authorities when the transmission system problem had been mitigated.
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
 
Group
NPCC
Guy Zito
NPCC
No
There is inconsistency between R3 and M3. In R3, there is a provision for agreement between entities (RC, TOP, BA, GOP, DP) to use a language other than English in their communications. In M3, that option is not presented. M3 should reflect what is written in R3.
No
There is inconsistency between R3 and M3. In R3, there is a provision for agreement between entities (RC, TOP, BA, GOP, DP) to use a language other than English in their communications. In M3, that option is not presented. M3 should reflect what is written in R3.
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
 
Individual
Jeffrey V Hackman
Ameren
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes and No
While we agree that most of the requirements are redundancies that properly belong elsewhere, we are concerned that Requirement 4 and Requirement 8 are not properly represented elsewhere and should not be retired until they re-surface in another standard explicitly. We believe it is still very important for an RC to monitor their respective BAs reserves and CPS performance. Likewise in R8, while the frequency monitoring is a BA function, we think that it is important enough to also be included as an RC function explictly.
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
 
Individual
Dan Rochester
Independent Electricity System Operator - Ontario
Yes
 
No
M3: The evidence to show that concurrence is in place to allow communication using a language other than English is missing. The Measure as written merely asks for evidence that communication in a different language has occurred.
No
(i) R1: Suggest to revise the conditions for all levels to read "…failed to operationally test the altarnative communication facilities within the last……… (ii) R2: The second part under Severe is not needed since failing to notify any impacted entities would imply no communication to the affected entities anyway. If verification of the functionality of the alternate means of telecommunications is also critical even without communicating to the affecte entities, then the second condition should be an "OR". (iii) R3: Failure to having concurrence to use a language other than English for communications between and among operating personnel responsible for real-time operations by itself does not consitute a violate of any requirements; it is the absence of such a concurrence AND having used a language other than English that would consitute a violation. Suggest to revise this condition.
Yes
 
Yes
 
Yes
 
No
(i) R2: the phrase "act without intentional delay" is not necessary since the urgency of taking any actions as directed by the RC's are generally understood to be conveyed in the RC's directives. (ii) R3: Given R2 requires the responsible entities to comply with the RC directives, the part that says "immediately confirm the ability to comply with the directive or" is not needed. R3 should simply require the responsible entities to notify the RC upon recognition of the inability to perform the directive. (iii) The VRF for R5 should not be High. Failure to notify others when potential threats to system reliability have been mitigated does not consititue a high risk to the interconnected system. We suggest it be reduced to a Medium (i.e., that it affects control of the BES).
No
Wording in some of the Measures needs to be revised to reflect changes to R2 and/or R3, if our proposed changes are accepted. Also, we suggest the Requirement numbers be referenced in the Measures.
No
(i) R1: There should not be any distinction made between an RC acting and an RC directing others to act. Failure to mitigate adverse reliability impacts a severe violation of the requirement. We therefore suggest to revise the High and Severe levels as: High if the RC did not act or direct actions to prevent an Adverse Reliability Impact; Severe if the RC did not act or direct ations to mitigate the magnitude or duration of an existing Adverse Reliability Impact. (ii) R2: The High VSL seems contradictory to the requirement, which already has provision of not fully complying with the RC directives due to safety, equipment, or regulatory or statutory requirements. (iii) R3: We have proposed some wording change to R3, which if adopted, would precipitate a need to revise the VSLs for R3 accordingly. (iv) R4 and R5: The VSLs for these two requirements could be graded by assessing the number and/or timing of notifying the affected entities.
No
(i) R1: There is a duplicating requirement in TOP-005 R1.1. Suggest to eliminate one of the two. (ii) We do not agree with eliminating all of R5 to R8. There is a fundamental need for RCs to monitor its area, and even some portion of its adjacent areas to be aware of situations that require preventive and mitigating actions. While arguments can be made that requiring RCs to prevent and mitigate adverse reliability impacts would imply monitoring, the latter is a fundamental duty of any RCs to ensure system reliability. If monitoring is not explicitly stated as a requirement, then the same argument may be extended to training and operational facilities. We do not agree with the drafting team's conclusion that it is not practical to measure real-time monitoring. Measuring can be illustrated, for example, by a compliance audit to review system logs and assess the extent to which an RC follows and assesses system conditions.
No
(i) M1: We suggest to change the word "letter" to "documented request" (ii) If our recommendations to retain some of R5 to R9, some measures will need to be provided.
No
(i) R1: The wording for Low VSL is contradictory (e.g. it determined and requested in the first part but did not request in the second part). Suggest to revise it. (ii) R1: We suggest to grade the VSLs according to the extent to which the percentage of data specification and/or the number of entities not requested. (iii) R2: The RC either has the right or it doesn't, and hence it's a binary requirement. The VSL should be developed accordingly. Further, the wording for the Severe VSL does not correspond to the requirement and measure. The condition should simply be that the Reliability Coordinator failed to demonstrate that it had the authority to veto planned outages to analysis tools, including final approvals for planned maintenance.
No
(i) R1: We not not agree with removing this requirement for the same reason given for the proposal to remove R5 to R8 from IRO-002 (see comments on 10 (ii), above). (ii) R8: We do not agree with completely removing this requirement, especially that part that requires an RC to monitor system frequency. While DCS and CPS are largely a BA's responsibility, the RC is the last line of defence for abnormal system performance and needs to monitor its BAs' performance including their ability to address large frequency deviations, and direct or take corrective actions as needed including requesting emergency assistance on the BAs' behalf and directing load shedding. (iii) R9: The second part of this requirement needs to be retained. IRO-004 covers operational planning, not current day operations. Coordinating pending generator and transmission facility outages is an essential and necessary task by the RC to ensure reliabiity. (iv) R11: The RC needs to monitor ACE, detect and identify the cause of any abnormal ACE, and direct its BAs to take necessary actions to return ACE to within a normal range. (v) R13: We do not agree with removing the latter part of R13. The FAC standards cover the methodlology used in calculating SOLs and IROLs. Regardless of how these limits are calculated, in practice there always exists the possibility that different entities come up with SOLs/IROLs, especially of the inter-ties, that could be different. Operating to the lowest SOLs/IROLs when more than one set exists is a necessary requirement for reliable operation.
No
We suggest to replace the word "impacted" with"other" since there is a preconception that the concered RC makes an assessment of which other RCs are impacted by the coordinatred actions, which may not be the perspective of the other RCs who may in fact be impacted by any coordinated actions among other RCs.
No
Measure 1 actually contains a number of subrequirements that should be stipulated in R1, not M1. If indeed these are required, they should be stipulated in the Requirement section, not the Measures Section.
No
(i) R2: the High and Severe VSLs contradict with the requirement. We believe all of the "nots" should be removed. (ii) R6: The Low VSL should be a High since not agreeing to a plan but implementing one that has not been agreed to is a high violation of the requirement. (iii) The VSLs for R1 may need to be revised if our comments on M1 are adopted.
Yes
 
Yes
 
 
Group
Reliability Coordinator Comment Working Group
Linda Perez
WECC
Yes
 
No
on Measure 3 need to remove the word "all" in reference to voice logs. Measure needs to include evidence of concurrance for using a language other than English
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
No
measures do not align with VSL's (see question 9)
No
R1 talks about "ahall act or direct actions to be taken". High VSL - failure to act. Severe VSL - failure to act and direct. Does "act" mean any action taken short of issuing a directive? Change Severe VSL to failure to act or direct and eliminate the High VSL all together. R2 delay in issuing a directive due to equipmnet problems should be included in the moderate VSL and the body of the requirement and in the measure. The High VSL should be removed because not following the directive for equipment failure is allowed per R2. R5 - Severe VSL should be changed to moderate VSL since the problem has been mitigated and the system is stable and it does not adversely impact reliability. M3 talks about the ability of reliability entities to meet a directive. What constitutes evidence that confirms you are able to immeidately comply with the directive? If the entity agrees to the directive and then is unable to comply due to events outside of their control, such as a CT not starting, do they meet the measure? If the entity, based on the circumstances at the time of the directive, agrees to comply in good faith are they compliant? The Lower VSL should be made N/A because it is not practical for an entity to immediately confirm they are able to meet the directive in all cases.
No
for R1, this should be 2 separate requirments and measures. R1 should have a methodology for determining what data is needed and then a R2 should be a requirement to request this data from the reliability entities.
Yes
add measures for R1 & R2 see question 10
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
 
Individual
Fred Young
Northern California Power Agency
No
R3 should include in the last sentence that the Generator Operator and Distribution Provider may use alternate language for internal operations.
No
M3 should include Generator Operator and Distribution Provider in the applicability.
Yes
 
Yes and No
Remove Generator Operator from the Purpose Statement. The re-written statndard no longer applies to GOP.
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
 
Individual
Denise Roeder
ElectriCities of North Carolina, Inc.
No
We are a joint action agency registered on behalf of our member municipalities, who are all TDUs, neither own nor operate any Bulk Electric System facilities, and perform no real-time operations or operations planning for the BES. There are currently other standards that already apply to us that require us to have processes and means to communicate with our RC, BA, TOP, etc. The proposed modifications to this standard would now make our members subject to this standard as well, based on the DP registration designation. Given that, we believe there needs to be additional clarification of specifically what type of "telecommunications facilities" are required to be considered compliant with this standard. Maybe in the past when this standard applied to TOPs, BAs, and RCs, it was intuitive what type of telecommunications facilities they needed to communicate with each other. However, when you bring in small DPs, it doesn't seem so clear. Obviously we already communicate with our TOP and BA, and have done so for years. As written, the standard is ambiguous in terms of what more, if anything, we would have to put in place to satisfy this standard.
No
See comments on Question 1
No
Depends of what is meant by "telecommunications facilities"
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Individual
Karl Bryan
US Army Corps of Engineers, Northwestern Division
No
R3 needs to have the last sentence revised to allow the Generator Operator and Distribution Provider to use an alternate language for internal operations.
No
M3 needs to include the GO and DP in its requirement for interutility communications in English.
 
 
 
 
 
 
 
 
 
 
Yes
 
 
 
 
 
 
 
Group
PPL Supply Group
Annette Bannon
PPL Generation, LLC
Yes
 
Yes
 
 
Yes
PPL agrees with the changes to COM-002-3. However, for clarity PPL suggests that Generator Operator should be removed from the purpose statement of this standard.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Group
Standards Interface Subcommittee/Compliance Elements Drafting
John Blazekovich
Commonwealth Edison Co.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Standard – IRO-001 R1 Requirement (including sub-requirements) The Reliability Coordinator shall act or direct actions to be taken by Transmission Operators, Balancing Authorities, Generator Operators, Transmission Service Providers, Load-Serving Entities, Distribution Providers and Purchasing-Selling Entities within its Reliability Coordinator Area to prevent or mitigate the magnitude or duration of events that result in Adverse Reliability Impacts. [Violation Risk Factor: High] [Time Horizon: Real-time Operations and Same Day Operations] Proposed Measure Each Reliability Coordinator shall have evidence that it acted, or issued directives, to prevent or mitigate the magnitude or duration of Adverse Reliability Impacts within its Reliability Coordinator Area Attributes of the requirement Binary Timing X Omission X Communication X Quality Other Discussion – 1. As currently worded it can be interpreted that any time an event occurs the RC would be in violation of the standard simply because they had failed “to prevent” an event. 2. This requirement does not have a “timing” element included, although it implies timing based on the “duration of the event”. Including that “duration of the event” is problematic – it appears to imply that human intervention may provide a more timely response than relay operation, we would suggest more clarification about what the “duration” element of the requirement is intended to address (e.g. generation re-dispatch?). 3. There also appears to be a “quality” element included based on the mitigation of magnitude of the event. As a result we believe that timeliness, effectiveness and communication should be the basis of the VSLs. 4. The VSLs as differentiate between directing actions and acting. Practically, there is no difference. The RC is still giving the directive. It is just a matter of who is carrying it out. This is not a valid basis for differentiating between VSLs. We suggest the VSLs be defined based on actual system impact (i.e. Was the RC acting or directing actions to prevent or to mitigate?) and to either modify the requirement to remove timing aspects or to add the timing aspects to the VSLs. SDT Proposed Lower VSL N/A CEDRP Proposed VSL No Comment SDT Proposed Moderate VSL N/A CEDRP Proposed VSL No Comment SDT Proposed High VSL The Reliability Coordinator failed to act to prevent or mitigate the magnitude or duration of Adverse Reliability Impacts. CEDRP Proposed VSL The Reliability Coordinator failed to act to prevent the magnitude or duration of Adverse Reliability Impacts. SDT Proposed Severe VSL The Reliability Coordinator failed to act and direct actions to prevent or mitigate the magnitude or duration of Adverse Reliability Impacts CEDRP Proposed VSL The Reliability Coordinator failed to act and direct actions to mitigate the magnitude or duration of Adverse Reliability Impacts FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? 2. Is the VSL assignment a binary requirement? 3. Is it truly a “binary” requirement? 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? 6. Does the VSL redefine or undermine the stated requirement? 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Additional Compliance Elements Compliance Enforcement Authority NERC shall be responsible for compliance monitoring of the Regional Entity. Regional Entities shall be responsible for compliance monitoring of the Reliability Coordinators, Transmission Operators, Generator Operators, Distribution Providers, and Load Serving Entities. Compliance Monitoring Period and Reset Time Frame N/A Compliance Monitoring and Enforcement Processes: Compliance Audits Self-Certifications Spot Checking Compliance Violation Investigations Self-Reporting Complaints Data Retention Each applicable entity shall retain data and evidence for a rolling 12 months unless directed by its Compliance Enforcement Authority to retain specific evidence for a longer period of time as part of an investigation. The Compliance Enforcement Authority shall keep the last audit records and all requested and submitted subsequent compliance records. Additional Compliance Information None CAE Resource Pool Comments The Enforcement Authority Statement, “NERC shall be responsible for compliance monitoring of the Regional Entity.” Is not clear, if it is intended to encompass Regional Entities that perform RC functions is should be clearly stated, if not it should not be included in the Enforcement Authority section. Standard – IRO-001 R2 Requirement (including sub-requirements) Transmission Operators, Balancing Authorities, Generator Operators, Transmission Service Providers, Load-Serving Entities, Distribution Providers, and Purchasing-Selling Entities shall act without intentional delay to comply with Reliability Coordinator directives unless such actions would violate safety, equipment, or regulatory or statutory requirements. [Violation Risk Factor: High] [Time Horizon: Real-time Operations and Same Day Operations] Proposed Measure Each Transmission Operator, Balancing Authority, Generator Operator, Transmission Service Provider, Load-Serving Entity, or Purchasing-Selling Entity shall have evidence that it acted without delay to comply with the Reliability Coordinator's directives. Attributes of the requirement Binary Timing X Omission X Communication X Quality X Other The team would suggest “intentional delay” be eliminated from the requirement – e.g. “shall act to…”). To act with an intentional delay represents a willful act to disregard the requirement. Willful disregard of requirements is one of the factors that the enforcement authority uses to magnify penalties. Requirements should not include attempts to avoid willful disregard of the requirement. The measure and VSLs do not consider the exceptions for not following the RC objective. The drafting team should consider combining requirements R2 and R3. Thus, one VSL would become failure to notify the RC of the inability to comply. The drafting team could consider applying the numerical category of VSLs for some directives such as an order to redispatch. Obviously, it would not work well if the directive was to reconfigure the system. SDT Proposed Lower VSL N/A CEDRP Proposed VSL No Comment SDT Proposed Moderate VSL The responsible entity followed the Reliability Coordinators directive with a delay not caused by equipment problems. CEDRP Proposed VSL The team does not agree that this is a valid VSL. SDT Proposed High VSL The responsible entity followed the majority of the Reliability Coordinators directive but did not fully follow the directive because it would violate safety, equipment, statutory or regulatory requirements. CEDRP Proposed VSL The team does not agree that this is a valid VSL. The word majority implies some ability to numerically measure the response to the directive. Thus, the drafting team should consider applying the numerical category of the VSL guidelines. SDT Proposed Severe VSL The responsible entity did not follow the Reliability Coordinators directive. CEDRP Proposed VSL The responsible entity did not follow the Reliability Coordinators directive, the directive would not have violated safety, equipment, regulatory, or statutory requirements, and responsible entity did not communicate the inability to follow the directive to the Reliability Coordinator. FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? No 2. Is the VSL assignment a binary requirement? No 3. Is it truly a “binary” requirement? N/A 4. If yes, is the VSL assignment consistent with other binary requirement assignments? N/A 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? Yes 6. Does the VSL redefine or undermine the stated requirement? No 7. Is the VSL based on a single violation of the requirement (not multiple violations)? No Standard - IRO-001 R3 Requirement (including sub-requirements) The Transmission Operator, Balancing Authority, Generator Operator, Transmission Service Provider, Load-Serving Entity, Distribution Provider or Purchasing-Selling Entity shall immediately confirm the ability to comply with the directive or inform the Reliability Coordinator upon recognition of the inability to perform the directive. [Violation Risk Factor: High] [Time Horizon: Real-time Operations and Same Day Operations] Proposed Measure Each Transmission Operator, Balancing Authority, Generator Operator, Transmission Service Provider, Load-Serving Entity, or Purchasing-Selling Entity shall have evidence that it confirmed its ability to comply with the Reliability Coordinator's directives, or if for safety, equipment, regulatory or statutory requirements it could not comply, informed the Reliability Coordinator upon recognition of the inability to comply. Attributes of the requirement Binary Timing Omission Communication X Quality Other Discussion – The requirement appears to be based on communication and can be problematic by including the requirement to immediately confirm the ability to comply, a directive can be issued to one entity or several entities at one time (e.g. conference call, all call, electronic notification) that may create several issues when attempting to process all confirmations, the requirement language presents a risk of being found out of compliance for following a directive but not providing an “immediate” confirmation to the RC. The CEDRP believes it to be a reasonable expectation that all entities will comply with reliability directives and notification should be made only on exception. The SDT should consider combining this requirement with R2. SDT Proposed Lower VSL The responsible entity failed to immediately confirm the ability to comply with the directive issued by the Reliability Coordinator. CEDRP Proposed VSL See above discussion note SDT Proposed Moderate VSL N/A CEDRP Proposed VSL No comment SDT Proposed High VSL N/A CEDRP Proposed VSL No comment SDT Proposed Severe VSL The responsible entity failed to inform the Reliability Coordinator upon recognition of the inability to perform the directive. CEDRP Proposed VSL No comment FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? No 2. Is the VSL assignment a binary requirement? No 3. Is it truly a “binary” requirement? N/A 4. If yes, is the VSL assignment consistent with other binary requirement assignments? N/A 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? As currently worded the CEDRP believe that the requirement should be changed to eliminate that “immediate confirmation” portion of the requirement 6. Does the VSL redefine or undermine the stated requirement? No 7. Is the VSL based on a single violation of the requirement (not multiple violations)? No Standard - IRO-001 R4 Requirement (including sub-requirements) Each Reliability Coordinator that identifies an expected or actual threat with Adverse Reliability Impacts within its Reliability Coordinator Area shall notify, without intentional delay, all impacted Transmission Operators and Balancing Authorities in its Reliability Coordinator Area. [Violation Risk Factor: High] [Time Horizon: Real-time Operations, Same Day Operations and Operations Planning] Proposed Measure Each Reliability Coordinator shall have evidence that it notified, without intentional delay, all impacted Transmission Operators and balancing Authorities in its Reliability Coordinator Area when it identified a real or potential threat with Adverse Reliability Impacts, within its Reliability Coordinator Area. Attributes of the requirement Binary Timing X Omission Communication X Quality Other Discussion – To act with an intentional delay represents a willful act to disregard the requirement. Willful disregard of requirements is one of the factors that the enforcement authority uses to magnify penalties. Requirements should not include attempts to avoid willful disregard of the requirement. This requirement appears to fit the numerical category of the VSL guidelines best. SDT Proposed Lower VSL N/A CEDRP Proposed VSL The Reliability Coordinator who identified an expected or actual threat with Adverse Reliability Impacts within its Reliability Coordinator Area failed to notify 25% or less of the Transmission Operators and Balancing Authorities within its Reliability Coordination Area. SDT Proposed Moderate VSL N/A CEDRP Proposed VSL The Reliability Coordinator who identified an expected or actual threat with Adverse Reliability Impacts within its Reliability Coordinator Area failed to notify more than 25% but less than or equal to 50% of the Transmission Operators and Balancing Authorities within its Reliability Coordination Area. SDT Proposed High VSL N/A CEDRP Proposed VSL The Reliability Coordinator who identified an expected or actual threat with Adverse Reliability Impacts within its Reliability Coordinator Area failed to notify more than 50% but less than or equal to 75% of the Transmission Operators and Balancing Authorities within its Reliability Coordination Area. SDT Proposed Severe VSL: The Reliability Coordinator who identified an expected or actual threat with Adverse Reliability Impacts within its Reliability Coordinator Area failed to issue an alert to all impacted Transmission Operators and Balancing Authorities in its Reliability Coordinator Area. CEDRP Proposed Severe VSL: The Reliability Coordinator who identified an expected or actual threat with Adverse Reliability Impacts within its Reliability Coordinator Area failed to notify more than 75% of the Transmission Operators and Balancing Authorities within its Reliability Coordination Area. FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? No 2. Is the VSL assignment a binary requirement? No 3. Is it truly a “binary” requirement? N/A 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? Yes 6. Does the VSL redefine or undermine the stated requirement? No 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Yes Standard - IRO-001 R5 Requirement (including sub-requirements) Each Reliability Coordinator who identifies an expected or actual threat with Adverse Reliability Impacts, within its Reliability Coordinator Area shall notify, without intentional delay, all impacted Transmission Operators and Balancing Authorities in its Reliability Coordinator Area when the transmission problem has been mitigated. [Violation Risk Factor: High] [Time Horizon: Real-time Operations, Same Day Operations and Operations Planning] Proposed Measure Each Reliability Coordinator shall have evidence that it notified, without intentional delay, all impacted Transmission Operators and balancing Authorities in its Reliability Coordinator Area when the real or potential threat with Adverse Reliability Impacts within its Reliability Coordinator Area has been mitigated. Attributes of the requirement Binary Timing X Omission Communication X Quality Other Discussion – To act with an intentional delay represents a willful act to disregard the requirement. Willful disregard of requirements is one of the factors that the enforcement authority uses to magnify penalties. Requirements should not include attempts to avoid willful disregard of the requirement. Measure 5 is written implying that there is an Adverse Reliability Impact. The drafting team should consider wording the measurement to consider that there may not be an Adverse Reliability Impact requiring a directive. The Commission in paragraph 27 of the VSL order has stated that multiple VSLs are preferable where possible. Suggest applying the numerical category of the VSL Guidelines based on the number of entities notified.. SDT Proposed Lower VSL: N/A CEDRP Proposed Lower VSL: The Reliability Coordinator who identified an expected or actual threat with Adverse Reliability Impacts within its Reliability Coordinator Area failed to notify 25% or less of the impacted Transmission Operators and Balancing Authorities within its Reliability Coordination Area that the Adverse Reliability Impact had been mitigated. SDT Proposed Moderate VSL: N/A CEDRP Proposed Moderate VSL: The Reliability Coordinator who identified an expected or actual threat with Adverse Reliability Impacts within its Reliability Coordinator Area failed to notify more than 25% but less than or equal to 50% of the impacted Transmission Operators and Balancing Authorities within its Reliability Coordination Area that the Adverse Reliability Impact had been mitigated. SDT Proposed High VSL: N/A CEDRP Proposed High VSL: The Reliability Coordinator who identified an expected or actual threat with Adverse Reliability Impacts within its Reliability Coordinator Area failed to notify more than 50% but less than or equal to 75% of the impacted Transmission Operators and Balancing Authorities within its Reliability Coordination Area that the Adverse Reliability Impact had been mitigated. SDT Proposed Severe VSL: The Reliability Coordinator failed to notify all impacted Transmission Operators, Balancing Authorities, when the transmission problem had been mitigated. CEDRP Proposed Severe VSL: The Reliability Coordinator who identified an expected or actual threat with Adverse Reliability Impacts within its Reliability Coordinator Area failed to notify more than 75% of the impacted Transmission Operators and Balancing Authorities within its Reliability Coordination Area that the Adverse Reliability Impact had been mitigated. FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? No 2. Is the VSL assignment a binary requirement? No 3. Is it truly a “binary” requirement? N/A 4. If yes, is the VSL assignment consistent with other binary requirement assignments? N/A 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? Yes 6. Does the VSL redefine or undermine the stated requirement? No 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Yes Standard – IRO-002-2 R1 Requirement (including sub-requirements) Each Reliability Coordinator shall determine the data requirements to support its reliability coordination tasks and shall request such data from its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load- Serving Entities, or adjacent Reliability Coordinators. [Violation Risk Factor: Medium] [Time Horizon: Real-time Operations, Same Day Operations and Operations Planning] Proposed Measure Each Reliability Coordinator shall have and provide upon request evidence that could include, but is not limited to, a letter to Transmission Operators, Balancing Authorities, Transmission Owners, Generator Owners, Generator Operators, and Load-Serving Entities, or adjacent Reliability Coordinators, or other equivalent evidence that will be used to confirm that the Reliability Coordinator has requested the data required to support its reliability coordination tasks. Attributes of the requirement Binary Timing Omission X Communication X Quality Other Discussion – The VSLs attempt to measure the quality of the data requirements. They require the compliance auditor to judge if another RC has material impact and what data is administrative and what data is substantial. Given the typical length of a compliance audit, it is doubtful that the compliance auditor can make these types of judgments about the quality of the data and the material impact of another RC. The drafting team should consider applying numerical category of VSLs based on the number of entities the data request is made from. It is interesting that the measure also does not require any documentation of a data specification. SDT Proposed Lower VSL: The Reliability Coordinator demonstrated that it 1) determined its data requirements and requested that data from its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities or Adjacent Reliability Coordinators with a material impact on the Bulk Electric System in its Reliability Coordination Area but did not request the data from Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities or Adjacent Reliability Coordinators with minimal impact on the Bulk Electric System in its Reliability Coordination Area orr 2) determined its data requirements necessary to perform its reliability functions with the exceptions of data that may be needed for administrative purposes such as data reporting. CEDRP Proposed Lower VSL: The Reliability Coordinator failed to request data to support its reliability coordination tasks from 25% or less of its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities, or adjacent Reliability Coordinators. SDT Proposed Moderate VSL: The Reliability Coordinator demonstrated that it determined the majority but not all of its data requirements necessary to support its reliability coordination functions and requested that data from its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities or Adjacent Reliability Coordinators. CEDRP Proposed Moderate VSL: The Reliability Coordinator failed to request data to support its reliability coordination tasks from more than 25% but less than or equal to 50% of its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities, or adjacent Reliability Coordinators. SDT Proposed High VSL: The Reliability Coordinator demonstrated that it determined 1) some but less than the majority of its data requirements necessary to support its reliability coordination functions and requested that data from its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities or Adjacent Reliability Coordinators Or 2) all of its data requirements necessary to support its reliability coordination functions but failed to demonstrate that it requested data from two of its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities or Adjacent Reliability Coordinators. CEDRP Proposed High VSL: The Reliability Coordinator failed to request data to support its reliability coordination tasks from more than 50% but less than or equal to 75% of its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities, or adjacent Reliability Coordinators. SDT Proposed Severe VSL: The Reliability Coordinator failed to demonstrate that it 1) determined its data requirements necessary to support its reliability coordination functions and requested that data from its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities or Adjacent Reliability Coordinators Or 2) requested the data from three or more of its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities or Adjacent Reliability Coordinators. CEDRP Proposed Severe VSL: The Reliability Coordinator failed to request data to support its reliability coordination tasks from more than 75% of its Transmission Operators, Balancing Authorities, Transmission Owners, Generation Owners, Generation Operators, and Load-Serving Entities, or adjacent Reliability Coordinators, Or, The Reliability Coordinator failed to determine data requirements to support its reliability coordination tasks. FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? 2. Is the VSL assignment a binary requirement? 3. Is it truly a “binary” requirement? 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? 6. Does the VSL redefine or undermine the stated requirement? 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Standard – IRO-002-2 R2 Requirement (including sub-requirements) Each Reliability Coordinator shall have the authority to veto planned outages to analysis tools, including final approvals for planned maintenance. [Violation Risk Factor: Medium] [Time Horizon: Real-time Operations, Same Day Operations and Operations Planning] Proposed Measure 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 the authority to veto planned outages to analysis tools, including final approvals for planned maintenance as specified in Requirement 2. Attributes of the requirement Binary Timing Omission Communication Quality Other X Is this requirement needed? R1 IRO-001-2 requires the RC to mitigate Adverse Reliability Impacts. R2 IRO-001-2 requires responsible entities to comply with the RC directives. Wouldn’t the RC thus have the right to cancel all types of outages (i.e. analysis tools, transmission equipment, etc). FERC has stated in paragraph 112 of Order 693-A that an RC does not derive their authority from agreements but rather from FERC’s approval of the standards. Barring the team’s decision to remove this requirement, the Severe VSL is confusing. We have suggested different wording. SDT Proposed Lower VSL Reliability Coordinator has approval rights for planned outages of analysis tools but does not have approval rights for maintenance on analysis tools. CEDRP Proposed VSL No Comment SDT Proposed Moderate VSL N/A CEDRP Proposed VSL No Comment SDT Proposed High VSL N/A CEDRP Proposed VSL No Comment SDT Proposed Severe VSL Reliability Coordinator approval is not required for planned maintenance or planned outages. CEDRP Proposed VSL Reliability Coordinator does not approve planned maintenance or planned outages. FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? 2. Is the VSL assignment a binary requirement? 3. Is it truly a “binary” requirement? 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? 6. Does the VSL redefine or undermine the stated requirement? 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Standard – IRO-014-2 R1 Requirement (including sub-requirements) R1. The Reliability Coordinator shall have Operating Procedures, Processes, or Plans for activities that require notification, exchange of information or coordination of actions with impacted Reliability Coordinators to support Interconnection reliability. These Operating Procedures, Processes, or Plans shall collectively address, as a minimum, the following: [Violation Risk Factor: Medium] [Time Horizon: Same Day Operations and Operations Planning] R1.1. Communications and notifications, including the mutually agreed to conditions under which one Reliability Coordinator notifies other Reliability Coordinators; the process to follow in making those notifications; and the data and information to be exchanged with other Reliability Coordinators. R1.2. Energy and capacity shortages. R1.3. Planned or unplanned outage information. R1.4. Voltage control, including the coordination of reactive resources for voltage control. R1.5. Coordination of information exchange to support reliability assessments. R1.6. Authority to act to prevent and mitigate instances of causing Adverse Reliability Impacts to other Reliability Coordinator Areas. Proposed Measure M1. The Reliability Coordinator’s System Operators shall have available for Real-time use, the latest approved version of Operating Procedures, Processes, or Plans that require notifications, information exchange or the coordination of actions among impacted Reliability Coordinators. M1.1 These Operating Procedures, Processes, or Plans shall address: M1.2 Communications and notifications, including the mutually agreed to conditions under which one Reliability Coordinator notifies other Reliability Coordinators; the process to follow in making those notifications; and the data and information to be exchanged with other Reliability Coordinators. M1.3 Energy and capacity shortages. M1.4 Planned or unplanned outage information. M1.5 Voltage control, including the coordination of reactive resources for voltage control. M1.6 Coordination of information exchange to support reliability assessments. Authority to act to prevent and mitigate instances of causing Adverse Reliability Impacts to other Reliability Coordinator Areas. Attributes of the requirement Binary Timing Omission x Communication x Quality Other Discussion – The CEDRP has no recommendations regarding this requirement. SDT Proposed Lower VSL: The Reliability Coordinator has Operating Procedures, Processes, or Plans in place for activities that require notification, exchange of information or coordination of actions with impacted Reliability Coordinators to support Interconnection reliability but failed to address one or two of the subrequirements. CEDRP Proposed Lower VSL: No Comment SDT Proposed Moderate VSL: Coordinator has Operating Procedures, Processes, or Plans in place for activities that require notification, exchange of information or coordination of actions with impacted Reliability Coordinators to support Interconnection reliability but failed to address three or four of the subrequirements. CEDRP Proposed High VSL: No Comment SDT Proposed High VSL: The Reliability Coordinator has Operating Procedures, Processes, or Plans in place for activities that require notification, exchange of information or coordination of actions with impacted Reliability Coordinators to support Interconnection reliability but failed to address five of the subrequirements. CEDRP Proposed High VSL: No Comment SDT Proposed Severe VSL: The Reliability Coordinator failed to have Operating Procedures, Processes, or Plans in place for activities that require notification, exchange of information or coordination of actions with impacted Reliability Coordinators to support Interconnection reliability. CEDRP Proposed Severe VSL: No Comment FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? 2. Is the VSL assignment a binary requirement? 3. Is it truly a “binary” requirement? 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? 6. Does the VSL redefine or undermine the stated requirement? 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Standard – IRO-014-2 R2 Requirement (including sub-requirements) R2. Each Reliability Coordinator’s Operating Procedure, Process, or Plan that requires one or more other Reliability Coordinators to take action (e.g., make notifications, exchange information, or coordinate actions) shall be: [Violation Risk Factor: Lower] [Time Horizon: Real-time Operations and Operations Planning] R2.1. Agreed to by all the Reliability Coordinators required to take the indicated action(s). R2.2. Distributed to all Reliability Coordinators that are required to take the indicated action(s). Proposed Measure M2. The Reliability Coordinator shall have evidence that the Operating Procedures, Processes, or Plans that require one or more other Reliability Coordinators to take action (e.g., make notifications, exchange information, or coordinate actions) were: M2.1 Agreed to by all the Reliability Coordinators required to take the indicated action(s). M2.2 Distributed to all Reliability Coordinators that are required to take the indicated action(s). Attributes of the requirement Binary Timing Omission X Communication X Quality Other Discussion – The High and Severe VSLs appear to use “not” incorrectly. SDT Proposed Lower VSL N/A CEDRP Proposed VSL No Comment SDT Proposed Moderate VSL: The Reliability Coordinator failed to have evidence that the Operating Procedures, Processes, or Plans that require one or more other Reliability Coordinators to take action (e.g., make notifications, exchange information, or coordinate actions) were distributed to all Reliability Coordinators that are required to take action. CEDRP Proposed Moderate VSL: The Reliability Coordinator did not have evidence that the Operating Procedures, Processes, or Plans that require one or more other Reliability Coordinators to take action (e.g., make notifications, exchange information, or coordinate actions) were distributed to all Reliability Coordinators that are required to take action. SDT Proposed High VSL: The Reliability Coordinator failed to have evidence that the Operating Procedures, Processes, or Plans that require one or more other Reliability Coordinators to take action (e.g., make notifications, exchange information, or coordinate actions) were not agreed to by all Reliability Coordinators that are required to take action CEDRP Proposed High VSL: The Reliability Coordinator did not have evidence that the Operating Procedures, Processes, or Plans that require one or more other Reliability Coordinators to take action (e.g., make notifications, exchange information, or coordinate actions) were agreed to by all Reliability Coordinators that are required to take action SDT Proposed Severe VSL: The Reliability Coordinator failed to have evidence that the Operating Procedures, Processes, or Plans that require one or more other Reliability Coordinators to take action (e.g., make notifications, exchange information, or coordinate actions) were not agreed to by all Reliability Coordinators that are required to take action and were not distributed to all Reliability Coordinators that are required to take action CEDRP Proposed Severe VSL: The Reliability Coordinator did not have evidence that the Operating Procedures, Processes, or Plans that require one or more other Reliability Coordinators to take action (e.g., make notifications, exchange information, or coordinate actions) were agreed to by all Reliability Coordinators that are required to take action and were distributed to all Reliability Coordinators that are required to take action FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? 2. Is the VSL assignment a binary requirement? 3. Is it truly a “binary” requirement? 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? 6. Does the VSL redefine or undermine the stated requirement? 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Standard – IRO-014-2 R3 XXX-XXX Requirement (including sub-requirements) R3. The Reliability Coordinator shall make notifications and exchange reliability–related information with impacted Reliability Coordinators using its predefined Operating Procedures, Processes, or Plans for conditions that may impact other Reliability Coordinator Areas or other means to accomplish the notifications and exchange of reliability-related information. [Violation Risk Factor: Medium][Time Horizon: Real-time Operations and Operations Planning] Proposed Measure M3. The Reliability Coordinator shall have evidence it made notifications and exchanged reliability–related information with impacted Reliability Coordinators using its predefined Operating Procedures, Processes, or Plans for conditions that may impact other Reliability Coordinator Areas or other means to accomplish the notifications and exchange of reliability-related information. Attributes of the requirement Binary Timing Omission X Communication X Quality Other Discussion: The VSLs appear to be appropriate. Since the only difference is the use of the “and” and “or”, we suggest emphasizing those words in bold. We read this more than once before we noticed the difference. SDT Proposed Lower VSL N/A CEDRP Proposed VSL N/A SDT Proposed Moderate VSL N/A CEDRP Proposed VSL N/A SDT Proposed High VSL: The Reliability Coordinator failed to make notifications or exchange reliability–related information with impacted Reliability Coordinators. CEDRP Proposed High VSL: The Reliability Coordinator failed to make notifications or exchange reliability–related information with impacted Reliability Coordinators. SDT Proposed Severe VSL: The Reliability Coordinator failed to make notifications and exchange reliability–related information with impacted Reliability Coordinators. CEDRP Proposed Severe VSL: The Reliability Coordinator failed to make notifications and exchange reliability–related information with impacted Reliability Coordinators. FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? 2. Is the VSL assignment a binary requirement? 3. Is it truly a “binary” requirement? 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? 6. Does the VSL redefine or undermine the stated requirement? 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Standard – IRO-014-2 R4 XXX-XXX Requirement (including sub-requirements) R4. The Reliability Coordinator shall participate in agreed upon conference calls and other communication forums with impacted Reliability Coordinators. [Violation Risk Factor: Lower][Time Horizon: Real-time Operations] The frequency of these conference calls shall be agreed upon by all involved Reliability Coordinators and shall be at least weekly. Proposed Measure M4. The Reliability Coordinator shall have evidence it participated in agreed upon (at least weekly) conference calls and other communication forums with impacted Reliability Coordinators. Attributes of the requirement Binary Timing X Omission X Communication X Quality Other Discussion – This requirement is purely administrative and probably does not rise to a level of a reliability standard requirement. It is in essence redundant, with R1.1 IRO-014-2? It appears R1.1 addresses the same information that would be expected to be discussed in a weekly conference call. Should the drafting team disagree and retain this requirement, please consider applying multiple VSLs based on how often the RC participates in conference calls, how many they missed, or how many impacted RCs they participated in conference calls with. SDT Proposed Lower VSL: The Reliability Coordinator failed to participate in agreed upon (at least weekly) conference calls and other communication forums with impacted Reliability Coordinators. CEDRP Proposed Lower VSL: The Reliability Coordinator participated in agreed upon conference calls and other communication forums with impacted Reliability Coordinators bi-weekly, Or the Reliability Coordinator failed to participate in one weekly conference call, Or the Reliability Coordinator agreed to participate in conference calls with 25% or less of the impacted Reliability Coordinators. SDT Proposed Moderate VSL: N/A CEDRP Proposed Moderate VSL: The Reliability Coordinator participated in agreed upon conference calls and other communication forums with impacted Reliability Coordinators every third week, Or the Reliability Coordinator failed to participate in two weekly conference calls, Or the Reliability Coordinator agreed to participate in conference calls with more than 25% but less than or equal to 50% of the impacted Reliability Coordinators. SDT Proposed High VSL: N/A CEDRP Proposed High VSL: The Reliability Coordinator participated in agreed upon conference calls and other communication forums with impacted Reliability Coordinators fourth week, Or the Reliability Coordinator failed to participate in three weekly conference calls, Or the Reliability Coordinator agreed to participate in conference calls with more than 50% but less than or equal to 75% of the impacted Reliability Coordinators. SDT Proposed Severe VSL: N/A CEDRP Proposed Severe VSL: The Reliability Coordinator participated in agreed upon conference calls and other communication forums with impacted Reliability Coordinators at least every fifth week, Or the Reliability Coordinator failed to participate in four weekly conference calls, Or the Reliability Coordinator failed to agree to participate in any conference calls, Or the Reliability Coordinator agreed to participate in conference calls with more than 75% but less than 100% of the impacted Reliability Coordinators. FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? 2. Is the VSL assignment a binary requirement? 3. Is it truly a “binary” requirement? 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? 6. Does the VSL redefine or undermine the stated requirement? 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Standard – IRO-014-2 R5 XXX-XXX Requirement (including sub-requirements) R5. When an expected or actual reliability issue is detected, the Reliability Coordinator shall confirm the existence of the issue with the impacted Reliability Coordinators. In the event that the issue cannot be confirmed, each Reliability Coordinator shall operate as though the problem exists. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning, Same Day Operations and Real-time Operations] Proposed Measure The Reliability Coordinator shall have evidence that, in cases when an expected or actual reliability issue was detected, it has confirmed the existence of the issue with the impacted Reliability Coordinators. Attributes of the requirement Binary Timing Omission X Communication X Quality Other Discussion – This requirement is confusing in the way it is worded. We think it is trying to say that the RC should operate as though the reliability issue (should this be Adverse Reliability Impact) is detected until the issue is confirmed not to exist. The way it is worded might imply that if one doesn’t confirm it to exist, operate as though it does. This leaves open the interpretation that a confirmation that it doesn’t exist must still be operated to as though it does exist. The drafting team should consider splitting operating to prevent from operating to mitigate an existing event in the VSLs. SDT Proposed Lower VSL The Reliability Coordinator that detected an expected or actual reliability issue contacted the other Reliability Coordinator(s) to confirm that there was a problem but could not confirm that the problem existed and failed to operate as though the problem existed. CEDRP Proposed VSL N/A SDT Proposed Moderate VSL N/A CEDRP Proposed VSL N/A SDT Proposed High VSL N/A CEDRP Proposed VSL The Reliability Coordinator that detected an expected reliability issue failed to contact the other Reliability Coordinator(s) to confirm that there was a problem. SDT Proposed Severe VSL The Reliability Coordinator that detected an expected or actual reliability issue failed to contact the other Reliability Coordinator(s) to confirm that there was a problem. CEDRP Proposed VSL The Reliability Coordinator that detected an actual reliability issue failed to contact the other Reliability Coordinator(s) to confirm that there was a problem. FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? 2. Is the VSL assignment a binary requirement? 3. Is it truly a “binary” requirement? 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? 6. Does the VSL redefine or undermine the stated requirement? 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Standard – IRO-014-2 R6 XXX-XXX Requirement (including sub-requirements) When an expected or actual reliability issue exists and the impacted Reliability Coordinators cannot agree on a mitigation plan, all impacted Reliability Coordinators shall implement the mitigation plan developed by the Reliability Coordinator who has the reliability issue. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning, Same Day Operations and Real-time Operations] Proposed Measure The affected Reliability Coordinators shall have evidence that, in cases when an expected or actual reliability issue existed and the impacted Reliability Coordinators could not agree on a mitigation plan, they implemented the mitigation plan developed by the Reliability Coordinator who has the reliability issue. Attributes of the requirement Binary Timing Omission X Communication X Quality Other Discussion: We are concerned the validity of this requirement, it may force an RC to implement a solution that they don’t agree with and ultimately result in an Adverse Reliability Impact. The RC may not agree with the solution because it may not be reliable for their footprint. They need to have the ability to veto mitigation plans that cause Adverse Reliability Impacts in their footprint without incurring a compliance violation. SDT Proposed Lower VSL The Reliability Coordinator did not agree on a mitigation plan and implemented a plan other than the one developed by the Reliability Coordinator who had the reliability issue. CEDRP Proposed VSL N/A SDT Proposed Moderate VSL N/A CEDRP Proposed VSL N/A SDT Proposed High VSL N/A CEDRP Proposed VSL N/A SDT Proposed Severe VSL The Reliability Coordinator did not agree on a mitigation plan and did not implement a mitigation plan. CEDRP Proposed VSL What if the RC is correct in disagreeing and the mitigation plan would have caused an Adverse Reliability Impact on their system? FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? 2. Is the VSL assignment a binary requirement? 3. Is it truly a “binary” requirement? 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? 6. Does the VSL redefine or undermine the stated requirement? 7. Is the VSL based on a single violation of the requirement (not multiple violations)?
Group
MRO NERC Standards Review Subcommittee
Terry Bilke
MidwestISO
No
The new R2 requirement is too verbose. We suggest that you strike the final clause: "and shall verify that alternate means of telecommunications are functional." It is obviated by the requirement to notify impacted parties. The responsible entity is already implicitly required to verify its alternate means of communication is functional since it is required to notify its impacted parties of the failure of its normal telecommunications. It can't notify its impacted parties if the alternate communications means are not funcitonal. This clause is similar to the old requirement one that the drafting team appropriately struck. We tend to agree that striking R1 makes sense due to the drafting team's reasoning. However, we are not clear why the new R4 is necessary then. If the drafting team does not believe R1 is necessary shouldn't they respond to the FERC directive with the same reason why R4 is not really necessary? The VRF for new requirement 1 should be lower. It does not fit the definition of a medium VRF. A medium VRF requires that a violation of the requirement directly affect the state or capability or the ability to effectively monitor and control. Failure to test does not result in directly affecting the state or capability or the ability to effectively monitor and control. At a minimum, a failure of the alternative communication systems and primary communication systems must occur first. The failure to perform a single test in a given quarter does not mean that primary and alternative communication systems will fail. Thus, testing is really an administrative issue and should thus be a lower VRF. In the Data Retention section, Distribution Provider and Generation Operators should be added. Currently, there are no data retention requirements listed for them. Suggest modifying the language regarding data retention for compliance violations to: "… is found in violation of a requirement, it shall keep information related to the violation until it the Compliance Enforcement Authority finds it compliant."
No
M4 does not appear to be worded as a measurement. If R4 is kept, we suggest the following modification: "The Distribution Provider and Generation Operator shall demonstrate the existence of its telecommunication systems idenfitied in R4."
No
The VSLs as defined for Requirement 1 appear to violate Guideline 4 that the Commission established in their "Order on Violation Severity Levels Proposed by the Electric Reliability Organization". Guideline 4 requires that a VSL should be based on a single violation. The VSLs as defined accumulate the number of consecutive quarters. This would imply that a single violation could last more than a year and that the compliance auditor could not determine sanctions until the entity becomes compliant or year has passed. A single violation appears to be the failure to test in a single quarter. This requirement is binary in nature in that it is either met or it isn't. We suggest that only a lower VSL should be defined as: "The RC, TOP, or BA failed to test the backup telecommunication facilities for a single calendar quarter." The Lower VSL for R2 is not possible. The act of notifying all impacted entities of the failure of their primary telecommunication system requires the use of the alternative telecommunications systems which is a form of verying that the alternative telecommunications facilities are functional. The drafting team should consider applying the numeric performance category of the VSL Development Guideline Criteria for R2.
Yes
 
Yes
 
Yes
 
No
New requirement R2 should omit act without intentional delay. The desired outcome is for the responsible entity to comply with the RC directive. Adding act without intentional delay only confuses the situation and adds questions. What is an intentional delay? The word act implies that the requirement is met simply if the responsible entity attempted to meet the directive but was unable to do so. That is already considered in with the clause that begins "unless such actions would violate …". Thus, the word act is not necessary. The word immediately should be removed from the new R3. This attempts to time frame the response of the responsible entity and remove the judgment from the compliance auditor. We agree with the concept of doing this but in reality it only confuses the issue and the compliance auditor will likely apply his judgment regarding what immediate is anyway. Additionallly, the requirement attempts to separate the act of confirming that the responsible entity can take the action from notifying the RC that the entity can't take the action. This is not logical. What RC is going to request a responsible entity to take action that would violate safety, equipment, statutory, or regulatory requirements? The RC should already be aware of those requirements and likely won't direct actions that violate them. Thus, the likely scenario is that the responsible entity will attempt to take action and discover that equipment is not funciton properly and thus notify the RC. We suggest striking the "shall immediately confirm the ability to comply with the directive or" from the requirement. This part of the requirement is not needed because the responsible entity is already obligated to follow the RCs directive (see order 693.) Thus, the assumption is that the order will be followed unless it can't be followed because it will violated safety, equipment, statutory, or regulatory requirements. Requirements R4 and R5 are unnecessary. New R1 requires the RC to direct actions to be taken by the TOP, BA, GOP, TSP, LSE, DP and PSE to prevent or mitigate the magnitude or duration of events that result in Adverst Reliability Impacts. The RC can't direct these actions without notifying all impacted TOPs and BAs. They would also have to notify them when actions are no longer necessary.
No
Some compliance auditors have been taking the need for evidence to the extreme. We have encountered actual situations where if a measure states evidence shall be provided for requirements that are event based, the compliance auditor expected evidence even if no event occurred. For example, some RCs rarely issue directives. As M1 is written, some compliance auditors would require the RC to provide evidence that no reliability directives were issued. This is not possible. We suggest modifying the measurement to: Each Reliability Coordinator shall have evidence that it acted, or issued directives, to prevent or mitigate the magnitude or duration of Adverse Reliability Impacts within its Reliability Coordiantor Area if needed. If there were no directives issues (assuming there are no complaints or evidence to the contrary of the need to issue a directive), no evidence is necessary."
No
The R1 High and Severe VSL appear to differ only by the inclusion of directing actions in Severe. From a practical perspective, what is the difference between directing actions and acting? We don't believe there is any. The actions are the result of the RC authority whether the RC takes the actions themselves or directs someone else to. We suggest a better alternative for the VSL levels would be for the High level to reflect that the RC did not act or direct actions to prevent an Adverse Reliability Impact and Severe would be that the RC did not act or direct ations to mitigate the magnitude or duration of an existing Adverse Reliability Impact. The moderate VSL for R2 is not practical and too subjective. What constitutes a delay? What if the responsible entity takes five minutes to determine how to carry out the action or if their equipment currently is capable of carrying out the action? Is this a delay? We suggest striking this Moderate VSL. The High VSL does not agree with the requirement. It considers the inability to fully follow an RC directive due to a violation of the safety, equipment, statutory, or regulatory requirements a violation. This is in direct conflict with the requirement. We suggest that the High VSL should be struck. We suggest the Severe VSL should be that the responsible entity failed to follow the RC directive and it would not have violated the safety, equipment, statutory or regulatory requirements. Currently, the Severe category does not allow that the responsible entity may not be able to carry out the directive due to the violation of safety, equipment, statutory, or regulatory requirements. In question 7, we request that the drafting team strike part of requirement 3. The striking of that portion of requirement 3 obviates the lower VSL. In paragraph 27 of the ORDER ON VIOLATION SEVERITY LEVELS PROPOSED BY THE ELECTRIC RELIABILITY ORGANIZATION, the Commission expresses "that, as a general rule, gradated Violation Severity Levels, whereever possible, would be preferable to binary Violation Severity Levels". Given that it is possible to define gradated VSLs for R4 and R5, we suggest that the drafting team should consider applying the numeric performance category of the Violation Severity Levels Development Guidelines Criteria based on the number of impacted TOPs and BAs that were notified.
No
New Requirement R1 is duplicate to the requirement TOP-005-1 R1.1. If the drafting team can't delete TOP-005-1 R1.1, they should notify other appropriate drafting teams of the need to remove the requirement. We do not agree with eliminating requirements R5, R6, R7, and R8 in their entirety. The requirements as they are written are problematic. However, we do believe that there is a need for a basic requirement to monitor the system. The requirements should be that the RC should compare actual system flows to SOLs and IROLs. While some will argue SOLs are not the responsibility of the RC, failure to monitor SOLs could cause the RC to miss unknown IROLs since an SOL can become an IROL. Several SOL violations in a given area also can be indicative of a broader system problem the RC should be addressing. We also do not agree with the drafting team's conclusion that it is not practical to measure real-time monitoring. It is very easy to measure. As an example, a compliance auditor could select a day and an SOL or IROL and ask for the system flows from that day or hour etc. This is generally easy for any RC to produce with today's data archiving software. We believe that there should be a requirement that the RC have a state estimator and real-time contingency analysis as well (RTCA). The drafting team needs to be careful in the construction of these requirements to make them practical and measurable. For instance, making the requirement to have a state estimator and RTCA is measurable in that the compliance auditor can verify their existence but this is not stringent enough because they may only run once a week. At the same time, if we create a requirement that SE and RTCA must run every 5 minutes, we could inadvertantly create a requirement that any missing 5 minute run of RTCA and SE could be construed as a violation. There also needs to be a requirement that there is a real-time assessment of voltage as well. New Requirement R2 is no longer needed as a result of paragraph 112 in Order 693-A. Since the RC's "authority to issue directives arises out of the Commission's approval of Reliability Standards" the RC already has veto authority or will have once R1 IRO-001-2 is approved. This requirement obligates the RC to take actions or direct actions to prevent Adverse Reliabilty Impacts. Veto outages of equipment and analysis tools would fall into this category even if the RC couldn't say for certain that an Adverse Relability Impact was going to occur but rather they are concerned one could occur due to heavy loads for example.
No
Measure 1 should not focus on a letter as evidence. A more appropriate measure would be a data specification document and actual verification that data has been received. The letter or equivalent is only needed if data has not been supplied. Demonstration of the actual receipt the data would be easy. Requirement 2 is not needed and thus Measure 2 is not needed per paragraph 112 of Order 693-A. Additional measures are needed to address the proposed requirements in question 10.
No
For R1, the lower VSL contradicts itself. It states that RC demonstrated that it determined its data requirements and requested that data and then follows with that it didn't request that data. The second option in the Lower VSL category is not practical and a compliance auditor would not be in a position to determine this. In fact, if the administrative data is not requested, other administrative requirements for reporting would be violated. Additionally, it does not make sense that an RC would determine its data needs and then omit data for administrative reporting. Further, is it the compliance auditor's job to judge if the data the RC requests is sufficient or is it his job to see that the RC has met the requirement to define the data? The remaining VSLs imply that the RC may define only partial data requirements. This does not seem likely. Why would the RC do this? This VSL appears to add to the requirement by making it appear that the compliance auditor is to judge the completeness of the data requirement. This violates Guideline 3 of the FERC ORDER ON VIOLATION SEVERITY LEVELS PROPOSED BY THE ELECTRIC RELIABILITY ORGANIZATION. Practically, it would not be enforceable anyway. It would require the RC to admit that they did not include administrative data in the their data requirements. It is doubtful this would happen because the RC likely believes they prepared a complete data requirement document. We suggest that the VSLs should be: Severe: The RC did not determine it data requirements or the RC could not demonstrate it requested the necessary data if actual receipt of the necessary data can't be deomstrated for greater than 75 to 100% of the TOPs, BA, TO, GO, GOPs, LSEs and adjacent RCs. High: The RC could not demonstrate it requested the necessary data if actual receipt of the necessary data can't be deomstrated for greater than 50 and less than or equal to 75% of the TOPs, BA, TO, GO, GOPs, LSEs and adjacent RCs. Medium: The RC could not demonstrate it requested the necessary data if actual receipt of the necessary data can't be deomstrated for greater than 25% and less than or eqal to 50% of the TOPs, BA, TO, GO, GOPs, LSEs and adjacent RCs. Lower: The RC could not demonstrate it requested the necessary data if actual receipt of the necessary data can't be deomstrated for greater than 0% and less than or equal to 25% of the TOPs, BA, TO, GO, GOPs, LSEs and adjacent RCs. R2 VSLs are not needed er paragraph 112 of Order 693-A. The Severe VSL contradicts the requirement.
No
R1 includes many requirements for monitoring the system that are important, measurable and should be retained. Monitoring is too critical to operating the system to completely eliminate these requirements. R4, R8 and R11 are problematic as currently written. However, there have been actual instances of a large BA intentionally operating short hundreds of MWs of energy. I believe this occurred during the summer of 1999. Thus, the RC should be monitoring the BAs ACE and directing the BA to correct it if it becomes too large. It is not necessary or even useful for the RC to monitor the BA CPS performance.
No
Please strike "as a minimum" in R1. By definition, the requirement defines the minimum. Please strike R1.6. RCs already have the authority to act per paragraph 112 of Order 693-A. Since R2 requires the RCs to agree, is the "mutually agreed to" clause in R1.1 necessary? Please strike requirements R4 and R4.1. It is duplicative to R1.1. Conference calls are a form of communication and should be address per R1.1. R5 is confusing. If a reliability issue isn't confirmed, doesn't this mean there is no reliability issue? Isn't this the point of confirming? Additionally, we suggest using validate instead of confirm. R6 appears to be a rewrite of requirements R1, R2 and their sub-requirements in IRO-016. We agree that those requirements do need to be written more succinctly or removed altogether. However, R6 does not accomplish the goal and only confuses that matter further. The reason the RCs may not be able to agree on a mitigation plan is that RC with the reliability issue may be requesting mitigations that the other RCs believe may cause them reliability issues. This requirement appears to suggest that the solution to a disagreement on the mitigation plan is cut and dried. Generally, the reason the disagreement arises is due to one RC not fully understanding the impact of their actions on another RC. The bottom line is that the RCs may have disagreements and there is no way to require a solution in these types of situations. Please revise R6 to require using the mitigation plan developed by the Reliability Coordinator who has the reliability issue provided that the mitigation plan does not cause a reliability issue in the other region. As Requirement 1 is currently written, one could interpret the requirement for every Operating Process, Procedure and Plan to address each of the sub-requirements. That is not necessary. The drafting team needs to consider modifying the requirement to make it clear that not every sub-requirement must be addressed in every Operating Process, Procedure, and Plan and to also make it clear that the some sub-requirements may only be appropriately addressed in a Process but not a Plan for instance.
No
Measure 1 appears to add to the requirement. Requirement 1 does not mention anything about System Operators yet the measurement does. The measurement should just be to verify that the RC has have Operating Processes, Procedures, and Plans. The sub-measurements are not measurements at all. There should be the single measurement to verify the Operating Processes, Procedures, and Plans have been developed and address the sub-requirements. This really points out the problem with making the criteria that must be considered in the Operating Processes, Procedures, and Plans sub-requirements in the first place. They aren't requirements of any sort. They represent criteria. The drafting team should consider making them a bulleted list without the Rs, then the drafting team won't feel compelled to write sub-measures that don't measure anything. We do not agree with M6 because we don't agree with R6.
No
For R2, the High and Severe VSLs contradict the requirement. We believe all of the "nots" should be removed. We don’t' agree with the VSLs in R4 since we believe R4 should be struck. The Lower VSL for R6 should not even be a violation unless the impact was negative. If the RC implemented a different mitigation plan and resolved the issue, then the RC was likely correct to disagree.
Yes
 
Yes
We do agree with moving the requirement. However, the drafting team needs to revisit the wording of the requirement. The new wording is much more confusing. Until we reviewed IRO-016-2, it was not clear at all that R6 in IRO-014 was attempting to mimic R1 and its sub-requirements in IRO-016-2.
 
Group
Southern Company Transmission
Jim Busbin
Southern Company Services, Inc.
No
1.1 - In R1, we suggest that "operationally test by way of operator action" should be defined to remove any confusion regarding what the term requires. The word "ensure" needs to be changed to "assure" to more accurately convey the intent of the requirement. We also suggest changing the word "facilities" to "capabilities". 1.2 - R2 is overly broad and should include a reasonable time frame for notification. For example, as currently written, a telecom outage of only one minute for which a notification is not made would be a severe violation. The VSL should be consistent with the language of the requirement. A very short, insignificant telecom outage with no notification could result in a severe violation as the requirement is presently written and VSL's applied. 1.3 - R1, R2 and R3 should be expanded to include the list of entities the RC needs to talk with as included in the Applicability section of IRO-001-2 (RC, TO, BA, GO, DP, TSP, LSE, PSE). These entities should also be included in the purpose statement and R4 and M4 can then be eliminated. 1.4 - In R3, we suggest that the last sentence of R3 should be changed to "entities may use an alternative language for internal operations" rather than allowing only TOs and BAs to have this option.
No
2.1 - A general comment regards the production of evidence - such language should be standardized as "have and provide upon request" and the authorized requestors identified. This comment should apply to all standards. 2.2 - M2 is overly broad and should include a reasonable time frame for notification. For example, as currently written, a telecom outage of only one minute for which a notification is not made would be a severe violation. 2.3 - The Drafting Team should coordinate the data retention time frame with the requirement measures for R1. DPs and GOs should also be included in the measures requirements.
Yes
3.1 - The expanded list of entities recommended in comment 1.3 and 1.4 need to be included the VSLs 3.2 - The Severe VSL for R2 should be corrected. Add the word 'to' as follows: "…and failed to verify the …"
No
4.1 - We agree with the recommendation to retire COM-002-3 when COM-003-1 is approved; however we suggest the following changes should be made for the interim applicability of COM-002-3: 4.2 - The Purpose statement should be revised to re-align with the revisions in the Standard. 4.3 - The applicability of COM-002-3 should be consistent with the applicability of IRO-001-2. 4.4 - The words "clear, concise, and definitive manner" in R1 are ambiguous and impossible to measure. We suggest they be replaced with "the RC shall direct". 4.5 - An additional requirement, R2, should be added that requires the Operator to repeat the information back correctly (i.e., separate this requirement from R1). 4.6 - Grammatical changes are suggested. The revised requriement reads as follows: " To ensure Balancing Authorities, Transmission Operators, and Generator Operators have adequate communications; to ensure that these communication capabilities are staffed and available for addressing a real-time emergency condition; and to ensure effective communications by operating personnel." 4.7 - At the Data Retion section, the reference to 'Requirement 3, Measure 3' should be consistent with the modified standard. The revised standard only has one requirement. 4.8 - The use of calendar days in the Data Retention seciton is inconsistent with related standards where 'months' are used.
No
5.1 - The measures need to be revised to match the new requirements.
No
6.1 - The severity levels need to be revised to match the new requirements.
No
7.1 - Applicability 4.2 - Transmission Operator should be plural. 7.2 - The revised definition of "Adverse Reliability Impacts" (R1) should be included at the top of Standard IRO-001-2, per Glossary of Terms Used in Standards: All defined terms used in reliability standards shall be defined in the glossary. Definitions may be approved as part of a standard action or as a separate action. All definitions must be approved in accordance with the standards process. 7.3 - In R2 insert the word "its" before Reliability Coordinator. 7.4 - In R3, replace "immediately" with "without intentional delay", replace "ability" with "intent", replace "or" with "and" and replace "the" with "its" before Reliability Coordinator.
No
8.1 - In M2 and M3, Add Distribution Provider. 8.2 - In M2 add "intentional" between "without" and "delay". 8.3 - In M3 replace "ability" with "intent", replace "or" with "and" and replace "the" with "its" before Reliability Coordinator's and Reliability Coordinator. 8.4 - In M5, change "has" to "had".
No
9.1 - R1 is a binary requirement and should have only a severe VSL. The RC either acts or he doesn't - If he fails to act, he fails to direct and mitigate the problem by default. 9.2 - R2 VSLs need to be rewritten to recognize that some directives may not be followed because of safety, regulatory or statuatory requirements. 9.3 - Remove the Lower severity level in R3 to conform to changes in R3 and M3.
No
10.1 - We propose that R1 and R2 should be moved to the RC Certification Procedure and this standard retired. If this standard is not retired then we recommend Comments 10.2 and 10.3. 10.2 - At Requirement R2, the RC is given 'veto' authority. Is a standard an appropriate place to give this type of authority? 10.3 - The revised Purpose basically provides that the RC will have access to information and control of analysis tools. What is the correlation of information/control to veto authority/approval of planned maintenance?
No
11.1 - Moving R1 and R2 to the RC Certification Procedure, will eliminate measurement requirements.
No
12.1 - Moving R1 and R2 to the RC Certification Procedure, will eliminate VSL requirements.
Yes
13.1 - We agree with retiring this standard.
No
14.1 - R1 and R2 - The word "impacted" tends to broaden the requirements to have procedures, processes and plans in place with each RC within the RC's Interconnection. We suggest the phrasing should be tightened up to convey the original meaning that the team intended. For example, does the team intend for the FRCC RC to have an agreement with the PJM or MISO RC? 14.2 - We suggest bringing R6 under R1 as subrequirement R1.7 and rewrite it as follows: R1 - The Dispute Resolution process will be followed when the Reliability Coordinator issuing a mitigation plan and the Reliability Coordinator(s) receiving a mitigation plan disagree on the proper steps to be taken. 14.3 - We suggest deleting R4.1 and adding a second sentence to R4: The frequency of these communications shall be at least weekly. 14.4 - R4: The word "impacted" makes it sound like these calls are only to be made when problems are expected or are occurring. If this requirement is intended more for operational awareness calls (such as the daily SERC RC call), then the word "impacted" needs to be changed to "contiguous" or a similar term. 14.5 - We suggest rewriting R5 to read: In the event that a reliability issue cannot be confirmed, each Reliability Coordinator shall operate as though the problem exists. 14.6 - At Requirement R1, the use of the phrase "as a minimum" seems to add some flexibility for development of procedures, processes and plans. A negative consequence is that it introduces more abmiguity. The recommendation is to strike the phrase. 14.7 - At Requirement R1.6, consider the following: "Authority to act to prevent and mitigate instances 'that have the potential to cause' Adverse Reliability Impacts to other Reliability Coordinator Areas."
No
15.1 - In M1, delete "for Real-time use". 15.2 - Modify the measures to be consistent with changes requested in R1, R2, R4, R4.1 and R5.
No
16.1 - In R2, severe should be "... and no action was taken by the RC". 16.2 - In R5, severe should also include "... or that the RC failed to operate as though the problem existed." 16.3 - Modify the VSLs to be consistent with changes requested in R1, R2, R4, R4.1 and R5.
Yes
17.1 - We agree with the recommendation to retire IRO-015-2.
Yes
18.1 - We agree with the recommendation to retire IRO-016-2.
19.1 - We suggest the effective date for the retirement of R5 (NERC Net Security Policy) in the COM-001-2 Standard should be effective immediately upon regulatory approval. As written, the Policy is unenforceable, contains no measures and is not germane to BES Reliability.
Individual
Kathleen Goodman
ISO New England Inc.
No
ISO New England does not support the removal of Requirement 1. Also, we believe Requirement 3 is written such that it may pose an unnecessary requirement on the Hydro Quebec area given the terminology "inter-entity" and support further clarification.
No
See answer to #1.
 
No
ISO New England believes it is inefficient to have a (temporary) Standard with only one Requirement and recommend including this Requirement in COM-001, with COM-001 renamed to "Communications."
No
See response to Q#4
 
Yes and No
We beleive the word "threat" shoudl be replaced with "events" in Requirements 4 and 5.
 
 
Yes and No
Suggest changing with word "request" to "document" in Requirement 1.
 
 
Yes
 
Yes and No
As Requirement 1 is currently written, one could interpret the requirement for every Operating Process, Procedure and Plan to address each of the sub-requirements. That is not necessary. The drafting team needs to consider modifying the requirement to make it clear that not every sub-requirement must be addressed in every Operating Process, Procedure, and Plan and to also make it clear that the some sub-requirements may only be appropriately addressed in a Process but not a Plan for instance. Use of the term collectively may resolve this dilemma.
 
 
Yes
 
Yes
 
 
Individual
Edward Davis
Entergy Services, Inc
Yes
The drafting team should consider expanding the second sentence of R3 to apply to internal communications of any affected entity not just BAs and TOPs.
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
No
PER-003 R1 does not specifically addresss delegated functions; therefore, this requirement is not redundant with IRO-001 R6 without changes to PER-003 to specifically deal with employees perforing delegated functions.
Yes
 
No
The VSL for R2 does not seem consistent with the language in the requirement. It is not clear why the entity should be subject to a high VSL if the entity did not comply with an RC directive due to safety or regulatory prohibition, and made the RC aware of same.
No
IRO-002-1 R9, the deleted language of the second sentence is not adequately covered by the language in EOP-008-0 R1, unless those outages are tied to the loss of a control center. EOP-008-0 is in the process of being revised and this language could be included in the revision, but it isn't adequately addressed by the version 0 standard.
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Overall, we think the coordinated set of standards being developed by the RTOSDT and IROLSDT are good for reliability, crisp, and tightens up the reliability concepts.
Individual
Danny Dees
MEAG Power
 
 
 
 
 
 
No
Directives that are mandatory under R2 of IRO-001-2 should have boundaries consistent with the proper role of an RC. For example, if an RC directs an LSE with a 15% planning reserve margin to execute purchase power agreements until its reserve margin is at least 20% and the LSE refuses, then the LSE may have violated this standard. Other examples of improper RC directives are directives to increase coal inventories, buy firm fuel transportation rights, reconductor transmission lines, purchase spare equipment, etc. Granted entities may be able to conjure up a regulatory or statutory basis for refusing many improper RC directives but in some instances there may be no permissible grounds to refuse. The appropriate solution is to modify the standard to ensure that improper directives are never mandatory in the first place. Specifically, NERC is urged to state that RC directives are mandatory only if they pertain to specific categories such as: switching orders to reconfigure the BES, orders to postpone scheduled outages of BES equipment, orders to change generator output, orders to curtail transactions or orders to curtail load.
No
The M2 measure should not mandate compliance with RC directives that are improper as defined in my response to question 7.
 
 
 
 
 
 
 
 
 
 
My other concerns are addressed in the comments of the SERC OC Standards Review Group.
Individual
Mike Gentry
Salt River Project
Yes
 
No
M3 should include providing evidence of concurrence to use a language other than English. This will better align the measure with the VSL language.
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
No
R1 states the RC must act OR direct. The R1 VSL's attempt to distinguish between act and direct. The requirement allows for either action. I suggest that the High VSL be removed and replaced by an N/A. The Severe VSL should be amended so that the words "act and direct" are replaced by the words "act OR direct" as is consistent with the requirement and the measure. R2:The moderate VSL introduces the phrase "equipment problems" for the first time in the Standard. "Equipment Problems" needs to be included in the Requirement, R2, and defined in the Measure for R2. R5: The Severe VSL needs to be moved to the Moderate category. This condition does not constitute an Adverse Reliability Impact that severely threatens the BES.
Yes
 
No
R1: The Requirement and VSL's mention that the RC will determine it's data needs. Yet the Measure for R1 does not mention this, it only mentions the RC requesting the data from it's member emtities. This Measure needs to include a measure for how the RC determines it's data needs.
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
I appreciate the new comment form in Word version. his allows me to comment on each requirement specifically addressing the requirement, measure or the VSL's
Group
SERC OC Standards Review Group
Jim Griffith
Southern Co.
Yes and No
1.1 - In R1, we suggest that "operationally test" should be defined to remove any confusion regarding what the term requires. The word "ensure" needs to be changed to "assure" to more accurately convey the intent of the requirement. We also suggest changing the word "facilities" to "capabilities". 1.2 - R2 is overly broad and should include a reasonable time frame for notification. For example, as currently written, a telecom outage of only one minute for which a notification is not made would be a severe violation. 1.3 - R1, R2 and R3 should be expanded to include the list of entities the RC needs to talk with as included in the Applicability section of IRO-001-2 (RC, TO, BA, GO, DP, TSP, LSE, PSE). These entities should also be included in the purpose statement and R4 and M4 can then be eliminated. 1.4 - In R3, we suggest that the last sentence of R3 should be changed to "entities may use an alternative language for internal operations" rather than allowing only TOs and BAs to have this option.
Yes and No
2.1 - A general comment regards the production of evidence - such language should be standardized as "have and provide upon request" and the authorized requestors identified. This comment should apply to all standards. 2.2 - M2 is overly broad and should include a reasonable time frame for notification. For example, as currently written, a telecom outage of only one minute for which a notification is not made would be a severe violation. 2.3 - The Drafting Team should coordinate the data retention time frame with the requirement measures for R1. DPs and GOs should also be included in the measures requirements
Yes and No
3.1 - The expanded list of entities recommended in comment 1.3 and 1.4 need to be included the VSLs
Yes and No
4.1 - We agree with the recommendation to retire COM-002-3 when COM-003-1 is approved; however we suggest the following changes should be made for the interim applicability of COM-002-3: 4.2 - The Purpose statement should be revised to re-align with the revisions in the Standard. 4.3 - The applicability of COM-002-3 should be consistent with the applicability of IRO-001-2. 4.4 - The words "clear, concise, and definitive manner" in R1 are ambiguous and impossible to measure. We suggest they be replaced with "the RC shall direct". 4.5 - An additional requirement, R2, should be added that requires the Operator to repeat the information back correctly (i.e., separate this requirement from R1).
No
5.1 - The measures need to be revised to match the new requirements.
No
6.1 - The severity levels need to be revised to match the new requirements
Yes and No
7.1 - Applicability 4.2 - Transmission Operator should be plural. 7.2 - The revised definition of "Adverse Reliability Impacts" (R1) should be included at the top of Standard IRO-001-2, per Glossary of Terms Used in Standards: All defined terms used in reliability standards shall be defined in the glossary. Definitions may be approved as part of a standard action or as a separate action. All definitions must be approved in accordance with the standards process. 7.3 - In R2 insert the word "its" before Reliability Coordinator 7.4 - In R3, replace "immediately" with "without intentional delay", replace "ability" with "intent", replace "or" with "and" and replace "the" with "its" before Reliability Coordinator.
Yes and No
8.1 - In M2 and M3, Add Distribution Provider. 8.2 - In M2 add "intentional" between "without" and "delay". 8.3 - In M3 replace "ability" with "intent", replace "or" with "and" and replace "the" with "its" before Reliability Coordinator's and Reliability Coordinator. 8.4 - In M5, change "has" to "had".
Yes and No
9.1 - R1 is a binary requirement and should have only a severe VSL. The RC either acts or he doesn't - If he fails to act, he fails to direct and mitigate the problem by default. 9.2 - R2 VSLs need to be rewritten to recognize that some directives may not be followed because of safety, regulatory or statuatory requirements. 9.3 - Remove the Lower severity level in R3 to conform to changes in R3 and M3.
Yes and No
10.1 - We propose that R1 and R2 should be moved to the RC Certification Procedure and this standard retired.
Yes and No
11.1 - Moving R1 and R2 to the RC Certification Procedure, will eliminate measurement requirements.
Yes and No
12.1 - Moving R1 and R2 to the RC Certification Procedure, will eliminate VSL requirements.
Yes
13.1 - We agree with retiring this standard
Yes and No
14.1 - R1 and R2 - The word "impacted" tends to broaden the requirements to have procedures, processes and plans in place with each RC within the RC's Interconnection. We suggest the phrasing should be tightened up to convey the original meaning that the team intended. For example, does the team intend for the FRCC RC to have an agreement with the PJM or MISO RC? 14.2 - We suggest bringing R6 under R1 as subrequirement R1.7 and rewrite it as follows: R1 - The Dispute Resolution process will be followed when the Reliability Coordinator issuing a mitigation plan and the Reliability Coordinator(s) receiving a mitigation plan disagree on the proper steps to be taken. 14.3 - We suggest deleting R4.1 and adding a second sentence to R4: The frequency of these communications shall be at least weekly. 14.4 - R4: The word "impacted" makes it sound like these calls are only to be made when problems are expected or are occurring. If this requirement is intended more for operational awareness calls (such as the daily SERC RC call), then the word "impacted" needs to be changed to "contiguous". 14.5 - We suggest rewriting R5 to read: In the event that an operating issue cannot be confirmed, each Reliability Coordinator shall operate as though the problem exists.
Yes and No
15.1 - In M1, delete "System Operator" and "for real-time use". 15.2 - Modify the measures to be consistent with changes requested in R1, R2, R4, R4.1 and R5.
Yes and No
16.1 - In R2, severe should be "no action was taken by the RC". 16.2 - In R5, severe should also include that the RC failed to operate as though the problem existed. 16.3 - Modify the VSLs to be consistent with changes requested in R1, R2, R4, R4.1 and R5.
Yes
17.1 - We agree with the recommendation to retire IRO-015-2
Yes
18.1 - We agree with the recommendation to retire IRO-016-2
19.1 - We suggest the effective date for the retirement of R5 (NERC Net Security Policy) in the COM-001-2 Standard should be effective immediately upon regulatory approval. As written, the Policy is unenforceable, contains no measures and is not germane to BES Reliability
Individual
Jay Seitz
US Bureau of Reclamation
No
Purpose Distribution Providers and Generator Operators were added to the applicability; the Purpose should be revised to reflect that.
Yes
 
Yes
 
No
Purpose Since Generator Operators were deleted from the applicability; the Purpose should be revised to reflect that and include Reliability Coordinators. The language is somewhat redundant, recommend it be simplified to “To ensure Balancing Authorities, Reliability Coordinators, and Transmission Operators communicate in an effective manner.”
Yes
 
Yes
 
No
R4. and R5. Both of these Requirements use the phrase “without intentional delay” to describe the urgency of the notification to impacted entities. In both requirements we recommend the language be changed from “notify, without intentional delay” to “immediately notify”.
No
M4. and M5. In both Measures, recommend “without intentional delay” be changed as described above for R4. and R5.
Yes
 
No
R2. This requirement provides authority to the Reliability Coordinator to veto planned outages and approve planned maintenance to “analysis tools”. It is not clear in this standard what these “analysis tools” are. Per FERC Order 693, NERC was to identify a minimum set of analysis tools and the task was assigned to the Real-Time Tools Best Practices Task Force. Until the tools are identified, it is premature to insert a placeholder in a mandatory standard; this also applies to the violation severity levels table.
No
M2 again "analysis tools" have not been identified.
No
Until the tools are identified, it is premature to insert a placeholder in a mandatory standard; this also applies to the violation severity levels table.
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
 
Group
PJM Interconnection
Patrick Brown
PJM Intercinnection
Yes
We agree with the revisions, but recommend adding applicability to Distribution Providers and Generator Operators for data retention requirements.
Yes
M4 should be revised to reflect that each Distribution Provider and Generation Operator has evidence demonstrating the functionality of telecommunications facilities with the TOP and BA for the exchange of interconnection and operating information.
No
Recommend the following VSLs for R1: Proposed Lower VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator failed to operationally test alternative telecommunications every three months on at least one occasion. Proposed Moderate VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator failed to operationally test alternative telecommunications every three months on two separate occasions. Proposed High VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator failed to operationally test alternative telecommunications every three months on three separate occasions. Proposed Severe VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator failed to operationally test alternative telecommunications every three months on more than three separate occasions. Recommend the following VSLs for R2: Proposed Lower VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator failed to operationally test alternative telecommunications every three months on at least one occasion. Proposed Moderate VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator failed to operationally test alternative telecommunications every three months on two separate occasions. Proposed High VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator failed to operationally test alternative telecommunications every three months on three separate occasions. Proposed Severe VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator failed to operationally test alternative telecommunications every three months on more than three separate occasions. Recommend the following VSLs for R4: Proposed High VSL: The Responsible Entity failed to establish telecommunications with either their Balancing Authority or Transmission Operator for the exchange of Interconnection and operating information. Proposed Severe VSL: The Responsible Entity failed to establish telecommunications with their Balancing Authority and Transmission Operator for the exchange of Interconnection and operating information.
Yes
We note that this requirement really is "3-part communication" and will be moved to the new communications standard, COM-003-1.
Yes
 
No
The word "clear" is redundantly used in the High and Severe colums. Recommend that "Moderate" should read: "The Responsible Entity provided a directive in a clear, concise and definitive manner, but did not require the recipient to repeat the directive back to the originator." Recommend that "High" should read: "The Responsible Entity failed to issue a directive in a clear, concise and definitive manner while ensuring the recipient of the directive repeated the information back correctly with acknowledgment by the originator that the response was correct." Recommend that "Severe" should read: "The Responsible Entity failed on more than one occasion to issue a directive in a clear, concise and definitive manner while ensuring the recipient of the directive repeated the information back correctly with acknowledgment by the originator that the response was correct."
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
 
Group
#2 Standards Interface Subcommittee/Compliance Elements Development Resource Pool
John Blazekovich
Commonwealth Edison Co.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Standard – COM-001-2 Telecommunications Requirement 1: Each Reliability Coordinator, Transmission Operator, and Balancing Authority shall operationally test, on a quarterly basis at a minimum, alternative telecommunications facilities to ensure the availability of their use when normal telecommunications facilities fail. Proposed Measure: Each Reliability Coordinator, Transmission Operator, and Balancing Authority shall provide evidence that it operationally tested, on a quarterly basis at a minimum, alternative telecommunications facilities to ensure the availability of their use when normal telecommunications facilities fail. Attributes of the requirement Binary Quarterly operational tests of alternate telecommunications Timing X Omission Communication Quality X Other SDT Proposed Lower VSL: The Reliability Coordinator, Transmission Operator, or Balancing Authority failed to operationally test within the last quarter. CEDRP Proposed Lower VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator performed operational testing of alternative telecommunications, but did not perform a test in one of the previous four quarters. SDT Proposed Moderate VSL: The Reliability Coordinator, Transmission Operator, or Balancing Authority failed to operationally test within the last 2 quarters. CEDRP Proposed Moderate VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator performed operational testing of alternative telecommunications, but did not perform a test in two of the previous four quarters. SDT Proposed High VSL: The Reliability Coordinator, Transmission Operator, or Balancing Authority failed to operationally test within the last 3 quarters. CEDRP Proposed High VSL: The Reliability Coordinator, Balancing Authority or Transmission Operator performed operational testing of alternative telecommunications, but did not perform a test in three of the previous four quarters. SDT Proposed Severe VSL: The Reliability Coordinator, Transmission Operator, or Balancing Authority failed to operationally test within the last 4 quarters. CEDRP Proposed Severe VSL: The Responsible Entity failed to operationally test alternative telecommunications every quarter on more than three separate occasions (i.e. more than any three different quarters). FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? No 2. Is the VSL assignment a binary requirement? Yes 3. Is it truly a “binary” requirement? Yes 4. If yes, is the VSL assignment consistent with other binary requirement assignments? Yes 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? Yes 6. Does the VSL redefine or undermine the stated requirement? No 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Yes Standard – COM-001-2 Telecommunications Requirement 2: Each Reliability Coordinator, Transmission Operator and Balancing Authority shall notify impacted entities of the failure of its normal telecommunications facilities, and shall verify that alternate means of telecommunications are functional. Proposed Measure: Each Reliability Coordinator, Transmission Operator and Balancing Authority shall provide evidence that it notified impacted entities of failure of their normal telecommunications facilities, and verified the alternate means of telecommunications were functional. Attributes of the requirement Binary Timing Notify impacted entities and verify functionality of alternate telecommunications Omission Communication X Quality Other - Test X Discussion - This requirement needs to be re-written to be more clearly define who the entities are that are “impacted.” The key attributes appear to be notification of ALL (communication) impacted entities (possible omission if some, but not all are not notified). The requirement does not give any guidance on the “verification” side – this is a problem, one entity can interpret that to mean “we looked and it was working”, another may be to verify with all impacted entities that alternate communication is working. We suggest this requirement needs a little more clarification. The CEDRP does not feel it can write a valid VSL for this requirement as currently worded. SDT Proposed Lower VSL: The Reliability Coordinator, Transmission Operator or Balancing Authority notified all impacted entities of the failure of their normal telecommunications facilities, but failed to verify the alternate means of telecommunications are functional. CEDRP Proposed Lower VSL: See Discussion SDT Proposed Moderate VSL: The Reliability Coordinator, Transmission Operator or Balancing Authority notified some, but not all, impacted entities of the failure of their normal telecommunications facilities, and failed to verify the alternate means of telecommunications are functional. CEDRP Proposed Moderate VSL: See Discussion SDT Proposed High VSL: N/A CEDRP Proposed High VSL: See Discussion SDT Proposed Severe VSL: The Reliability Coordinator, Transmission Operator or Balancing Authority failed to notify any impacted entities of the failure of their normal telecommunications facilities, and failed verify the alternate means of telecommunications are functional. CEDRP Proposed Severe VSL: See Discussion FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? No 2. Is the VSL assignment a binary requirement? No 3. Is it truly a “binary” requirement? No 4. If yes, is the VSL assignment consistent with other binary requirement assignments? N/A 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? Yes 6. Does the VSL redefine or undermine the stated requirement? No 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Yes Standard – COM-001-2 Telecommunications Requirement 3: Unless agreed to otherwise, each Reliability Coordinator, Transmission Operator, Balancing Authority, Generator Operator and Distribution Provider shall use English as the language for all inter-entity Bulk Electric System (BES) reliability communications between and among operating personnel responsible for the real-time generation control and operation of the interconnected BES. Transmission Operators and Balancing Authorities may use an alternate language for internal operations. Proposed Measure: The Reliability Coordinator, Transmission Operator or Balancing Authority shall have and provide upon request evidence that could include, but is not limited to operator logs, voice recordings or transcripts of voice recordings, electronic communications, or equivalent, that will be used to determine that personnel used English as the language for all inter-entity BES reliability communications between and among operating personnel responsible for the real-time generation control and operation of the interconnected BES. Attributes of the requirement Binary Use English for real-time communications unless agreed to otherwise. NOTE: OK with this as is because the requirement and VSLs have been re-written, will be removed from this standard shortly, and included in the new COM-003-1 standard. Timing Omission Communication X Quality Other SDT Proposed Lower VSL: N/A CEDRP Proposed Lower VSL: No change SDT Proposed Moderate VSL: N/A CEDRP Proposed Moderate VSL: No change SDT Proposed High VSL: N/A CEDRP Proposed High VSL: No change SDT Proposed Severe VSL: The responsible entity failed to provide evidence of concurrence to use a language other than English for all communications between and among operating personnel responsible for the real-time generation control and operation of the interconnected Bulk Electric System. CEDRP Proposed Severe VSL: The Responsible Entity failed to provide evidence of the concurrence to use a language other than English for all communications between and among operating personnel responsible for the real-time generation control and operation of the interconnected Bulk Electric System. FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? No 2. Is the VSL assignment a binary requirement? Yes 3. Is it truly a “binary” requirement? Yes 4. If yes, is the VSL assignment consistent with other binary requirement assignments? It’s a little inflated as being Severe 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? It’s OK for the interim 6. Does the VSL redefine or undermine the stated requirement? No 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Yes Standard – COM-001-2 Telecommunications Requirement 4: Each Distribution Provider and Generation Operator shall have telecommunications facilities with its Transmission Operator and Balancing Authority for the exchange of Interconnection and operating information. Proposed Measure: Each Distribution Provider and Generation Operator has telecommunications facilities with its Transmission Operator and Balancing Authority for the exchange of Interconnection and operating information. Attributes of the requirement Binary “has” telecomm with TOP and BA Timing Omission Communication X Quality Other Discussion – Telecommunication Facilities is ambiguous and is not included in the NERC glossary of terms – the CEDRP recommend deleting the word “facilities” from the requirement and measure and leaving it just as “telecommunications” with its TOP and BA . SDT Proposed Lower VSL: N/A CEDRP Proposed Lower VSL: No change SDT Proposed Moderate VSL: N/A CEDRP Proposed Moderate VSL: No change SDT Proposed High VSL: N/A CEDRP Proposed High VSL: The Responsible Entity failed to establish telecommunications with either their Balancing Authority OR Transmission Operator for the exchange of Interconnection and operating information. SDT Proposed Severe VSL: The Distribution Provider or Generation Operator failed to have telecommunications facilities with its Transmission Operator and Balancing Authority CEDRP Proposed Severe VSL: The Responsible Entity failed to establish telecommunications with their Balancing Authority AND Transmission Operator for the exchange of Interconnection and operating information. FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? No 2. Is the VSL assignment a binary requirement? Mostly 3. Is it truly a “binary” requirement? Mostly 4. If yes, is the VSL assignment consistent with other binary requirement assignments? Yes 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? Yes, considering the wording of the requirement as written. More specifically, the word “have” as used in the requirement is a bit vague. A better choice could have been, “established and maintains.” 6. Does the VSL redefine or undermine the stated requirement? No 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Yes Standard: COM-002-3 Communications and Coordination Requirement 1: Each Reliability Coordinator, Transmission Operator, and Balancing Authority shall issue directives in a clear, concise, and definitive manner; shall ensure the recipient of the directive repeats the information back correctly; and shall acknowledge the response as correct or repeat the original statement to resolve any misunderstandings. Proposed Measure: Each Reliability Coordinator, Transmission Operator, and Balancing Authority shall have evidence such as voice recordings or transcripts of voice recordings to show that it issued directives in a clear, concise, and definitive manner; ensured the recipient of the directive repeated the information back correctly; and acknowledged the response as correct or repeated the original statement to resolve any misunderstandings. Attributes of the requirement: Binary Timing Omission Communication X Quality X Other SDT Proposed Lower VSL: None CEDRP Proposed Lower VSL: No Comment SDT Proposed Moderate VSL: The responsible entity provided a clear directive in a clear, concise and definitive manner and required the recipient to repeat the directive, but did not acknowledge the recipient was correct in the repeated directive. CEDRP Proposed Moderate VSL: No comment SDT Proposed High VSL: The responsible entity provided a clear directive in a clear, concise and definitive manner, but did not require the recipient to repeat the directive. CEDRP Proposed High VSL: No comment SDT Proposed Severe VSL: The responsible entity failed to provide a clear directive in a clear, concise and definitive manner when required. CEDRP Proposed Severe VSL: No comment FERC Guidance for VSLs 1. Will the VSL assignment signal entities that less compliance than has been historically achieved is condoned? No 2. Is the VSL assignment a binary requirement? No 3. Is it truly a “binary” requirement? No 4. If yes, is the VSL assignment consistent with other binary requirement assignments? 5. Is the VSL language clear & measurable (ambiguity removed)? If no, does the requirement or measure need to be revised? Yes 6. Does the VSL redefine or undermine the stated requirement? No 7. Is the VSL based on a single violation of the requirement (not multiple violations)? Yes and No (Severe is for multiple occasions of not issuing directives per the requirement).
Individual
Timothy C. (TC) Thomas
Progress Energy Carolinas
No
R1- The proposed requirement R1 as stated is too broad in reference to "telecommunications facilities". It is unclear as to whether it is intending to specify facilities and equipment which provide VOICE/VERBAL communications, or ELECTRONIC MESSAGING notifications systems, or DATA EXCHANGE links or all of these. Please clarify either within the requirement or within the Glossary of Terms which accompany the full standards set. R2 - The proposed requirement R2 as stated is too broad in reference to "telecommunications facilities". It is unclear as to whether it is intending to specify facilities and equipment which provide VOICE/VERBAL communications, or ELECTRONIC MESSAGING notifications systems, or DATA EXCHANGE links or all of these. Please clarify either within the requirement or within the Glossary of Terms which accompany the full standards set. R4 - The proposed requirement R4 as stated is too broad in reference to "telecommunications facilities". It is unclear as to whether it is intending to specify facilities and equipment which provide VOICE/VERBAL communications, or ELECTRONIC MESSAGING notifications systems, or DATA EXCHANGE links or all of these. Please clarify either within the requirement or within the Glossary of Terms which accompany the full standards set.
No
M1 - The proposed measure M1 as stated is too broad in reference to "telecommunications facilities". It is unclear as to whether it is intending to specify facilities and equipment which provide VOICE/VERBAL communications, or ELECTRONIC MESSAGING notifications systems, or DATA EXCHANGE links or all of these. Please clarify either within the requirement or within the Glossary of Terms which accompany the full standards set. M2 - The proposed measure M2 as stated is too broad in reference to "telecommunications facilities". It is unclear as to whether it is intending to specify facilities and equipment which provide VOICE/VERBAL communications, or ELECTRONIC MESSAGING notifications systems, or DATA EXCHANGE links or all of these. Please clarify either within the requirement or within the Glossary of Terms which accompany the full standards set. M4 - The proposed measure M4 as stated is too broad in reference to "telecommunications facilities". It is unclear as to whether it is intending to specify facilities and equipment which provide VOICE/VERBAL communications, or ELECTRONIC MESSAGING notifications systems, or DATA EXCHANGE links or all of these. Please clarify either within the requirement or within the Glossary of Terms which accompany the full standards set.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Group
FirstEnergy
Sam Ciccone
FirstEnergy Corp.
No
Purpose - The purpose does not include the GOP and DP entities. It may be better if the purpose was written more generally as "To ensure adequate and reliable telecommunications facilities for the exchange of Interconnection and operating information necessary to maintain BES reliability". R1 - This requirement makes no distinction between data and voice communications facilities and assumes a designated primary and backup facility configuration such that the backup communications systems are not used regularly. This may be an accurate assumption for data communications; however voice communications may be different. Today many organizations use voice communications systems that allow the system to choose the communication path each time a call is placed. This design ensures that all communications paths are tested regularly in day-to-day use. However, the design of these systems makes it difficult, if not impossible, to substantiate that a functional test of the circuitry has been performed. This requirement should be broken into two requirements. The first should cover data circuitry and the second should cover voice circuitry. This will allow the drafting team to address the inherent differences in these two methods of communications. Lastly, the requirements need to be much more specific concerning the criticality of the facilities to be tested to improve the measurability of the standard. The drafting team dropped the phrase "for the exchange of Interconnection and operating data" from the standard requirement. This deletion appears to open the application of this standard to virtually every communication path used by an RC, BA, TOP whether or not it is used for communicating real-time operating information or not. We do not believe this was the intention of the drafting team and suggest this phrase be reinserted or another one added that limits applicability to only those communication paths that support the real-time reliability of the bulk electric system. R2 - It is not clear who the "impacted entities" would be in this requirement. The SDT should consider specifying these entities. R3 - The last sentence of this requirement should be deleted. It is not a requirement, it does not add clarity, and the first sentence is very specific as to the communications covered by the requirement. R4 - This requirement makes no distinction between data and voice communications facilities and assumes a designated primary and backup facility configuration such that the backup communications systems are not used regularly. This may be an accurate assumption for data communications; however voice communications may be different. Today many organizations use voice communications systems that allow the system to choose the communication path each time a call is placed. This design ensures that all communications paths are tested regularly in day-to-day use. However, the design of these systems makes it difficult, if not impossible, to substantiate that a functional test of the circuitry has been performed. This requirement should be broken into two requirements. The first should cover data circuitry and the second should cover voice circuitry. This will allow the drafting team to address the inherent differences in these two methods of communication.
No
The measures should be modified per our suggested modifications in question 1.
No
The VSL should be modified per our suggested modifications in question 1. R1 VSL - The statement in the VSL that the responsible entity did not "operationally test" is too broad. It should be more specific with the language used in the requirement.
No
Purpose - The GOP is still shown in the purpose statement although it was removed from the applicability. Also, it may be better if the purpose was written more generally as "To ensure adequate communications capabilities for addressing real-time emergency conditions and ensure communications by operating personnel are effective to maintain BES reliability". Applicability - In the SDT's document "Scope of Work Assigned to the Reliability Coordination Standard Drafting Team", the team decided to not include the FERC directive to include the DP in the applicability with the following reasoning "The proposed revisions do not include the DP entity because they are not applicable." We would like clarification on this. R1 - It does not appear that the implementation plan addresses the FERC direction to consider comments from Santa Clara, FirstEnergy, and Six Cities per 693 par. 539 regarding staffing requirements. Santa Clara asks that these requirements apply "only to operating staff available on site at all times or includes repair personnel who are available only on an on-call basis". FirstEnergy asks that the "term [staffed] should not require a physical presence at all facilities at all times because some units, such as peaking units, are not staffed 24 hours a day". FirstEnergy also suggest "because nuclear units are already subject to communications requirements in their operating procedures, their compliance with NRC operating procedures should be deemed in compliance with the NERC Reliability Standards". Six Cities "states that, to avoid unnecessary staffing burdens, particularly for smaller entities, the Commission should direct NERC to clarify COM-002-2 by providing that identification of an emergency contact person on call to respond to real-time emergency conditions will constitute adequate compliance". R1 - Just as an FYI, with regard to the proposed replacement requirement statement in the implementation plan: "TOP-005-1, R1 and R3 require adequate telecommunications for BAs and TOPs to provide each other with operating data as well as providing data to the RC", per recently stakeholder approved ballots, R1 of TOP-005-1 has been retired and now covered in new standard IRO-010-1. R1.1 - The existing requirement includes "through predetermined communication paths of any condition that could threaten the reliability of its area or when firm load shedding is anticipated". The proposed replacement requirements do not address the need for "predetermined communication paths".
No
The measures should be modified if our comments in question 4 result in changes to the proposed requirements.
No
The VSL should be modified if our comments in question 4 result in changes to the proposed requirements.
No
R3 - should be a sub requirement of R2. These two requirements are sequential in nature and should be measured at the same time. The VRFs and Time Horizons are the same for both requirements lending to their combination into a requirement with a sub requirement. In the VSL for R2, an entity is being penalized with a high severity level for not completely following an RC directive even though it violated safety, equipment, statutory, or regulatory requirements. Measuring R2 and R3 at the same time allows for the process to complete prior to the measurement taking place. R3 - The "or" between "Distribution Provider" and "Purchasing-Selling Entity" should be replaced with an "and". R4 - Should be revised by adding the phrase "of the expected or actual threat" to the end of the requirement to add clarity. Existing R7 requirement - This requirement is proposed for retirement because it is redundant with IRO-014-1 R1. However, it is not clear how the existing requirement to "have clear, comprehensive coordination agreements with adjacent RCs to ensure that SOL or IROL violation mitigation requiring actions in adjacent RC areas are coordinated" is covered in IRO-014-1 R1. IRO-014-1 R1 requires agreements for coordination of actions between RCs to support Interconnection reliability, but it does not specifically require "clear" and "comprehensive" agreements to mitigate SOL or IROL violations. IRO-014-1 only vaguely covers the existing requirement R7 of IRO-001-1.
No
M2 - The word "intentional" should be added between "without" and "delay".
No
R2 VSL - The Severe VSL should include after the word directive: "that would not violate safety, equipment, statutory or regulatory requirements".
No
R2 - As written, this requirement does not clearly define the scope of the authority of the Reliability Coordinator over analysis tools. Is it the intent of the drafting team to give the RC authority over analysis tools owned and operated by the RC. Is it the intent of the drafting team to give the RC authority over the analysis tools owned and operated by the BA, TOP, GOP, etc.? Are the tools intended to be the real-time (EMS) or the off-line engineering planning analysis tools or any analysis tool used in real-time. Does this include the analysis tools used by field personnel? This requirement should be revised to specify exactly the analysis tools under the authority of the Reliability Coordinator.
No
The measures should be modified per our suggested modifications in question 10.
No
The VSL should be modified per our suggested modifications in question 10.
Yes
 
No
R1 - Should be revised as follows to improve readability and clarity: R1.3 - Add "Exchanging" before "Planned" R1.4 - Add "Control of voltage" at the beginning of the requirement and delete "for voltage control" at the end of the requirement. Add a new R1.7 as follows: "A process for resolution of the disagreement covered by R6 of this standard."
No
The measures should be modified per our suggested modifications in question 14.
No
The VSL should be modified per our suggested modifications in question 14.
Yes
 
Yes
 
 
Group
Bonneville Power Administration
Denise Koehn
Transmission Reliability Program
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
 
Individual
Greg Rowland
Duke Energy
No
Purpose - The purpose statement does not read very well. It either needs another sentence or changes to the current sentence. The purpose of the standard is to assure proper communications, not to suggest entities need proper communications as currently written. Suggest changing to, “To assure each Reliability Coordinator, Transmission Operator and Balancing Authority develops and maintains…. Requirement R1 - What is the definition of "alternative telecommunications facilities"? Is there another requirement somewhere to have alternative telecommunications facilities – or is this a new requirement being introduced by this standard? What is the relationship, if any, between "alternative telecommunications facilities" and EOP-008-1? What is the requirement for maintaining and testing "alternative telecommunications facilities"; what does “operationally test” mean? Just because an alternative facility works when it is tested does not mean it will work during an actual failure of the primary system. Furthermore, what do we do if the “test” fails- are we still compliant? The word “ensure” needs to be changed to “assure”. Requirement R2 - What does "impacted entity" mean? Requirement R3 - Why can’t others use alternate language – this limits alternate language to just TOPs and BAs internal operations. TOs, GOPs, and others may want to use alternate language internally. Need to define language to be used with and between other relationships – BA to PSE, as an example. Is this a reliability issue or a certification issue? Simply state that: “Entities may use alternative language for internal operations”. This will allow any entity to use alternative language for internal operations. The inclusion of TSPs, LSEs, and PSEs in IRO-001-2 indicates the need to include these functions in the COM-001-2 applicability and requirements concerning the use of English as the approved language. Requirement R4 - Remove R4 and add DP and GO, as well as all of the other entities listed in IRO-001-2, to R1 thru R3.
No
General comments - Not using consistent language regarding “provide evidence” and “shall have and provide upon request evidence”. Also need to add corresponding requirement number after each measure. Measure M1 - Just because an alternate facility works when it is tested does not mean it will work during an actual failure of the primary system. - what do we do if the “test” fails- are we complaint? Clarify that the requirement and measure is to “test” not "to test successfully". We may test and find that something does not work as expected.
No
VSL for Requirement R1 - The VSL for R1 seems to imply that an operational test needs to have been performed in the last 90 days – this is read in conjunction with the data retention requirements. Need to clarify in the requirement how “quarter basis” is defined - is it the calendar quarter, or a rolling 90 days? In addition, the VSLs for Requirement R1 appear to violate NERC guidlelines, since the Moderate, High and Severe VSLs are based upon cumulative violations of the Lower VSL.
No
Requirement R1 - As defined by Merriam Webster, the use of the word “ensure” implies virtual guarantee <the government has ensured the safety of the refugees>; while the use of the alternative word “assure” implies the removal of doubt and suspense from a person's mind. We suggest that “assure” is more appropriate than “ensure” in this context in the standards. The use of words like “clear, concise, and definitive manner” is subject to interpretation. This same language is used in the VSLs. Depending on the interpretation of this phrase, an entity could be found to be in a “Severe” violation level. The issuer of the directive should not be subject to non-compliance if the recipient of the directive refuses to repeat back. Need to add a requirement, measure, and VSL that clarifies that the recipient of a directive is obliged to perform their portion of a repeat-back. The inclusion of TSPs, LSEs, and PSEs in IRO-001-2 indicates the need to include these functions in the COM-002-3 requirement concerning repeat-backs. What is a “directive”? The regional compliance processes are having difficulty in auditing this existing standard due to lack of clarity of what constitutes a directive. "Directive" should be defined as being associated with real-time operational emergency conditions, and not ordinary day-to-day communications. Otherwise a VRF of High is not warranted.
No
The use of words like “clear, concise, and definitive manner” is subject to interpretation. The issuer of the directive should not be subject to non-compliance if the recipient of the directive refuses to repeat back. Need to add a requirement, measure, and VSL that clarifies that the recipient of a directive is obliged to perform their portion of a repeat-back.
No
The use of words like “clear, concise, and definitive manner” is subject to interpretation. The issuer of the directive should not be subject to non-compliance if the recipient of the directive refuses to repeat back. Need to add a requirement, measure, and VSL that clarifies that the recipient of a directive is obliged to perform their portion of a repeat-back.
No
Requirement R1 - What happens if the RC failed to recognize that such an event was happening as opposed to failed to take action. Is this intended to cover both scenarios? The term “Adverse Reliability Impacts” is being changed and is listed in the associated Implementation Plan. The revision development of this definition needs to go thru Due Process. The inclusion of TSPs, LSEs, and PSEs here indicates the need to include these functions in the COM-001-2 requirements concerning the use of English as the approved language. In addition, this also indicates the need for all of these listed entities to be included in COM-002-3 requirements concerning repeat-backs. The RC, TOP, and BA should not be placed in a possible non-complaint state because the counter party refuses a repeat-back AND these requirements are not applicable to the counter party. Requirement R2 - The language in the Moderate VSL of R2 recognizes another potential reason for delay in execution of a directive. Requirement 2 of the Standards needs to be modified to also recognize this potential. Requirements R2 and R3 - Clarify that entities are obligated to take action and confirm directives only from their Reliability Coordinators, not from any Reliability Coordinator. Requirements R2, R3, R4, R5 - Inconsistent use of “timing” words in the standards – "without intentional delay" and "immediately". Suggest deleting these words due to the difficulty of determining compliance. Requirement R4 - The term “Adverse Reliability Impacts” is being changed and is listed in the associated Implementation Plan. The revision of this definition needs to go through Due Process. Requirement R5 - The VRF should be "Lower" instead of "High" since the notification is that the threat has been mitigated. Also, the term “Adverse Reliability Impacts” is being changed and is listed in the associated Implementation Plan. The revision of this definition needs to go through Due Process.
No
Measures M2, M4 and M5 use the terms "without delay" and "without intentional delay". Suggest deleting these words due to the difficulty of determining compliance. The term “Adverse Reliability Impacts” is being changed and is listed in the associated Implementation Plan. The revision of this definition needs to go through Due Process.
No
The language in R1 of the VSL is not consistent with the requirements and measures in the standard. The VSL needs to recognize that the RC may EITHER act or give direction to others to act. The term “Adverse Reliability Impacts” is being changed and is listed in the associated Implementation Plan. The revision of this definition needs to go through Due Process. The language in R2 of the VSL places an entity in Moderate or High violation level even if failure is “allowed” in the standard; i.e. failure to act is due to violation of safety, regulatory, statutory requirements. The language in R2 of the VSL recognizes another potential reason for delay in execution of a directive. Requirement R2 of the Standard needs to be modified to also recognize this potential.
No
Requirement R1 - This requirement is in the wrong standard – this is a Facilities standard. This requirement belongs in another standard. Question: Is there a requirement in another standard that compels the TOPS, BAs, etc to provide the requested data? Requirement R2 - Need to clarify whose analysis tools (I assume it is the RCs analysis tools, not the analysis tools of another entity) and planned maintenance to what – is it tools, facilities, transmission, generation, etc. Depending on the answer above, this requirement is in the wrong standard – this is a Facilities standard. This requirement belongs in another standard. Question: Where is the Requirement for the RC to have analysis tools? It appears that the Requirement the RC has analysis tools have been removed in the revisions to the standard.
No
See response to Question #12 above. If the requirements are moved to another standard, the measures aren't needed here.
No
R1 VSL - As a general comment, this VSL is unclear and would be difficult to audit. This VSL uses subjective terms like “material impact” and “minimal impact”. These terms are not used in the associated requirement or measure and should be removed from the VSL. This VSL uses terms like “majority, but not all”; “some, but less than a majority” which provides an opportunity for a subjective review by Compliance as to what a complete listing of data requirements should be. This term is not used in the Requirements or Measures and should be removed from the VSL. This VSL introduces a concept, data the RC needs for “ … administrative purposes, such as data reporting …”. This concept is not included in the Requirements or Measures portions of the Standard and should be removed from the VSL. This VSL should be written to simply assess whether the RC has made determination of what its data needs are and whether those needs have been communicated to the entities in the footprint. R2 VSL - This VSL clarifies the questions posed above regarding what the RC needs approval rights over. R2 needs to be modified to include this clarity. This VSL needs to clarify that the RC approval rights are for the RC's tools, not tools of other entities. The Severe level of this VSL needs to be re-written along the lines of: The RC does not have approval rights for planned maintenance or outages to its analysis tools.
Yes
 
No
R1 and R2 - The word "impacted" tends to broaden the requirements to have procedures, processes and plans in place with each RC within the RC's Interconnection. We suggest the phrasing should be tightened up to convey the original meaning that the team intended. For example, does the team intend for the FRCC RC to have an agreement with the PJM or MISO RC? We suggest bringing R6 under R1 as subrequirement R1.7 and rewrite it as follows: R1 - The Dispute Resolution process will be followed when the Reliability Coordinator issuing a mitigation plan and the Reliability Coordinator(s) receiving a mitigation plan disagree on the proper steps to be taken. We suggest deleting R4.1 and adding a second sentence to R4: The frequency of these communications shall be at least weekly. R4: The word "impacted" makes it sound like these calls are only to be made when problems are expected or are occurring. If this requirement is intended more for operational awareness calls (such as the daily SERC RC call), then the word "impacted" needs to be changed to "contiguous". We suggest rewriting R5 to read: In the event that an operating issue cannot be confirmed, each Reliability Coordinator shall operate as though the problem exists.
No
See comment #14 above. Also, Measure M5 is inconsistent with Requirement R5. It should mirror the requirement. Also, need to add the requirement number at the end of each Measure.
No
See comments #14 and #15 above - VSLs need to be revised to correspond to the revised Requirements and Measures.
Yes
 
No
See comment #14 above regarding re-write needed for Requirement R6 of IRO-014-2.
 
Individual
Thad Ness
AEP
No
A precise definition of telecommunications facilities needs to be established in this standard. R2 needs to be clarified regarding impacted utilities. FERC Order 693 suggests that this standard should apply Distribution Providers (DP) along with Generation Operators (GOP). AEP acknowledges that there needs to be some level of coordination and communication between DP’s and other function model entities; however, the requirements, as applied to the DP, for telecommunications with the TOP and BA might not address the current communication paths adequately. Today, the DP usually does not communicate with the RTO (performing the BA and/or TOP function), but the DP could either communicate directly or through a joint action agency to the IOU that may serve as the TO (or maybe the TOP). As this draft is written the DP’s would be required to have telecommunication facilities with the RTO in this scenario. There will likely be many exceptions to the rule that the requirements and measures create when applied to the DP. We ask that the drafting team consider the applicability, some of the current channels of communications, and options for addressing the FERC comments without creating telecommunication paths that do not make practical sense.
No
M2 needs to be clarified regarding impacted functions.
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
Yes
 
 
Individual
Chris de Graffenried
Consolidated Edison Co. of NY, Inc.
 
 
 
 
 
 
Yes and No
Wording in question: R.2/M.2 Each … Load-Serving Entity, or Purchasing-Selling Entity shall have evidence that it acted without intentional delay to comply with the Reliability Coordinator's directives. R.3/M.3 Each … Load-Serving Entity, or Purchasing-Selling Entity shall have evidence that it confirmed its ability to comply with the Reliability Coordinator's directives. [1] Question: Is this wording absolutely necessary? And then, is it sufficient, if needed? Comment: First, we would question whether there is a specific need to include this wording. Is the IRO-001 Reliability Standard sufficient without it? [2] Question: Is this wording unambiguous? Comment: The wording seems somewhat vague and ambiguous. Analysis: The wording appears to establish performance standards ("without intentional delay", “shall immediately confirm”) and evidentiary requirements (“evidence that it acted” or “evidence that it confirmed”), but without using pre-existing defined terms, establishing new defined terms, or defining these terms as used in context. [3] Intentional vs. Unintentional, Valid Intentional vs. Inappropriate Intentional? How does one differentiate between intentional and unintentional delay? When is and how much delay is valid or inappropriate? Isn’t some intentional delay necessary to ensure that the other parts of the requirement being are met, e.g., “… unless such actions would violate safety, equipment, or regulatory or statutory requirements”? Mightn’t some acceptable amount of valid intentional delay be necessary to insure that any such RC directive and entity action would not in fact violate these safety, equipment, or regulatory or statutory requirements? [4] What is the timeliness standard? How are the terms “without delay” and “immediately conform” defined? What standard commercial measures would apply, e.g., “reasonably efforts” vs. “best efforts?” Are these terms measured in units of time (seconds or minutes) or in units of performance quality? Does a poorly considered “immediate” reply meet the standard, while a well considered reply, which is intentionally delayed, yet still appropriate, fail to meet this standard? Is that the best outcome? [5] What is this Evidentiary Standard? Is the sought-after “evidence” sufficiently well defined, e.g., phone logs, computer e-mail, control center computer logs, hand-written operator journals, etc.? What form of evidence is necessary and sufficient to demonstrate that the entity met this evidentiary standard? How is failure to meet this uncertain standard measured, judged and penalized?
Yes and No
[Comments repeated for Measures] Wording in question: R.2/M.2 Each … Load-Serving Entity, or Purchasing-Selling Entity shall have evidence that it acted without intentional delay to comply with the Reliability Coordinator's directives. R.3/M.3 Each … Load-Serving Entity, or Purchasing-Selling Entity shall have evidence that it confirmed its ability to comply with the Reliability Coordinator's directives. [1] Question: Is this wording absolutely necessary? And then, is it sufficient, if needed? Comment: First, we would question whether there is a specific need to include this wording. Is the IRO-001 Reliability Standard sufficient without it? [2] Question: Is this wording unambiguous? Comment: The wording seems somewhat vague and ambiguous. Analysis: The wording appears to establish performance standards ("without intentional delay", “shall immediately confirm”) and evidentiary requirements (“evidence that it acted” or “evidence that it confirmed”), but without using pre-existing defined terms, establishing new defined terms, or defining these terms as used in context. [3] Intentional vs. Unintentional, Valid Intentional vs. Inappropriate Intentional? How does one differentiate between intentional and unintentional delay? When is and how much delay is valid or inappropriate? Isn’t some intentional delay necessary to ensure that the other parts of the requirement being are met, e.g., “… unless such actions would violate safety, equipment, or regulatory or statutory requirements”? Mightn’t some acceptable amount of valid intentional delay be necessary to insure that any such RC directive and entity action would not in fact violate these safety, equipment, or regulatory or statutory requirements? [4] What is the timeliness standard? How are the terms “without delay” and “immediately conform” defined? What standard commercial measures would apply, e.g., “reasonably efforts” vs. “best efforts?” Are these terms measured in units of time (seconds or minutes) or in units of performance quality? Does a poorly considered “immediate” reply meet the standard, while a well considered reply, which is intentionally delayed, yet still appropriate, fail to meet this standard? Is that the best outcome? [5] What is this Evidentiary Standard? Is the sought-after “evidence” sufficiently well defined, e.g., phone logs, computer e-mail, control center computer logs, hand-written operator journals, etc.? What form of evidence is necessary and sufficient to demonstrate that the entity met this evidentiary standard? How is failure to meet this uncertain standard measured, judged and penalized?
Yes and No
Agreement uncertain, subject to further clarification of Requirements and Measures performance standards and definitions (see our comments on Requirements and Measures). Without clearer definitions, e.g., for "immediate," or any allowance for appropriate intentional delay, it is not entirely clear that the VSL's comport with the ultimate meaning, intent and needed wording to be incorporated into the Requirements and Measures. Why would failure to fully comply, when precluded by conditions specifically allowed in the standard, necessarily be a problem, so long as the RC received timely notice, however defined?
 
 
 
 
 
 
 
 
 
 
Individual
Kevin Koloini
Buckeye Power, Inc.
Yes and No
What constitutes "telecommunications facilities"?
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
Yes and No
abstain
 
Individual
Jason Shaver
American Transmission Company
Yes and No
If some language is clarified, we support the revisions. R2 states that "Each TO shall notify impacted entities of the failure of its normal telecommunications facilities…". If a phone line goes down and an alternate phone line is used, it is an excessive requirement to notify the impacted entities when there is no impact upon communication or the BES. The wording should be clear that notification is only required if an alternate means of communication is necessary. A defined timeframe for notification should be added to the requirement. It is possible that the loss of telecommunication facilties can occur without the loss of a control center. So, the redundancy with EOP-008 to R4 should be clarified.
No
M2 should be changed to reflect the comments noted in Question 1 for R2.
Yes
Based upon revisions to Question 1.
Yes
 
Yes and No
As long as the measurement of compliance does not include proving the negative, that no directives were issued.
No
R1-High VSL-If the directive was followed and there was no threat to the BES, then a lack of repetition of the directive does not constitute a "high" VSL. Suggest that this be a low or moderate VSL.
No
R2 refers to "intentional delay". The determination of intent should be left to the VSL portion of the standard, not the requirement portion.
Yes
If some language is changed, we support the revisions. R2 has language in it that should be added to M4 to be consistent. In M2, we propose adding language "unless such actions would violate safety, statutory or regulatory requirements."
No
VSL's for R2 and R3 are not appropriate. In order to assess a situation we may not be able to immediately inform the RC of our ability to comply with the directive. The high VSL for R2 currently states that if we do not follow the directive because of safety, statutory or regulatory requirements, it is a high VSL. An entity should not be penalized for not breaking the law.
Abstain.
Abstain.
Abstain.
No
The accountability and monitoring addressed in this Standard is still required. The drafting team's intent was that the ability to monitor is part of the certification process. However, certification is to Standards, and if there is not a Standard which addresses this issue, then an entity cannot certify to it.
Abstain
Abstain
Abstain
Abstain
Abstain
 
Group
ISO/RTO Council Standards Review Subcommittee
Charles Yeung
SPP
Yes and No
We suggest that a definition of telecommunications be written by the drafting team because it is not clear what all telecommunications is intended to be included. Does this requirement apply to data, voice, rtus, networks, etc? For requirement R2, e suggest that you strike the final clause: "and shall verify that alternate means of telecommunications are functional." It is obviated by the requirement to notify impacted parties. The responsible entity is already implicitly required to verify its alternate means of communication is functional since it is required to notify its impacted parties of the failure of its normal telecommunications. It can't notify its impacted parties if the alternate communications means are not funcitonal. The VRF for new requirement 1 should be lower. It does not fit the definition of a medium VRF. A medium VRF requires that a violation of the requirement directly affect the state or capability or the ability to effectively monitor and control. Failure to test does not result in directly affecting the state or capability or the ability to effectively monitor and control. At a minimum, a failure of the alternative communication systems and primary communication systems must occur first. The failure to perform a single test in a given quarter does not mean that primary and alternative communication systems will fail. Thus, testing is really an administrative issue and should thus be a lower VRF. In the Data Retention section, Distribution Provider and Generation Operators should be added. Currently, there are no data retention requirements listed for them. Suggest modifying the language regarding data retention for compliance violations to: "… is found in violation of a requirement, it shall keep information related to the violation until it the Compliance Enforcement Authority finds it compliant."
Yes and No
M3: The evidence to show that concurrence is in place to allow communication using a language other than English is missing. The Measure as written merely asks for evidence that communication in a different language has occurred.
No
The VSLs as defined for Requirement 1 appear to violate Guideline 4 that the Commission established in their "Order on Violation Severity Levels Proposed by the Electric Reliability Organization". Guideline 4 requires that a VSL should be based on a single violation. The VSLs as defined accumulate the number of consecutive quarters. This would imply that a single violation could last more than a year and that the compliance auditor could not determine sanctions until the entity becomes compliant or year has passed. A single violation appears to be the failure to test in a single quarter. This requirement is binary in nature in that it is either met or it isn't. We suggest that only a lower VSL should be defined as: "The RC, TOP, or BA failed to test the backup telecommunication facilities for a single calendar quarter." The Lower VSL for R2 is not possible. The act of notifying all impacted entities of the failure of their primary telecommunication system requires the use of the alternative telecommunications systems which is a form of verying that the alternative telecommunications facilities are functional. The drafting team should consider applying the numeric performance category of the VSL Development Guideline Criteria for R2. (i) R1: Suggest to revise the conditions for all levels to read "…failed to operationally test the altarnative communication facilities within the last……… (ii) R2: The second part under Severe is not needed since failing to notify any impacted entities would imply no communication to the affected entities anyway. If verification of the functionality of the alternate means of telecommunications is also critical even without communicating to the affecte entities, then the second condition should be an "OR". (iii) R3: Failure to having concurrence to use a language other than English for communications between and among operating personnel responsible for real-time operations by itself does not consitute a violate of any requirements; it is the absence of such a concurrence AND having used a language other than English that would consitute a violation. Suggest to revise this condition.
Yes
 
Yes
 
Yes
 
Yes and No
New requirement R2 should omit act without intentional delay. Use of intentional implies willful disregard for compliance for the requirement. Intention should not be addressed as part of the compliance with the requirement but rather through the enforcement process once the compliance auditor has identified a violation. The word immediately should be removed from the new R3. This attempts to time frame the response of the responsible entity and remove the judgment from the compliance auditor. We agree with the concept of doing this but in reality it only confuses the issue and the compliance auditor will likely apply his judgment regarding what immediate is anyway. Additionallly, the requirement attempts to separate the act of confirming that the responsible entity can take the action from notifying the RC that the entity can't take the action. This is not logical. What RC is going to request a responsible entity to take action that would violate safety, equipment, statutory, or regulatory requirements? The RC should already be aware of those requirements and likely won't direct actions that violate them. Thus, the likely scenario is that the responsible entity will attempt to take action and discover that equipment is not funcitoning properly and thus notify the RC. We suggest striking the "shall immediately confirm the ability to comply with the directive or" from the requirement. This part of the requirement is not needed because the responsible entity is already obligated to follow the RCs directive (see order 693.) Thus, the assumption is that the order will be followed unless it can't be followed because it will violate safety, equipment, statutory, or regulatory requirements. Requirements R4 and R5 are unnecessary. New R1 requires the RC to direct actions to be taken by the TOP, BA, GOP, TSP, LSE, DP and PSE to prevent or mitigate the magnitude or duration of events that result in Adverst Reliability Impacts. The RC can't direct these actions without notifying all impacted TOPs and BAs. They would also have to notify them when actions are no longer necessary. The VRF for R5 should not be High. Failure to notify others when potential threats to system reliability have been mitigated does not consititue a high risk to the interconnected system. We suggest it be reduced to a Medium (i.e., that it affects control of the BES).
 
No
The R1 High and Severe VSL appear to differ only by the inclusion of directing actions in Severe. From a practical perspective, what is the difference between directing actions and acting? We don't believe there is any. The actions are the result of the RC authority whether the RC takes the actions themselves or directs someone else to. We suggest a better alternative for the VSL levels would be for the High level to reflect that the RC did not act or direct actions to prevent an Adverse Reliability Impact and Severe would be that the RC did not act or direct ations to mitigate the magnitude or duration of an existing Adverse Reliability Impact. The moderate VSL for R2 is not practical and too subjective. What constitutes a delay? What if the responsible entity takes five minutes to determine how to carry out the action or if their equipment currently is capable of carrying out the action? Is this a delay? We suggest striking this Moderate VSL. The High VSL does not agree with the requirement. It considers the inability to fully follow an RC directive due to a violation of the safety, equipment, statutory, or regulatory requirements a violation. This is in direct conflict with the requirement. We suggest that the High VSL should be struck. We suggest the Severe VSL should be that the responsible entity failed to follow the RC directive and it would not have violated the safety, equipment, statutory or regulatory requirements. Currently, the Severe category does not allow that the responsible entity may not be able to carry out the directive due to the violation of safety, equipment, statutory, or regulatory requirements. In question 7, we request that the drafting team strike part of requirement 3. The striking of that portion of requirement 3 obviates the lower VSL. In paragraph 27 of the ORDER ON VIOLATION SEVERITY LEVELS PROPOSED BY THE ELECTRIC RELIABILITY ORGANIZATION, the Commission expresses "that, as a general rule, gradated Violation Severity Levels, whereever possible, would be preferable to binary Violation Severity Levels". Given that it is possible to define gradated VSLs for R4 and R5, we suggest that the drafting team should consider applying the numeric performance category of the Violation Severity Levels Development Guidelines Criteria based on the number of impacted TOPs and BAs that were notified.
No
New Requirement R2 is no longer needed as a result of paragraph 112 in Order 693-A. Since the RC's "authority to issue directives arises out of the Commission's approval of Reliability Standards" the RC already has veto authority or will have once R1 IRO-001-2 is approved. This requirement obligates the RC to take actions or direct actions to prevent Adverse Reliabilty Impacts. Veto outages of equipment and analysis tools would fall into this category even if the RC couldn't say for certain that an Adverse Relability Impact was going to occur but rather they are concerned one could occur due to heavy loads for example.
No
Measure 1 should not focus on a letter as evidence. A more appropriate measure would be a data specification document and actual verification that data has been received. The letter or equivalent is only needed if data has not been supplied. Demonstration of the actual receipt the data would be easy.
No
For R1, the lower VSL contradicts itself. It states that RC demonstrated that it determined its data requirements and requested that data and then follows with that it didn't request that data. The second option in the Lower VSL category is not practical and a compliance auditor would not be in a position to determine this. In fact, if the administrative data is not requested, other administrative requirements for reporting would be violated. Additionally, it does not make sense that an RC would determine its data needs and then omit data for administrative reporting. Further, is it the compliance auditor's job to judge if the data the RC requests is sufficient or is it his job to see that the RC has met the requirement to define the data? The remaining VSLs imply that the RC may define only partial data requirements. This does not seem likely. Why would the RC do this? This VSL appears to add to the requirement by making it appear that the compliance auditor is to judge the completeness of the data requirement. This violates Guideline 3 of the FERC ORDER ON VIOLATION SEVERITY LEVELS PROPOSED BY THE ELECTRIC RELIABILITY ORGANIZATION. Practically, it would not be enforceable anyway. It would require the RC to admit that they did not include administrative data in the their data requirements. It is doubtful this would happen because the RC likely believes they prepared a complete data requirement document. We suggest that the VSLs should be: Severe: The RC did not determine it data requirements or the RC could not demonstrate it requested the necessary data if actual receipt of the necessary data can't be deomstrated for greater than 75 to 100% of the TOPs, BA, TO, GO, GOPs, LSEs and adjacent RCs. High: The RC could not demonstrate it requested the necessary data if actual receipt of the necessary data can't be deomstrated for greater than 50 and less than or equal to 75% of the TOPs, BA, TO, GO, GOPs, LSEs and adjacent RCs. Medium: The RC could not demonstrate it requested the necessary data if actual receipt of the necessary data can't be deomstrated for greater than 25% and less than or eqal to 50% of the TOPs, BA, TO, GO, GOPs, LSEs and adjacent RCs. Lower: The RC could not demonstrate it requested the necessary data if actual receipt of the necessary data can't be deomstrated for greater than 0% and less than or equal to 25% of the TOPs, BA, TO, GO, GOPs, LSEs and adjacent RCs. R2 VSLs are not needed er paragraph 112 of Order 693-A. The Severe VSL contradicts the requirement.
 
No
Please strike "as a minimum" in R1. By definition, the requirement defines the minimum. Please strike R1.6. RCs already have the authority to act per paragraph 112 of Order 693-A. Since R2 requires the RCs to agree, is the "mutually agreed to" clause in R1.1 necessary? Please strike requirements R4 and R4.1. It is duplicative to R1.1. Conference calls are a form of communication and should be address per R1.1. R5 is confusing. If a reliability issue isn't confirmed, doesn't this mean there is no reliability issue? Isn't this the point of confirming? Additionally, we suggest using validate instead of confirm. As Requirement 1 is currently written, one could interpret the requirement for every Operating Process, Procedure and Plan to address each of the sub-requirements. That is not necessary. The drafting team needs to consider modifying the requirement to make it clear that not every sub-requirement must be addressed in every Operating Process, Procedure, and Plan and to also make it clear that the some sub-requirements may only be appropriately addressed in a Process but not a Plan for instance. Use of the term collectively may resolve this dilemma.
No
Measure 1 appears to add to the requirement. Requirement 1 does not mention anything about System Operators yet the measurement does. The measurement should just be to verify that the RC has have Operating Processes, Procedures, and Plans. The sub-measurements are not measurements at all. There should be the single measurement to verify the Operating Processes, Procedures, and Plans have been developed and address the sub-requirements. This really points out the problem with making the criteria that must be considered in the Operating Processes, Procedures, and Plans sub-requirements in the first place. They aren't requirements of any sort. They represent criteria. The drafting team should consider making them a bulleted list without the Rs, then the drafting team won't feel compelled to write sub-measures that don't measure anything.
No
For R2, the High and Severe VSLs contradict the requirement. We believe all of the "nots" should be removed. We don’t' agree with the VSLs in R4 since we believe R4 should be struck. The Lower VSL for R6 should not even be a violation unless the impact was negative. If the RC implemented a different mitigation plan and resolved the issue, then the RC was likely correct to disagree.
Yes
 
Yes
We do agree with moving the requirement. However, the drafting team needs to revisit the wording of the requirement. The new wording is much more confusing. Until we reviewed IRO-016-2, it was not clear at all that R6 in IRO-014 was attempting to mimic R1 and its sub-requirements in IRO-016-2.