Newsroom  Site Map  Contact NERC       




Individual or group.  (71 Responses)
Name  (44 Responses)
Organization  (44 Responses)
Group Name  (27 Responses)
Lead Contact  (27 Responses)
Question 1  (68 Responses)
Question 1 Comments  (71 Responses)
Question 2  (67 Responses)
Question 2 Comments  (71 Responses)
Question 3  (70 Responses)
Question 3 Comments  (71 Responses)
Question 4  (67 Responses)
Question 4 Comments  (71 Responses)
Question 5  (68 Responses)
Question 5 Comments  (71 Responses)
Question 6  (67 Responses)
Question 6 Comments  (71 Responses)
Question 7  (68 Responses)
Question 7 Comments  (71 Responses)
Question 8  (66 Responses)
Question 8 Comments  (71 Responses)
Question 9  (58 Responses)
Question 9 Comments  (71 Responses)
Question 10  (57 Responses)
Question 10 Comments  (71 Responses)
Question 11  (57 Responses)
Question 11 Comments  (71 Responses)
Question 12  (63 Responses)
Question 12 Comments  (71 Responses)
 
Group
E.ON U.S. LLC
Brent Ingebrigtson
Disagree
For the Communication Protocol definition, please clarify if “written” includes electronic (email.) Change the definition of “Interoperability” to “Emergency” Entities should not be required to use 3 part communications on a routine basis, only on emergency issues.
Disagree
As the requirement already exists it is redundant to incorporate it into COM-003. The incorporation not only exposes a responsible entity to double jeopardy, it now exposes Transmission Service Providers and LSEs to COM-003 requirements that should not apply to these entities. TOP-002 addresses planning ahead of the operating hour whereas COM-003 addresses communication during real-time operations. In the absence of evidence that the lack of common identifiers is an imminent and continuing risk to BES reliability, it does not make sense to have operators addressing urgent, real-time situations bear significant penalty risk should they refer a BES element by something other than a newly established common identifier. Is it the intent of the requirement that the common identifiers be the same for all neighboring parties, all of whom must “agree” to the identification? If not, then an element might be referred to by one identifier with Party A, another with Party B etc. which might well defeat the purpose of the requirement. If it is required that there be a single identifier, then all neighbors would have to agree upon the identifier constrained as each may be by, for example, the formatting limitation of their respective SCADA/EMS systems. Cost to modify software to accommodate common identifiers could be significant and NERC should weigh these costs and the aforementioned operational risks against the perceived incremental improvements to the BES reliability.
Disagree
Requiring production of a document that merely repeats Requirement 2-7 of COM-003 does not further BES reliability. Requirements R2-R7 set forth all that such a document would contain. Stating that the CPOP should include but not be limited to R2-R7 is nonsensical. What additional issues should the CPOP be required to address and why aren’t those issues the subject of a COM-003 requirement?
Disagree
The attachment adds a whole new lexicon for BES operators. E.ON U.S. suggests integrating attachment 1 and the relative alert levels into the EOP standards. The purpose of COM-003 indicates this standard is to ensure understanding of information during emergency alerts and emergency situations and not to establish the conditions, required notification, or levels of emergency alerts. While the attachment has been identified as a product of the RCWG it is unclear whether it has been reviewed and approved through the normal NERC and industry vetting.
Disagree
If it is the intent that the requirements of this standard apply not only to control room operators but field personnel (line crews, substation crews, etc.) then E ON US is not in favor of using a common time zone nation-wide. The confusion that this change could create in real-time operations outweighs the BES reliability benefit E.ON US would also like clarification that this requirement does not apply to control systems or elements thereof that may log equipment operations. The background information above suggests this possible interpretation.
Disagree
E ON US believes more specificity is required as to what constitutes a “directive”. Moreover, this requirement is redundant in light of COM-002 R2 for normal operations. If COM-003 is only applicable to emergencies, then this R5 would appear reasonable. E.ON U.S. suggests editing R5 and M5 as follows: Each Responsible Entity shall use Three-part Communications when issuing and/or receiving a directive during verbal Interoperability Communications
Disagree
The entire standard should only apply to emergency operations, not all communications. If it is the intent that the requirements of this standard apply not only to control room operators but also field personnel (line crews, substation crews, etc.) then E ON U.S. is not in favor of using the NATO phonetic alphabet. The confusion that this change could create in real-time operations outweighs the BES reliability benefit. E ON U.S. suggests that if the objective is to avoid confusion over similarly pronounced words, use of an ad-hoc phonetic alphabet would more easily address the concern. E ON U.S. is also concerned that the attention paid to “how” orders are given and acknowledged may well detract from “what” it is responsible entities are attempting to do. Are responsible entities supposed to spell out each number and word using the phonetic alphabet? The drafting team should be more specific as to what is meant by “alpha-numeric information.”
Disagree
In the absence of evidence that the lack of common identifiers is an imminent and continuing risk to BES reliability, it does not make sense to have operators addressing urgent, real-time situations that bear significant penalty risk should they refer to a BES element by something other than the common identifier. The operator focus at such times should be on resolving the situation not avoiding penalties over nomenclature. Is it the intent of the requirement that the common identifiers be the same for all neighboring parties, all of whom must “agree” to the identification? If not, then an element might be referred to by one identifier with Party A, another with Party B, and so on, which might well defeat the purpose of the requirement. If it is required that there be a single identifier, then all neighbors would have to agree upon the identifier constrained as each may be by, for example, the formatting limitation of their respective SCADA/EMS systems. Cost to modify software to accommodate common identifiers could be significant and NERC should weigh these costs and the aforementioned operational risks against the perceived incremental improvements to the BES reliability.
Disagree
E.ON U.S. has many concerns with this proposed attachment. The use of color coding and multiple types of alerts adds unnecessary levels of complexity. Any proposed alert level should be consistent throughout the suite of reliability standards, e.g level 1,2,3. Also, as previously noted in our comment to question 4 above, E.ON U.S. suggests integrating attachment 1 and the relative alert levels into the EOP standards and focusing the COM standards on the requirements of communications protocol.
Disagree
 
Disagree
If the requisite protocols are intended to be followed by all field personnel, applicability of these requirements to Distribution Providers could run afoul of FPA Section 215(a) codified in 18CFR39.1.
Disagree
This standard should only apply to alerts and emergencies. E.ON U.S. suggests eliminating “ especially” in the purpose statement of COM-003-1. During emergency situations, operational focus on the semantics of how communications are to occur does little to enhance the reliability of the system. High VRFs with Severe VSLs may add stress and distraction to operation personnel during times of emergency thus potentially harming, not improving reliability.
Individual
James Sharpe
South Carolina Electric and Gas
Agree
 
Agree
 
Agree
 
Agree
We agree with the proposal, however we feel that the color system should be evaluated to better distinguish the type of attack for example using P-YELLOW for physical vs. C-YELLOW for cyber instead of just "YELLOW" for both.
Disagree
We feel that time zones should be consistent throughout all standards and regulatory reporting requirements(eg. TADS)
Disagree
The term "directive" should be changed to "Reliability Directive" as defined in COM-002-3.
Disagree
We believe this should only be required when issuing Reliability Directives.
Agree
 
Agree
See question 4.
Disagree
 
Disagree
 
Agree
The SDT should consider vertically integrated utilities, where communication between functional entities is internal.
Group
Electric Market Policy
Mike Garton
Disagree
We do not agree with the adaptation of the proposed term “Interoperability Communication”. As defined, it is limited to the communication of information to be used to change the state or status of a BES element or facility. That definition is too limiting in that there are many types of reliability-related information that need to be clearly communicated that do not lead to changing the state of a BES facility. For example; information related to ratings, information related to the results of studies, information related to data errors or loss of data, etc. If the term “Interoperability Communication” is to be retained, we strongly suggest a name change. The word “interoperability” is widely used to refer to the ability of a system to work with or use the parts or equipment of another system. For example please see the current standards development efforts identified in the NIST Framework and Roadmap for Smart Grid Interoperability Standards available at http://www.nist.gov/public_affairs/releases/smartgrid_interoperability.pdf. Using the term “interoperability” to refer to reliability-related human communications could be confusing to regulators, compliance personnel, auditors, and many others who have to deal with a variety of standards.
Disagree
In our experience, neither the TSP nor the LSE provide or receive information about specific lines or equipment in real-time. Therefore, requirement R7 should not apply to them absent clear evidence that a realistic (not hypothetical) threat to reliability would exist if they are omitted. We do not think that such a threat would exist. Applying R7 to TSPs and LSEs would only cause them grief and further burden the compliance staffs of the regional entities for no appreciable benefit.
Disagree
We agree that communications procedures are necessary, but we do not agree with several of the requirements proposed to be addressed in the elements of the CPOP. See our comments on specific requirements elsewhere in our responses. We do not see the need to create a CPOP that includes requirements R2 through R7 given that each requirement spells out how and what is to be communicated. We could agree that a CPOP may be needed for Interoperability Communications that are not addressed in R2-7.
Disagree
We object due to the following reasons; 1 - There are 3 versions of Attachment 1-COM-003-1 which is potentially confusing. We suggest separating into 3 attachments, one for each type of notification. 2 – The level(s) identified in the notification text are at odds with the condition (color vs numerical). It is suggested that the standard either use to Condition (color) or the level (numerical). 3 – None of the Operating State Alert Levels in Attachment 1 appears to address Energy Emergency Alerts (EEAs). The note in the “Attachment 1-COM-003-1 defines normal, alert, and emergency operating conditions as they relate to Transmission Loading, Physical and Cyber Security. These definitions for Transmission Loading, Physical and Cyber Security Alert states align with the Emergency Energy Alert (EEA) states (as already described in NERC Reliability Standard EOP-002-2.1). The time frame for declaration of these Alert states shall be consistent with the approach used to declare EEAs and would normally apply to Real Time declarations and not forecast conditions.” This seems to limit use of Interoperability Communications to only events where there exists either a physical or cyber threat, or where an IROL can’t be mitigated. This emphasizes the confusion as described in item 2 above where the EEA levels in EOP-002-2.1 uses numerical values (i.e. EEA Level 1) without the colored conditions. We recommend adding a new section to Attachment 1 ‘Operating State Alert Levels’ as: ‘Reliability Coordinator Notifications for Energy Emergency Alerts.’ 4-Attachment 1 pertains specifically to Operating State Alert Levels and says nothing about the communication of information to be used to change the state or status of a BES element or facility (which is the SDT’s proposed definition of Interoperability Communications). Therefore, it is not appropriate to require that all verbal and written Interoperability Communications use the pre-defined terminology in Attachment 1. Only those communications concerning Operating State Alert Levels should be required to use that terminology. By the proposed definition, such communications are not Interoperability Communications since the information is not used to change the state or status of a BES element or facility. The SDT needs to revise this requirement to clarify that it pertains only to communicating the Operating State Alert Levels and nothing more.
Disagree
Any confusion about what time is being verbally communicated should be cleared up by three-part communications. There should be no confusion about what time is being communicated in writing as long as the time zone and AM\PM designation are included. Besides, many entities exchange written information via web-enabled applications that allow the users to configure their interface to show time in whatever format and time zone they prefer. This eliminates confusion. Operators will continue to use local time in their communications with field personnel, support staff, and management, and we see no demonstrable reliability-related need to require every operator in North America to have to convert their local time to CST in their communications with other operators. However, if the SDT feels a standard time must be adopted, it should be GMT as this is the time that used by all ‘true time’ devices.
Agree
As currently defined, Three-part Communications presumes the second party will repeat the information back “correctly.” Failure to do so is assigned a High VRF and a Severe VSL. The practical application of Three-part Communication involves a sender communicating information, a receiver repeating back the information, and the sender verifying the repeat back is either correct or incorrect. If the repeat back is incorrect, the process repeats until both parties have the same understanding of what is being communicated. This iterative process needs to be addressed within the definition of Three-part Communications.
Disagree
Use of this adds a lot to verbal communication but has little value. Where either the issuing or receiving party is unsure as to which letter was used, their choice of word to associate with the alphabet need not be dictated by a specific phonetic alphabet. If I am unclear, whether I ask “did you say ‘F’ as in Frank or ‘F’ as in Foxtrot, it is my belief that we will both know that I heard the letter F not the letter S. Using Frank instead of Foxtrot will result in a violation of Requirement R6 which carries a High VRF and a Severe VSL; even though there would be no impact on effective communication. There is no compelling reason to require every operator in North America to learn and use the NATO phonetic alphabet. It would be overkill to do so, and it could create some really bizarre conversations. For example, consider a TOP in the eastern time zone who calls his RC (also in the eastern time zone) at 10:00 A.M.to confirm that a line that tripped earlier that morning will be ready to switch back in service at 10:35. Taken to the extreme, a strict interpretation of R6 and R4 (the CST requirement) would say that the TOP operator would have to state the estimated time of restoration as “niner tree fife, Alpha Mike, Charlie Sierra Tango”. There is no need for that.
Agree
While we agree conceptually, it is our experience that Interoperability Communications concerning BES elements do not usually specifically identify the element or facility when the BA, RC or TOP is communicating with the TSP, LSE or GOP. This may have to do with concerns about Standards/Codes of Conduct or may be because specific identification of the element or facility isn’t required in order to communicate action(s) that entity is required to take.
Agree
See response to question 4. In addition, there seems to be an inconsistency between the inclusion of Attachment 1 and what is stated in the document posted with the standard entitled Disposition of Requirements Identified in the SAR for Operations Communications Protocols as Possibly Needing either Modification or Movement. The document states that the standard focuses on “how to” communicate rather than on specified scenarios of “to whom” or “when to” communicate; however, Attachment 1 does just the opposite.
Agree
Some ISO/RTOs have market rules which allow participants to elect NOT to follow instructions issued by their market operator (who may also perform BA, TOP and/or RC entity functions) unless an Emergency exists.
Agree
PJM members are only required to comply during an Emergency.
Agree
The VRFs for R2-R7 are all “High”, and the VSLs are all “Severe”. That is too harsh. Failing to comply with one of the requirements does not automatically mean that a miscommunication occurred that caused a reliability problem. There should be a “Moderate” VSL for failure to comply with a requirement but no miscommunication occurred. There should be a “High” VSL for failure to comply with a requirement that caused a miscommunication but resulted in no violation of another reliability standard. The “Severe” VSL should only apply to failures to comply with a requirement that caused a miscommunication that lead to a violation of another reliability standard. If approved, this standard will require a number of distracting things be added to each entity’s control center with little value added. Clock – set to the ‘standard time’ Attachment 1 – COM-003 (all 3 versions) Attachment 2 – COM-003
Individual
Martin Bauer
Bureau of Reclamation
Agree
 
Agree
 
Agree
 
Disagree
Reclamation does not agree with the Attachment 1 condition color coding as it will conflict with the DHS system of notification of change in threat condition. The three color system is unique to the notifications issued by DHS. Use of that color system is reserved by the DHS. Federal agencies are required to perform specific tasks when DHS issues alerts or changes the threat condition. Only DHS can change the threat condition. The concept needs to be revised considerably to avoid the conflict or create a potential security issue.
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
As indicated in the previous response the standard conflictsd with DHS notifications.
Agree
 
Group
Midwest ISO Standards Collaborators
Jason L. Marshall
Disagree
The definition of Three-part Communication applies only when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should rather reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: “A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it.” These principles are included in Requirements R2 and R3 in the recently issued draft Standard COM-002-3 in Project 2006-06. We believe the term “Interoperability Communication” creates confusion within the industry and contradicts the work by RTO and RC SDT in Project 2006-06 that limits the requirement to use three-part communications when issuing Reliability Directives (defined in Project 2006-06) that address anticipated and actual emergency conditions. Additionally, it appears that this definition would encompass all verbal communications and, as such, we question the need for such definition. While using three-part communications during routine operations may be a best operating practice, we do not believe that it is so critical to reliability that it becomes an enforceable requirement for routine operating instructions. Rather we believe the enforceable requirement should be limited to require three-part communications during actual emergency and anticipated emergency conditions only. Both element and facility are used in the Interoperability Communication definition and are NERC defined terms. Did the drafting team intend that the NERC definitions should apply? Then the terms need to be capitalized. In addition, the term “entities” is confusing and needs to be defined.
Disagree
The SDT actually expanded Requirement R18 of TOP-002-2 by adding the term “equipment”. In any event, this Requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how. The only real need for a requirement is to establish that each entity issuing a directive shall use three-part communications and the recipient of a directive shall also properly participate in the of use three-part communication protocol until the message has been correctly spoken and comprehended.
Disagree
This proposed communication protocol is redundant to Requirements R2-R7 and should not be included in this Standard. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions. The NERC BOT has approved pursuing the Performance-based Reliability Standard Task Force’s recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to eliminate administrative requirements. This proposal takes the opposite approach and incorporates a new administrative requirement. We – and the industry as a whole based on the response to the Task Force – do not support such an approach. We suggest deleting this Requirement from the Standard.
Disagree
It is not clear what value there is in identifying these alert levels. There does not appear to be any differentiation in actions taken based on the alert levels. Why not just state the number of substations attacked, etc? Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the listed entities such as Distribution Providers and Generator Operators cannot have access to these systems due FERC standards of conduct requirements. Attachment 1 and R2 are not consistent with the definition of Interoperability Communications. By definition, Interoperability Communication pertains to all communications about how entities change the state of the BES (not just about physical or cyber attacks). Attachment 1 is only about notifying of what physical and cyber attacks and transmission emergencies have already happened to the BES.
Disagree
There is no reliability need to use a common time zone for communications. There is already a requirement to use hour ending for scheduling purposes, inadvertent accounting, CPS and other standards where needed. There is no additional reliability need to use a common time zone. The time zone should be identified in the communication. Use of CST will actually cause confusion and significant, unnecessary costs with no foreseeable reliability benefit. Some of the costs will arise to change systems such as RCIS, IDC, scheduling and E-Tag systems, etc.
Disagree
Based on the definition of Interoperability Communications, R5 implies that three-part communications is required to communicate routine operating instructions. We believe this Requirement contradicts the work that has been done and substantially progressed through two other SDTs and creates confusion within the industry. We believe this Requirement would, in fact, be adverse to reliability instead of enhancing reliability by reducing the amount of pre-action communications that may occur prior to taking action because operators may be more concerned with not repeating back during such pre-action, strategic calls and/or discussion. We support the work being done by the RC SDT and RTO SDT in Project 2006-06 which would define a Reliability Directive based on the determination of the person giving such an order. We believe it should be left to the entity that needs the action to be taken to establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger and easily auditable and measureable. R5 is not consistent with the Functional Model. Only the RC, BA, and TOP can issue directives.
Disagree
While this Requirement may represent a good utility practice in certain situations, it is not necessary to be used in all verbal Interoperability Communications and is certainly not necessary to be included as an enforceable Requirement. Imagine the situation in which an operator says “A as in apple” instead of using the NATO Alpha. Even though the listener should clearly be able to discern the correct meaning, the speaker’s company could be sanctioned even if the correct actions were taken as a result of the clear communication. There is no reliability need for this Requirement.
Disagree
This may represent a good utility practice but it is not necessary to be included as a Requirement. The key question is: “Do the companies’ personnel understand one another?” If I know that my company refers to a tie-line as Alpha and my neighboring company calls it Beta, I know what he means when communicating to me. That is all that matters. This is a “how” based Requirement that should be eliminated.
Disagree
It is not clear what value is realized by declaring an alert status particularly with regard to cyber and physical attacks. There does not appear to be any differing actions taken based on the alert status. Given that no differing actions are taken for cyber and physical attacks, it seems it would be more beneficial to use specific information such as 12 substations have been physically or cyber attacked. This is more meaningful than issuing a red alert that would only indicate more than one site has been attacked. Furthermore, we question the value of communicating the physical and cyber alerts. How does this notification help the BES reliability? Consider the following example. One BA in Oklahoma is 34,323 sq miles. Communicating that an attack occurred in the BA and RC tells other operators that somewhere in Oklahoma an attack occurred. This notification does not present any information that could require actions on the operators’ parts and will only generate phone calls for more information. Furthermore, PSE and CSE is a type of sabotage which is reported in CIP-001 R2 already. TEA Alerts are already covered in IRO-006-East-1, IRO-009, IRO-010, IRO-014.01 R2. Attachment 1 contains a conflict. The last sentence of the opening paragraph of Attachment 1 reads, “The time frame for declaration of these Alert states shall be consistent with the approach used to declare EEAs and would normally apply to Real Time declarations and not forecast conditions.” In Transmission Emergency Alerts Condition Yellow, Orange and RED: The Reliability Coordinator or Transmission Operator foresees or is experiencing conditions where all available generation resources are committed to respect the IROL and/or is concerned about its ability to respect the IROL. Forsees is a forecast condition. In condition Orange and Red for TEA Level Two/Three, the initial notification requirements are redundant with IRO-006-East-1 R3.2. Under the Make Final Notifications, is curtailed intended to mean canceled or terminated? The term Curtailed in operations generally means cuts for schedules/tags. EEA’s use terminated. We recommend using terminated. Distribution Service Providers should be Distribution Providers to be consistent with the Functional Model.
Disagree
 
Disagree
 
Agree
We believe that the existing standard COM-002 is better than this proposed Standard. This Standard actually causes more confusion and ambiguity and creates unnecessary or overly cumbersome requirements that add little or no value to reliability. Additionally, we cannot understand how all requirements but R1 have been determined to have a HIGH VRF when, many of them are dictating HOW communications should take place and not when and why or what. COM-002 retirement does not appear to be consistent with the direction of the RC SDT in Project 2006-06. The RC SDT is adding requirements. More coordination is certainly required between these two teams. In addition, as stated earlier, this Standard focuses on “how” certain tasks should be performed and conflicts with NERC’s position of pursuing performance based and results based Standards. Based on these considerations, we suggest that work on this Standard be stopped until work on Project 2006-06 has been completed and approved. This approach is consistent with the August 2003 Blackout Recommendation #26 which actually focused on communications during emergencies which is the scope of Project 2006-06. After Project 2006-06 is completed, a determination can be made if this Standard is even required.
Individual
Kasia Mihalchuk
Manitoba Hydro
Disagree
Comments: Agree to the adoption, but not the definitions as defined. 1. Communication Protocol - Remove “written” from this definition. Create a new standard that defines “written” protocol, i.e.: express “24 hour format”, common date format, etc. a) Using “written” in this definition and which is also used in COM-003-1 R2, R3, R4 and R7 clouds both the Definition and the Standard. The majority of COM-003-1 requirements also focus on the spoken word, such as the use of English, Phonetics and Three-way Communication. b) “Communications” in the Definition infers verbal communication especially when examining the COM-003-1 Standard where its purpose is “timely information in alerts and emergencies”. c) When COM-001-1 R4 “English” and COM-002-2 R2 “Three-way” requirements are amalgamated into COM-003-1, the COM-003-1 standard will now strengthen the focus on the process of verbal communications. d) COM-003-1 R2 “Uniform Line Identifiers” This requirement would be used in real time reliability situations, alerts and emergencies. The “written” communications would be used after the fact and therefore “written” does not belong in the definition. e) In COM-003-1 R3 “use English” The purpose of this standard is convey information effectively during alerts and emergencies. “Written” would be used after the fact and therefore does not belong here. f) In COM-003-1 R4 “24 hour format” “Written” could be reserved for a new standard, which could which define “24 hour format” along with a common date format which is also needed. g) In COM-003-1 R5 “Three-part Communication” Focuses entirely on the spoken word and appears appropriate that “written” is not used here. h) In COM-003-1 R6 “Phonetics” Focus on the spoken word and would never be used to empathize a written word and is appropriate that is not used here. i) COM-003-1 R7 states “Operating State Levels” All communications for broadcasting these alerts would typically be verbal. “Written” communications would be after the fact. 2. Three-part Communication - Use COM-002-2 R2 requirement as an improved basis for the “Three-part Communication” glossary term and define each part of the three parts separately. a) This new NERC Glossary term is better defined in the COM-002-2 R2 “Three-part communication” requirement. “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.” b) The current glossary term is overwhelming and confusing with the “back and forth” exchange of responsibilities. More thought process is consumed trying to break down the definition into usable portions, then comprehending the definition itself. c) The glossary term should be more clearly defined by specifying each of the three part communication protocol; i. An initiating party verbally issues directives in a clear, concise and definitive manner. ii. The receiving party shall replicate the intent of the directive and iii. The initiating party shall acknowledge to their satisfaction that the receiving party fully understands and is capable of caring out the directive. 3. Interoperability Communication - Define further and/or define entities. Expand “interoperability” and add and define “entity” a) Using “interoperability” and “entities” in same glossary term, clouds the definition especially when this glossary term is used to help clarify requirements in COM-003-1. There are at least three possible levels of “Interoperability” from a Control Center point of view; i. Internally, within a utility. -Communication between the Balancing Authority and Transmission for reliability purposes (within control center). -Between BA, TO, TOP, GO, TSP, LSE and DP, such as between the sending and receiving end of an HVDC terminal. ii. Externally, between neighbouring utilities. iii. Externally, between the Balancing Authority and their Reliability Coordinator. For a Reliability Coordinator two more levels of “Interoperability” could be added: iv. Communication between Reliability Organizations. v. Communication between the three major interconnections. b) Though the glossary definition surely includes all of the above, it does not clarify that and becomes immediately clouded when interpreting COM-003-1 R1 where “personnel” is used for real time control for effective Interoperability Communication. 1. Personnel – individual responsible for the operation of the interconnected bulk electrical system (real time, planning, etc) c) Adding and defining Entity in the glossary as per suggestions; i. “Entities” are used commonly in the Reliability Standards and encompasses a lot of different contexts. ii. “Entity” defined by a dictionary includes a comprehensive range such as: -body -Unit -Group -Thing -Article iii. Entity in a interoperable power system: - BA, TO, GO, TSP, LSE, etc - Neighbouring BA, Control Area, Neighbour (Utility) - Reliability Coordinator, MISO, Reserve sharing Group, etc - NERC, MRO, WECC, NPCC, ERCOT, etc - Western Interconnection, Eastern Interconnection, ERCOT.
Disagree
Leave TOP-002-2 R18 in its original location. 1)“Mutual line and equipment identifiers” should not be moved from TOP-002-2 and placed in COM-003-1 R7. TOP-002-2 Standard’s focus is “Planning, coordination and procedures” whereas: • R1 is “Maintain current Plans” • R2 is “Participate in planning and design” • R3 is “LSE coordinate with Host” • R4 is “BA coordinate with neighbours” • R5 is “plan to meet schedules” • R6 is “plan to meet N-1” • R7 is “plan to meet capacity and reserves” • R8 is “plan to meet VAR limits” • R9 is “plan to meet interchange” • R10 is “plan to meet IROL, SOL’s” • R11 is “perform studies for SOL’s” and “utilize identical SOL’s for common facilities” • R12 is “include known SOLs or IROLs” • R13 is “GO shall verify generation capability” • R14 is “GO shall notify of changes” • R15 is “GO shall provide generation forecast” • R16 is “shall notify RC of changes” • R17 is “notify RC of R1 to R16” • R18 is “shall use uniform identifiers” • R19 is “maintain computer models for planning” 2)TOP-002-2 R18 “shall use uniform identifies” appears to be more strongly related to where it already exists and would have more impact to have it moved between R2 and R3. 3)Uniform identifiers are determined in the planning stages and are common knowledge to entities by the time they are in service and not a real time communication issue. a.Having TOP-002-2 R18 moved to COM-003-1 R7, takes the purpose of the COM-003 standard outside its context of “timely convey reliability information . . . especially during alerts and emergencies”. b.COM-003-1’s purpose and all its requirements directly relate to real time communication. 4)TOP-002-2 R11 “identical SOL’s for common facilities” complements R18 “shall use uniform identifiers” and again are both planning requirements. 5)The unofficial comment for “Pre-determined Line and Equipment Identifiers” indicates that mutual agreement of these identifiers are to be reached in advance, thus agreeing with above. Leave R18 in TOP-002-2, but possibly move it between R2 and R3, thus R2 in COM-003-1 would be removed. Regarding adding TSP and LSE, no comment added.
Agree
Yes, with comments 1)In this requirement “Interoperability Communications between personnel responsible for real time” becomes clouded when compared to the “Interoperability Communications” definition that states “exchange information between entities”. a.Improving the “Interoperability Communication” definition as per early suggestion should clarify this. 2)Changing the order of requirements would make the flow of the standard smoother. a.Since this standard is mostly designed for real time communication, the requirements should pyramid down. • R1 is fine. • R2 should be “English” • R3 should be “NATO” • R4 should be “Time” • R5 should be “Three-part communications” • R6 reserved for “Full name identification” (See below for clarification) Conclusion: This requirement is acceptable as long as the enclosed comments are considered.
Disagree
Move this new requirement R1.2 in COM-002-2. 1)COM-003-1 R2 “Pre-defined system condition terminology” are all planned definitions. a.COM-003-1 purpose is to “convey information effectively” meaning the use of English, NATO, three-part communication, 24 time format are all verbal aspects to accomplish this purpose and not suited to pre-defined or planned items. 2)COM-003-1 R2 appears more appropriate and relevant placed in COM-002-2. COM-002-2’s Purpose is “capabilities for addressing real time emergencies and to ensure communications by personnel are effective”. a.Placing “Pre-defined system condition terminology” in COM-002-2 after R1.1 as R1.2 appears to have more of a chronological approach. i.R1.1 states “conditions that could threaten” ii.R1.2 use “pre defined system conditions” Conclusion: Remove COM-003-1 R2 and replace in COM-002-2 as R1.2
Disagree
As per below. 1)The 24 hour format will certainly reduce the confusion of AM and PM and at present seems to be the current best practice for all entities so should not be a major change. 2)Examining the definition of “Interoperability Communications” means that there is and will be real time communications with entities in other times zones, thus it is assumed that this being an NERC standard is enforcing that all other time zones (PST, MST, EST) will be using CST when communicating with interoperability. a.If this is the case, it appears that the other time zones (PST, MST and EST) must make effort to modify their local time to synchronize with CST. b.This brings to point that when interoperability communication is used, this fact must be mentioned, instead of 13:53, it should be 13:53 CST. 3)Adding CST to verbal time formats will be difficult to implement, so maybe a statement confirming the time zone should be appropriate each time interoperability communications is used when required. Conclusion: 24 hour format is fine, further clarify that all other time zones must use CST.
Move requirement as planned but keep Three-part Communication definition as stated originally in COM-002-2 R2. 1)Reading the “Disposition/Explanation” it appears that COM-002-2 R2 will eventually be moved into COM-003 R5. This appears logical as COM-002-2 ensures staffing and communication capabilities. a.The statement in COM-002 R2 is reasonably descriptive, but loses its depiction when replaced with statement found in COM-003-0 R5. 2)Regarding COM-002-2 R2, Manitoba Hydro interprets part 2 (repeat back correctly) of Three-part Communication to mean; that the party receiving the directive has clearly received it in its full form and understands completely what is expected of him and to convey this to the sender; i.We delineated “repeating back correctly” to mean any of the three protocols as acceptable: 1.Actually repeating back the directives correctly. 2.The recipient verifies the issued directive(s) are identical to a copy they have at hand. Example for clarification: “The steps you have read are identical to what I have here on Order Number 1234, Revision 5 and I understand I can proceed with steps 3,4 and 5”. 3.The recipient summarizes the issued directive(s) to a copy they have at hand. Example for clarification: “I will do step 8, open all 115 kV disconnects as read to me and are identical to the order 1234 Revision 5 that I have at hand”. 4.This all could be resolved by using the term “repeat back the intent of the directive”. This statement could allow the operator to determine if the recipient fully understands and is capable of carrying out the directive, by the method of the recipient reply (any literate person can read back a written statement, but do they understand what they are doing and the consequences). ii.The purpose of protocols 2 and 3 are to alleviate potential of “lose of attention” due to the tedious receptiveness of long written directives. Summarizing or verifying these types of written orders will maintain the interest and attention to the detail. iii.Verbally detailing a directive at least once in any single conversation by either party should be sufficient to fulfill the first two parts of Three-part Communications (Clear and concise, repeat back). iv.Part 3 (acknowledge to satisfaction of the originator) could ensure that the person receiving the directive is capable and competent of carrying out the directive. v.None written (changes, revisions, real time emergency switching) and radio communication directives are a must for repeating back and are covered by other local policies. Part Two “Three Part Identification” 3)This new Standard COM-003-1 should contain a requirement for “Three Part Identification” or more commonly known as “Full Name Identification”. This is not addressed fully anywhere in the NERC standards. 4)We have defined “Three Part Identification” based loosely on common industry best practice into three parts: 1.Location – Company Name, Control Room Name, etc. 2.Area of responsibility or authority (function) – The operator at the desk must identity his position such as Balancing Authority or Distribution Operate, etc. 3.Identification – Unique identifier such as first and last Name.
Disagree
To using NATO full time 1)Being trained or being familiar with NATO Phonetics is a great idea, but should only be implemented, in bad communication connections, or upon request due to accents, quiet voice, fast talk, too loud, unusual request, etc. 2)Communication technology for the most part is exceptionally clear, and the regular use of NATO Phonetics would be difficult to implement and time consuming to use. The RC and neighbouring entities are familiar with common terminology between each other.
Disagree
Move this new requirement R1.3 in COM-002-2. This is similar to Question 4 and should be treated in the same way: (This requirement is moved from TOP-002-2 R18) 1)COM-003-1 R7 “Pre-determined, mutually agreed upon line and equipment identifiers” are all planned definitions. 2)COM-003-1 purpose is to “convey information effectively” meaning the use of English, NATO, three-part communication, 24 time format are all verbal aspects to accomplish this purpose and not suited to pre-determined or planned items. a.COM-003-1 R7 appears more appropriate and relevant placed in COM-002-2. COM-002-2’s Purpose is “capabilities for addressing real time emergencies and to ensure communications by personnel are effective”. 3)Placing “Pre-determined, mutually agreed upon line and equipment identifiers” in COM-002-2 after R1.1 as R1.3 appears to have more of a chronological approach. i. R1.1 states “conditions that could threaten” ii. R1.2 use “pre defined system conditions” iii. R1.3 use “pre determined equipment identifiers” Conclusion: Remove COM-003-1 R7 and replace in COM-002-2 as R1.3
Disagree
1)Attachment 1-COM-003-1 qualifies for all three requirements stated below and would be better suited in this Standard. a.CIP-001-1 Purpose:“sabotage to be reported to appropriate bodies” and includes the following requirements; R1. Procedure for recognition R2. Procedure for communication R3. Response guideline 2)OR COM-003-1 Attachment 1 could also be placed in COM-002-2. COM-002-2’s Purpose is “capabilities for addressing real time emergencies and to ensure communications by personnel are effective”. 3)COM-003-1 purpose is to “convey information effectively” meaning the use of English, NATO, three-part communication, 24 time format are all verbal aspects to accomplish this purpose and not suited to pre-defined or planned items. 4)COM-003-1 Attachment 1 also defines Physical Security threats and notifications which fulfills the purpose of COM-002-2 more thoroughly (then in COM-003-1) and could even be made as an requirement.
Disagree
 
Disagree
 
Disagree
 
Group
Transmission Owner
Silvia Parada-Mitchell
Agree
 
Disagree
This requirement is already covered by TOP-002. If the TOP-002 standard is deemed deficient because certain entities have been excluded or language appears to be missing, the changes need to occur to TOP-002 as opposed to copying and revising the existing requirement elsewhere. This would ensure that compliance oversight, understanding, and adherence goals are unencumbered by unnecessary redundancies. Moreover, this would ensure that the industry continues to re-enforce standards with changes that are within the scope of their original reliability purpose. The latter is in line with one of the core objectives of the Performance-based Reliability Standards Task Force’s recommendations to focus on identifying and aggregating duplicated requirements.
Disagree
FPL agrees with the reliability goal of establishing a set of agreed upon communication standards to ensure consistent communications particularly for actual and anticipated emergency coordination needs. FPL also believes that existing coordination/communication standards already fulfill this objective and that it might be of “training” or “reference” value to aggregate those requirements to a single document or view. However, FPL is not convinced that this requirement, largely administrative in nature, will result in marked improvement in reliability. Organizations tend to take the path of least resistance and unless forced out of that path with extensive and granular guidance on what CPOPs should contain above and beyond existing standards or contract language, CPOPs would likely become a simple patchwork of requirements constructed out of existing NERC standard language and contract language. Standards need to be clearly implementable before they are approved yet important implementation questions do not appear to have been answered. (1) What if parties cannot reach agreement? (2) Is it enough to have attempted to coordinate? (3) What if parties already have agreed upon procedures such as NPIRs, or those stated in Interconnection Agreements – do they take precedent or must they be redesigned/relegated? (4) What if CPOPs differ greatly across interconnections because of differing parties? (One might conclude that by formalizing these different practices, as opposed to mandating standard practices, the goal of more reliable coordination may not have been achieved) (5) What level of evidence constitutes “agreement” especially in circumstances where entities may be remiss to agree? (6) What if CPOPs are simply a patchwork of requirements constructed out of existing NERC standard language and contract language – does that achieve the CPOP goal?
Disagree
FPL agrees that standard system condition terminology could be beneficial in communications but this requirement introduces alert level conventions with no clarity on what the corresponding associated actions for such levels are and as a result, aside from the value derived from have improvement in terminology during communications, it is unclear what reliability improvements this will achieve in carrying out instructions since details on what sort of tasks need to be carried out for each level have not been defined. Also, this requirement should clearly indicate that this alerting system and any communication conventions be required for emergency conditions.
Disagree
Existing market and reliability communication methods already ensure that time-zone adjustments occur. It is critical that the feasibility, impact, and logistical aspects of implementing this change be rigorously reviewing and understood to inform this standard’s development. Any implementation or transition gaps between the time format and references used by reliability coordinators, their corresponding systems, and the interfaced systems of market participants would be extremely detrimental to system stability and ongoing market operations.
Disagree
The term “directive” as of yet has not been explicitly defined. Furthermore, FPL believes that by associating the “3-part communication” method with “directives” this standard drafting team could be at risk of unintentionally defining a directive as anything that takes the 3-part communication form. We would encourage the standard drafting team to continue to use the terms already employed in the draft standard: “… three-part communication be used when issue instructions related to “actual or expected emergency conditions.”
Disagree
FPL believes that though aspiring to use a single strict phonetic alphabet is important, it is more important to ensure that ease of communication takes precedence especially under emergency conditions. As such, this requirement should be written more as a best practice or guideline. FPL believes this requirement could be improved by stating that under such emergency conditions, the NATO phonetic alphabet can be used as a base-line reference but that usage of ad-hoc phonetic alternatives that achieve the same real-time communication goal can also be used.
Disagree
FPL believes that R7 should be withdrawn as it repeats TOP-002 R18 requirements. Please refer to comments on Q3.
Disagree
 
Disagree
 
Disagree
 
Agree
In the case of nuclear plant operations, NRC communication requirements and the requirements of NERC NUC-001 for nuclear facilities more than adequately cover communication requirements. COM-003 should not be applicable to Nuclear Generator Operators since doing so will introduce an additional, unnecessary, and potentially conflicting level of requirements. Measures: FPL suggests that the SDT clarify the periodicity of providing evidence of compliance and on what constitutes sufficient evidence of CPOP acceptance. Violation Severity Levels: FPL encourages the SDT to revisit the violation severity levels. In the case of most of the requirements it is unreasonable to levy severe penalties in instances where the operator may have deviated from the requirements but the communication occurred in an unencumbered and successful manner as evidenced by the use/acknowledgement outcomes of three-part communication.
Individual
Tim Hattaway
PowerSouth Energy
Disagree
Inoperability definition is too broad and not clear.
Agree
 
Disagree
It's not clear as to who is being targeted as the "personnel responsihle for real-time generation control and real-time operation of the BES". Is this just the system operator or is this the generator unit operator or the field switchman?
Disagree
This requirement is unecessary.
Disagree
This requirement will be too confusing and could lead to compliance violations because someone stated the wrong time during the conversation.
Disagree
The term interoperability communications is not clear.
Disagree
Completely unnecessary to require each operator to learn and use the NATO alphabet for situations that may occur on a very limited basis.
Agree
 
 
 
 
 
Individual
Joylyn Stover
Consumers Energy
Disagree
Communications Protocol and Three Part Communications have been used in the industry and are acceptable. There seems to be a better way of stating “informational” communications since Directives are already discussed.
Disagree
There is no reason to move R18 from TOP-002 to COM-003. There is also no reason to utilize a shotgun blast method of coverage for this standard. Also, regardless of technical accuracy, TOP-002-2 R18 should not be moved to COM-003-1 without a simultaneous and corresponding change to TOP-002-2, lest an entity be found non-compliant with both standards for a compliance violation.
Disagree
I agree written Communication Protocols should be in place. Since we do not agree with all of the requirements mentioned we can not agree with this statement. Furthermore, since these protocols will have to be between Functional Entities and most likely multiple companies, a methodology needs to be in place to prevent duplication of efforts and double jeopardy in the audit process.
Disagree
The COM Standards should put forth the methodology of communication, not provide communication for each event. For example, CIP-001 describes the communication to take place for CIP attacks, be they physical or cyber, EOP-002 describes the process for Generation and Capacity Emergencies. Utilizing the similar sounding vernacular (EEA,CEA,PSEA,TEA) is not prudent.
Disagree
Common Time Zone has been discussed for decades. There was little or no evidence a common time zone standard would have prevented any of the system disturbances experienced since 1996 let alone the blackout of 2003.
Agree
 
Agree
 
Disagree
This requirement is better served under the TOP Standards. The TOP standards already require this (TOP-002-2 R18), and the requirement should not be duplicated.
None.
None.
None.
Agree
Amplification of the communication process is needed but this draft reaches beyond Communication to the start of drafting procedures for three separate emergency conditions while it leaves one alone. Focusing on the communication process is in order.
Group
PacifiCorp
Sandra Shaffer
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
The sole use of Central Standard time Time would add confusion to thefor Interoperability communication Communications process that would detract would have the unintended consequence of creating more confusion, particularly during emergency communications. While PacifiCorp appreciates the need for minimizing mis-matched time signatures between control systems, it believes that mandating one time zone for all Interoperability Communications will create more confusion during an emergency that it will prevent.
Agree
 
Agree
 
Agree
 
Disagree
 
Disagree
 
Disagree
Currently, PacifiCorp’s Open asis Access Same-Time Information System (OASIS) allows time to be showndisplays time in Pacific standard Standard timeTime. Mandating all Interoperability Communications to be held in Central Standard Time may cause confusion with regard to transactions and activities conducted on OASIS – which ultimately relate to real-time operations.
Disagree
 
Group
Northeast Power Coordinating Council
Guy Zito
Disagree
The way the definition of “Three-part Communication” is worded applies only when the communication is understood by the listener the first time. The RC SDT requirement which includes “and shall acknowledge the response as correct or repeat the original statement to resolve any misunderstandings” is more complete. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. A suggested revision to the definition: A Real-Time Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it. These principles are included in Requirements R2 and R3 in the recently issued draft Standard COM-002-3 in Project 2006-06. An alternative suggestion to the definition of Three-part Communication: A Real-Time Operating Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct by the party who initiated the communication. A suggestion to the definition of Communications Protocol: The term “Interoperability Communication” creates confusion within the industry, and contradicts the work by RTO and RC SDT in Project 2006-06 that limits the requirement to use three-part communications when issuing Reliability Directives (defined in Project 2006-06) that address anticipated and actual emergency conditions, and do not agree with its definition. What also must be considered is that the RC SDT has stated that when someone “says”, it is a directive--operating conditions are not distinguished. This definition unnecessarily and counterproductively encompasses all verbal communications and, as such, is not needed. It is not so critical to reliability that it should become an enforceable requirement for routine operating instructions. The enforceable requirement should be limited to require three-part communications, and be left to the entity that needs the action to be taken to establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger, and be auditable and measurable. Virtually all communications in a control room environment deal with changing the state or status of an element of facility, as such there is not a need to define this communication protocol. Both element and facility are used in the Interoperability Communication definition and are NERC defined terms. Did the drafting team intend that the NERC definitions should apply? If so, the terms need to be capitalized. The term “entities” is confusing and needs to be defined.
Disagree
The SDT expanded Requirement R18 of TOP-002-2 by adding the term “equipment”. This Requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how. The only real need for a requirement is to establish that each entity issuing a directive shall use three-part communications and the recipient of a directive shall also properly participate in the of use three-part communication protocol until the message has been correctly spoken and understood. LSEs and TSPs do not own or operate equipment, and as such in a market environment should not fall under the mandates of this requirement. Neither the TSP nor the LSE provide or receive information about specific lines or equipment in real-time. Therefore, requirement R7 should not apply to them absent clear evidence that a realistic (not hypothetical) threat to reliability would exist if they are omitted. We do not think that such a threat would exist.
Disagree
This proposed communication protocol is redundant to Requirements R2-R7, and should not be included in this Standard. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions. The NERC BOT has approved pursuing the Results-based Reliability Standard Task Force’s recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to eliminate administrative requirements. This proposal takes the opposite approach and incorporates a new administrative requirement. The industry as a whole, based on the response to the Task Force, does not support such an approach. This Requirement should be deleted from the Standard. There is no need to create a CPOP that includes requirements R2 through R7 given that each requirement spells out how and what is to be communicated. A CPOP may be needed for Interoperability Communications that are not addressed in R2-7.
Disagree
It is not clear what value there is in identifying these alert levels. There does not appear to be any differentiation in actions taken based on the alert levels. Just stating the severity and details of the incident should suffice. Further, the “pre-defined” system conditions and alert levels are too detailed and overly prescriptive. System operators will need to spend time looking for the right color and level to communicate the prevailing system condition terminology to avoid violating the standard. This task does not lend itself to promptly and effectively deal with the emergency situation. The level(s) identified in the notification text are at odds with the condition (color versus numerical). Suggest that the standard either use Condition (color) or the level (numerical). Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the listed entities such as Distribution Provider and Generator Operator cannot have access to these systems due FERC standards of conduct requirements. Attachment 1 and R2 are not consistent with the definition of Interoperability Communications. By definition, Interoperability Communication pertains to all communications about how entities change the state of the BES (not just physical or cyber attacks). Attachment 1 is about notifying of what physical and cyber attacks have already happened to the BES. It is not clear in the context of Interoperability Communications what the recipient of a specific notification is expected to do when there is a change of state or status of an element or facility of the Bulk Electric System. Attachment 1 pertains specifically to Operating State Alert Levels and says nothing about the communication of information to be used to change the state or status of a BES element or facility (which is the SDT’s proposed definition of Interoperability Communications). Therefore, it is not appropriate to require that all verbal and written Interoperability Communications use the pre-defined terminology in Attachment 1. Only those communications concerning Operating State Alert Levels should be required to use that terminology. By the proposed definition, such communications are not Interoperability Communications since the information is not used to change the state or status of a BES element or facility. The SDT needs to revise this requirement to clarify that it pertains only to communicating the Operating State Alert Levels and nothing more. None of the examples in either of the attachments appear to address EEAs (EEA is mentioned in the top paragraph of page 9 that is included in EOP-002-2.1) or SOLs. This limits the use of Interoperability Communications to only events where there exists either a physical or cyber threat, or where an IROL can’t be mitigated. The requirements should focus on what is required, not how. The RC and encompassed entities should be required to define terms that will be used in communications. This would allow for the use of terms that are well understood in an area, rather than having to add new terms. The Background Information in this Comment Form introductory section mentions “The SDT proposes four system condition alerts instead of initial three in the RCWG version.” However, Attachment 1 only mentions 3 alerts – Physical Security, Cyber Security, and Transmission Emergency Alerts leading to confusion.
Disagree
There is no reliability need to use a common time zone for communications. There is already a requirement to use hour ending for scheduling purposes, inadvertent accounting, CPS and other standards where needed. There is no additional reliability need to use a common time zone. The time zone should be identified in the communication. Not only does this requirement attempt to determine HOW entities operate within their various footprints, it would significantly change the way many markets are structured. To implement this into existing Markets would cost significant time, money and resources while not enhancing reliability in these areas. When operating across time-zones, simply referencing “Central Standard Time” or “Eastern Standard Time” is sufficient for operating entities to reliably operate. The time zone adopted by the respective Reliability Coordinator (RC) and their area control center, e.g., NYISO Eastern Standard Time (EST), should be used. If each entity in the area and the RC are all using EST (or daylight savings), then why would a time zone be used that is foreign to all parties in the area? This can lead to considerable confusion. What cannot be ignored is how many entities would have to modify their existing practices, hardware, software, Control System, billing systems, bidding systems, etc. We are strongly opposed to this requirement. The requirement should be that those entities which need to communicate and are in different time zones define which time they will use for communications. Any confusion about what time is being verbally communicated should be cleared up through three-part communications. There should be no confusion about what time is being communicated as long as the time zone (where applicable), and the 24 hour format designations are included. Besides, many entities exchange written information via web-enabled applications that allow the users to configure their interface to show time in whatever format and time zone they prefer. This eliminates confusion.
Disagree
Based on the definition of Interoperability Communications, R5 implies that three-part communications is required to communicate routine operating instructions, or during operational strategic discussions as well as other “non-action” oriented communications. This Requirement contradicts the work that has been done and substantially progressed through two other SDTs and creates confusion within the industry. This Requirement would, in fact, be adverse to reliability instead of enhancing reliability by reducing the amount of pre-action communications that may occur prior to taking action because operators may be more concerned with not repeating back during such pre-action, strategic calls and/or discussion. The work being done by the RC SDT and RTO SDT in Project 2006-06 defines a Reliability Directive based on the determination of the person giving such an order. The entity that needs the action to be taken should establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger, auditable, and measureable. R5 is not consistent with the Functional Model. Only the RC, BA, and TOP can issue directives. Outside of allowing the individual who NEEDS the action to be taken, this is an auditable or measureable requirement whether it be for 3-part communications or for the receiving entity to actually take said action. By definition, Three-part Communications presumes the second party will repeat the information back “correctly.” Failure to do so is assigned a High VRF and a Severe VSL. The practical application of Three-part Communication involves a sender communicating information, a receiver repeating back the information, and the sender verifying the repeat back is either correct or incorrect. If the repeat back is incorrect, the process repeats until both parties have the same understanding of what is being communicated.
Disagree
While this Requirement may represent a good utility practice in certain situations, it is not necessary to be used in all verbal Interoperability Communications, and is certainly not necessary to be included as an enforceable Requirement. For example, a situation in which an operator says “A as in apple” instead of using the NATO Alpha. Even though the listener should clearly be able to discern the correct meaning, the speaker’s company could be sanctioned even if the correct actions were taken as a result of the clear communication. The objective of good communications is to assure that the parties understand each other. The statement “… shall use the NATO phonetic alphabet” doesn’t make sense for North America. If the Real-Time Operator states “breaker 6-North,” under the NATO phonetic alphabet that would be unacceptable, because the operator did not use the appropriate NATO term “breaker 6-November,” even thought the “N” on the one line diagram refers to the “North” breaker and not the “South” breaker. Many organizations may have established communications protocols which are working well. Making a change may actually hinder reliable operations by introducing unnecessary confusion and questioning. Not only does this requirement attempt to determine HOW entities operate with their various footprints, it may change the way many Markets are structured. What is the difference between using the word “Zebra” instead of “Zulu” to signify the letter “Z”? And, why would this be enforceable. Perhaps this should be a guideline document rather than an enforceable Requirement. There is no reliability need for this Requirement.
Agree
 
Agree
It is not clear what value is realized by declaring an alert status particularly with regard to cyber and physical attacks. There do not appear to be any differing actions taken based on the alert status. Given that no differing actions are taken for cyber and physical attacks, it seems it would be more beneficial to use specific information, for example 12 substations have been physically or cyber attacked. This is more meaningful than issuing a red alert that would only indicate more than one site has been attacked. Furthermore, we question the value of communicating the physical and cyber alerts. How does this notification help the BES reliability? Consider the following example. One BA in Oklahoma is 34,323 sq miles. Communicating that an attack occurred in the BA and RC tells other operators that somewhere in Oklahoma an attack occurred. This notification does not present any information that could require actions on the operators’ parts, and will only generate phone calls for more information. Furthermore, PSE and CSE is a type of sabotage already reported in CIP-001 R2. TEA Alerts are already covered in IRO-006-East-1, IRO-009, IRO-010, IRO-014.01 R2. Also it has been the experience of several entities during the field test of these Alert Levels that there are inconsistencies as to when to implement various stages of Alerts, and this introduces more confusion than exists today. Reliability has not been enhanced. Attachment 1 contains a conflict. The last sentence of the opening paragraph of Attachment 1 reads, “The time frame for declaration of these Alert states shall be consistent with the approach used to declare EEAs and would normally apply to Real Time declarations and not forecast conditions.” In Transmission Emergency Alerts Condition Yellow, Orange and RED: The Reliability Coordinator or Transmission Operator foresees or is experiencing conditions where all available generation resources are committed to respect the IROL and/or is concerned about its ability to respect the IROL. Foresees is a forecast condition. There is an inconsistency between the inclusion of Attachment 1 and what is stated in the document posted with the standard entitled Disposition of Requirements Identified in the SAR for Operations Communications Protocols as Possibly Needing either Modification or Movement. The document states that the standard focuses on “how to” communicate rather than on specified scenarios of “to whom” or “when to” communicate; however, Attachment 1 does just the opposite. In condition Orange and Red for TEA Level Two/Three, the initial notification requirements are redundant with IRO-006-East-1 R3.2. Under the Make Final Notifications, is curtailed intended to mean canceled or terminated? The term Curtailed in operations generally means cuts for schedules/tags. EEA’s use terminated. Terminated is the preferred term. Distribution Service Providers should be Distribution Provider to be consistent with the Functional Model. Refer to the response to Question #4.
Agree
Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the parties such as Distribution Provider and Generation Operator cannot have access to these systems due FERC standards of conduct requirements. Requirement 2 and the listing of functional entities required to be notified within the RC footprint in Attachment 1 creates a de facto requirement for them to have RCIS access or an unnecessary burden to communicate with all functional entities listed separately. Having to communicate to all functional entities in that list verbally and individually would create that unnecessary burden, and distract the RC from actual system operation. This is a detriment to reliability. Some ISO/RTOs have market rules which allow participants to elect NOT to follow instructions issued by their market operator (who may also perform BA, TOP and/or RC entity functions) unless an Emergency exists. In the Province of Québec, the use of French is mandatory, according to law, for communication within the Province. R3 should include: Within the Québec Interconnection, the French language shall be used for verbal and written interoperability communication between entities (RC, BA, TO, TOP, GOP, TSP, LSE and DP). For their interoperability communication with entities outside of the Québec Interconnection, they shall use the English language.
Agree
In some market structures, TSPs and LSE do not own or operate equipment. Thus, including them in the requirements is an unnecessary burden for these areas. The requirement to use CST attempts to determine HOW entities operate within their various footprints and it would significantly change the way many Markets are structured. To implement this into existing Markets would cost significant time, and resources while not enhancing reliability in these areas. When operating across time-zones, simply referencing “Central Standard Time” or “Eastern Standard Time” is sufficient for other operating entities to reliably operate. Many entities would have to modify their existing practices, hardware, software, Control System, billing systems, bidding systems, etc. We are strongly opposed to this requirement.
Agree
The existing standard COM-002 is better than this proposed Standard. This Standard actually causes more confusion and ambiguity, and creates unnecessary or overly cumbersome requirements that add little or no value to reliability. All requirements with the exception of R1 have been determined to have a HIGH VRF, when many of them are dictating HOW communications should take place and not when, why, or what. COM-002 retirement does not appear to be consistent with the direction of the RC SDT in Project 2006-06. The RC SDT is adding requirements. More coordination is required between the Standard Drafting Teams. Again, we support the work being done by the RC SDT and RTO SDT and do not believe this adds more necessary requirements. Many of the requirement proposed in this posting either reiterate the drafts as posted (i.e. English language) or introduce confusion when compared to the drafts as posted. The SDTs should limit their scope to R2 and R7, so as not to duplicate or contradict the on-going work of other SDTs. The SDT appears to have adopted severe violations for every infraction. There should be some gradations, using increasing severity based on the number of or severity of any infractions. Definitions: The standard should define other terms, as well, including the following: • reliability-related information, • “… state or status of an element or facility of the BES …” The standard should also have provision to include the boundaries (components) of an “element,” and the meaning of the terms “state or status” in the written communication protocol. For example, is the gas compressor of a 345kV breaker considered part of this element, and so would a change in its “state or status” be covered? Similarly, is the heat trace inside a 345kV breaker control cabinet part of this element or not? The VRFs for R2-R7 are all “High”, and the VSLs are all “Severe” are too harsh. Failing to comply with one of the requirements does not automatically mean that a miscommunication occurred that caused a reliability problem. There should be a “Moderate” VSL for failure to comply with a requirement, but no miscommunication occurred. There should be a “High” VSL for failure to comply with a requirement that caused a miscommunication but resulted in no violation of another reliability standard. The “Severe” VSL should only apply to failures to comply with a requirement that caused a miscommunication that lead to a violation of another reliability standard, or caused a reliability problem. In addition, as stated earlier, this Standard focuses on “how” certain tasks should be performed and conflicts with NERC’s position of pursuing performance based and results based Standards. Based on these considerations, work on this Standard should be stopped until work on Project 2006-06 has been completed and approved. This approach is consistent with the August 2003 Blackout Recommendation #26 “failure to identify emergency conditions and communicate that status to neighboring systems, and upgrade communication system hardware where appropriate” which actually focused on communications during emergencies, which is the scope of Project 2006-06. After Project 2006-06 is completed, a determination can be made on the disposition of this Standard. This Standard should be effective uniformly continent-wide.
Group
SERC OC&SOS Standards Review Group
Margaret Stambach
Disagree
We feel that the definition of Interoperability Communication is much too broad and is inconsistent with the effort to develop results-based standards. Adherence to such results-based standards would have a measurable and observable effect on the reliability of the bulk electric system. The definition of Interoperability Communication, as written, can include virtually any information exchange/instruction between entities, both routine and emergency. Such communication may or may not have a measurable and observable effect on bulk system reliability. The concern is that, since the broad term Interoperability Communication is used in every requirement in COM-003-1, entities will be required to use the English language, the central time zone, and 3-part communication in even the most routine exchanges of information. This could create a burden on operating personnel and a distraction from their reliability duties. This group does not feel the need for a definition of Interoperability Communication, since the term Reliability Directive has been defined in draft standard COM-002-3, which is currently posted for review. The Reliability Directive term is emergency-focused and consistent with the results-based standards process. In addition, the definition of Three-part Communication in this standard does not match the three-part communication requirements stated in COM-002-3. In COM-002-3, the requirements for three-part communication (state – repeat - acknowledge) apply to Reliability Directives, while in COM-003-1 the definition of Three-part Communication refers to “information” in general. If, as stated in the Disposition of Requirements, the revisions to COM-002-3 will be moved to COM-003-1, the definition of Three-part Communication in this draft standard should be consistent with the requirements of COM-002-3.
Disagree
TSPs and LSEs are not typically included in real-time communications and should not be included in COM-003-1. The intent of requirement R18 in TOP-002-2 pertained to communications between neighboring BAs and TOPs. Adding LSEs and TSPs to the applicability of this standard doesn’t make sense, and this change should not be made.
Disagree
This group feels that there should not be a requirement in the standard to have a “procedure”. It is our understanding that, to be auditably compliant with a standard, the responsible entity must develop a procedure, train on that procedure, and be able to demonstrate compliance via documents, data, logs, records, etc. If Requirements R2 – R7 are included in this standard, the entity will need to develop a procedure to be compliant. Therefore, we feel that requirement R1 is redundant and should not be included.
Disagree
The Alert Level Guides in Attachment 1 are not consistent with the proposed definitions of reliability-related communications. Both the Reliability Directive and Interoperability Communication, as currently defined, require some emergency action or change of equipment status. Yet the Alert Level Guides were intended for announcement, not actions. Requiring system operators to use the color-coded system condition terminology during communication adds a layer of responsibility that will distract from the operator’s real-time reliability-related tasks. We do not feel that these Alert Level Guides apply to all the responsible entities identified under Applicability in the draft standard – for example, TSPs and LSEs are not included in the list of notifications. There is also some redundancy in the Alert Level Guides – for example, the CIP-001 standard requires notification of sabotage events – it should not be repeated in this standard.
Disagree
We feel that this requirement of a common time zone is overly prescriptive. The requirement should be that entities operating in different time zones agree on how to best eliminate any confusion regarding the time difference. Entities that routinely operate in different time zones already have an effective system for dealing with time differences. There seems to be no incentive to change a system that already works quite well, and the cost of updating computer systems could prove prohibitive. For instance, the requirement to use the central time zone for logging the time of an alert is problematic in that all communication tools, such as the RCIS, will need to be re-vamped. We question whether there will be a measurable reliability benefit by so doing. This group feels that mandating a common time zone across all of North America can only lead to confusion and increased reliability issues.
Disagree
As suggested in Question 1 above, the term Reliability Directive (as defined in COM-002-3) should be used in place of Interoperability Communication, since the directive is specific to emergency operations. The requirement should read: “Each responsible entity shall use Three-part Communication when issuing a Reliability Directive”. In addition, this requirement should apply only to BAs, TOPs & RCs. The other entities listed in the draft standard under Applicability do not issue Reliability Directives.
Disagree
First, please note that “NATO” does not stand for North American Treaty Organization; it stands for North Atlantic Treaty Organization. Use of the NATO phonetic alphabet should be considered a “best practice” and should not be included as a requirement in a reliability standard. One failure, such as saying “Baker” instead of “Bravo”, results in a severe violation without any impact on system reliability. This group is concerned that operating personnel will be focused on using the correct word rather than managing the power system.
Disagree
Requirement R7 in draft COM-003-1 came from TOP-002-2, Requirement R18. The original requirement intended that neighboring Balancing Authorities use uniform line identifiers when communicating information about their tie lines. This requirement drops that clarification and introduces the additional requirement to use pre-determined “equipment” identifiers. Having to mutually agree in advance on identifiers for every switch & transformer is another example of a prescriptive requirement whose violation will not affect system reliability, yet will expose entities to large fines.
Agree
Our concern is that the Alert Level Guides of Attachment 1 were written for Reliability Coordinators, not the industry as a whole, and now they are being incorporated into an industry-wide standard. This attachment is very prescriptive as to how the notifications take place, such as through the RCIS. If the RCIS is not functioning and the hotline is used instead, is the entity vulnerable to a violation by virtue of the fact that these alert guides are included in the standard? We believe that the color-coded system condition terminology should be defined/required externally to the COM standards. The use of clear & consistent alert level terminology, while important, does not fit in well with the reliability-related communication standards, especially at these high violation severity levels. It is our suggestion that the Alert Level Guides be balloted separately, and include the Energy Emergency Alerts (EEA) as well. EEA requirements currently exist in NERC Standard EOP-002-2.1
Disagree
No, we are not aware of any regional variances.
Agree
We do see a potential conflict with the Energy Policy Act of 2005, which set the framework for the Electric Reliability Organization (ERO). The ERO’s mission is to oversee and protect the reliability of the Bulk Electric System. This standard seems to cross the line between reliability-related activities and other types of operating actions. The concern here is that system operators will focus on the letter of the standard rather than on good operating practice. The fear of a violation among operators may have a greater impact on reliability than the violation itself.
Agree
This review group has identified several problems with this standard, as noted above. Other observations include: The effective dates in the draft standard and in the implementation plan do not seem to match. In the standard, the effective date mentions one calendar year following regulatory approval, while the implementation plan refers to the third calendar quarter after regulatory approval. Furthermore, we do not feel that any of the requirements in this standard warrant Violation Risk Factors or Violation Severity Levels in the high or severe category. In summary, this review group feels that COM-003-1 is not yet ready to be acted upon and may have been posted too soon. There does not seem to be sufficient coordination between the drafting teams of all the COM standards, or any attempt to integrate these standards. One example is the inconsistency between COM-003-1 and COM-002-3 regarding the meaning of three-part communication (mentioned in our response to Question 1 above). As noted above, we feel that many of the requirements prescribe specific “how to” methods for compliance rather than focusing on the “what” of the requirement. Overall, COM-003-1 is much too prescriptive to be tied to million dollar-level fines. “The comments expressed herein represent a consensus of the views of the named members of the SERC OC&SOS Standards Review group only and should not be construed as the position of SERC Reliability Corporation, its board or its officers.”
Individual
Jonathan Appelbaum
Long Island Power Authority
Disagree
LIPA disagrees with the definition for Three-Part Communication. LIPA prefers the process offered in COM-002-03 (draft). In COM-003 the listener must understand the communication the first time. Failure to understand and repeat back correctly could be a violation of the requirement. The intent three part communication is to have an iterative process whereby the person issuing the message is ultimately satisfied that the recipient understands the information and will perform the required action. It should not be defined as three steps and only three steps. LIPA offers the following definition: A Real-Time Operating Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back to the party that initiated the communication by the second party that received the communication, and the information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it. LIPA disagrees with the definition of Interoperability Communication. LIPA believes the Standard is addressing the communication of the Operating State of BES equipment and facilities. The proposed definition utilizes the phrase “change the state … of a BES facility” which can be interpreted as the position, e.g. open, close, tap position, etc… thereby extending this Standard into routine switching and operation of the BES. The SAR stated this Standard was “to use specific communications protocols under normal, abnormal and emergency conditions to relay critical reliability-related information in a timely and effective manner”. The proposed definition can be interpreted in a manner that extends this to all reliability related information for every BES operation. The drafting team should also consider adding a definition for Directive or acknowledge the definition in draft Com-002-03.
Agree
 
Disagree
LIPA agrees with the need for CPOP but does not agree that R4 can or should apply to all interoperability communications between entities. Since the examples in Attachment 1 specifically state RC and TOP, this standard should not apply to any other entity except for the RC and TOP. COM-002-03(draft) could require the other entities to utilize three part communication for reliability-related Interoperability communication.
Disagree
LIPA believes the use of “shall” and “all” coupled with the broad applicability of this Standard and the broad definition of Interoperability Communication will result in entities either not complying with R2 or making statements regarding the Operating Alert State when unnecessary. Attachment 1-Com-003 is very prescriptive in the use pre-defined terminology, colors and levels, and what to report on. There is no benefit to specifying the specific terminology. This requirement should require the RC to define the terms/levels/alert states to include within the CPOP that sufficiently communicate the increased levels of Alert or Response encountered/required. Many entities have invested time and training in the existing processes that meet the intent of this requirement. Read strictly, the only predefined alert conditions are Physical security, Cyber security and Transmission Security as it applies to the RC and TOP only. LIPA notes that R2 in the draft Standard does not match R2 in this question. Specifically the word ALL is not in the Standard.
Disagree
This requirement will burden those entities whose operations and communication needs are with other entities in the same time zone, which represents the overwhelming majority of all communications performed. It will increase the likelihood of errors for such entities. Further, some entities are operating both NERC BES elements and non-BES elements from the same control room. This requirement will significantly impact the efficiency and the safety of workers within those entities. LIPA notes that R4 in the draft Standard does not match R2 in this question. Specifically the word ALL is not in the Standard.
Disagree
The SDT should define Directive. Draft Com-002 -3 has a similar requirement to identify a directive and then utilize three-part communication. Also Com-002-3 Three part communication differs from the description of Three-part communication in this Standard. LIPA prefers Com-002-3 usage of the word “intent” in the repeat back. Also see comments to Question 1.
Disagree
While LIPA understands the benefit of utilizing a phonetic alphabet, we question the designation of a specific phonetic alphabet. This prescriptive requirement may result in absurd non-compliance reports, such as, using “Dog” for “D” instead of “Delta”. R6 requires the use of the alphabet when issuing information, but not in the repeat back step. This may be an oversight. Also Does the RC in its communication utilize the abbreviation for the threat type, e.g PSEA, or does the RC use the NATO-Alphabet? If NATO, then the example in Attachment 1 should state this need.
Agree
LIPA notes that R7 in the draft Standard does not match R2 in this question. Specifically the word ALL is not in the Standard.
Agree
In addition to the response to Question 4, LIPA does not understand why there are Levels and color designations since only the threat level numeral is being communicated. Attachment 1-Com-003 is very prescriptive in the use pre-defined terminology, colors and levels. There is no benefit to specifying the specific terminology. Requiring system Operators to state Colors and Levels would seem to result in slower and more confused communication.
 
Disagree
 
Agree
R1 requires each entity to create a CPOP. There is not a requirement to coordinate CPOP’s amongst entities beyond the requirements in the Standard. There is no requirement to exchange CPOP’s between entities with an operating relationship. The SDT should consider adding a requirement either that allows entities with operating relationships to request and be provided a copy of the other’s CPOP, or a requirement requiring the exchange of CPOP between entities with operating relationships. Additionally, we cannot understand how all requirements but R1 have been determined to have a HIGH VRF when, many of them are dictating HOW communications should take place and not when and why or what. High Risk Factor requirement (a) is one that, if violated, could directly cause or contribute to bulk power system instability, separation, or a cascading sequence of failures, or could place the bulk power system at an unacceptable risk of instability, separation, or cascading failures. LIPA does not believe that any requirement in this Standard if violated would have the results specified in the definition of a High VRF, especially since these requirements are addressing the HOW of communication.
Group
Pacific Northwest Small Utilities Comment Group
Margaret Ryan
Disagree
Communication protocols extend beyond the verbal and written versions. How does the “non-routable (communication) protocol” of CIP-006 fit into or not fit into these definitions?
Our utilities agree with the move in principle, but are concerned about the transition. How will NERC ensure that registered entities are not doubly jeopardized during the time when the same requirement exists in two active standards? The addition of LSE to COM-003 goes way beyond the obligations in TOP-002-2 R18; LSE’s are now in every requirement of COM-003.
Disagree
DPs and LSEs are in general users, not owners or operators of interconnected BES equipment per the registry criteria. DPs and LSEs should be removed from this requirement since LSEs typically do not own or operate the interconnected BES equipment
Disagree
The referenced attachment appears to list alert levels for RCs to use in communicating threats to BAs, DPs, GOs, TOPs and TOs. This requirement should apply only to RCs.
Disagree
While our utilities agree that understanding the actual time is important, stating the time zone and summer offset (13:34 PDT) should suffice. As an alternative, UTC might be used since it is clearly distinguishable from local time in all of NERC. As in R1, LSEs and DPs should be removed from this Requirement.
Disagree
Per TOP-001 and IRO-001, only TOs and RCs have the authority to issue reliability directives (per the proposed definition of interoperability communications, such directives would qualify as reliability directives). All other entity types should be removed from this requirement. As in Q2, the transition is a concern. Unless the effective date of COM-003-1 is the same as the date of retirement of COM-002; there will either be a reliability gap where neither active standard requires three-part communication, or there will be a situation where an entity could be doubly jeopardized for a single event. Three-part communication is worthless unless the recipient understands what he/she is parroting and is authorized to take action. For example, many DPs/LSEs do not maintain 24/7 dispatch desks and an afterhours call may go to an answering service. Three-part communication with the answering service operator will only delay the requested action. The entity issuing the directive should be required to ensure their employee reaches someone authorized to take action before delivering the directive via Three-part communication.
Agree
No Comment
Disagree
DPs and LSEs are typically users, not owners or operators of interconnected BES equipment per the registry criteria. DPs and LSEs should be removed from this requirement.
Disagree
 
Agree
(This is a yes or no questions) Yes, The RC in the WECC region has no communication with any entity other than the sixteen listed in http://www.bpa.gov/corporate/business/reliability/Docs/2007/PNSC_RE_Data_Letter_2_070723.pdf. Although the linked document is on PNSC letterhead, WECC as RC continues this policy. Communication paths involving the RC and any other entity in the west other than the sixteen should be exempt from all the requirements in this standard. If DPs and LSEs must be included in this standard, then there should be an agreement in force beforehand between them and their RC, BA and TOP that they may receive directives, or require the RC, BA and TOP to list those DPs and LSEs that would not receive directives.
Agree
(This is a Yes or No Questions) Yes, see our comments to Q2.
Agree
(This is a Yes or No Questions) The proposed standard seems to have just thrown everyone into the pot, and not considered how registered entities interact with the BES or what other standard requirements apply to them. We can not lose sight of the original objective of, not only ERO Compliance, but the “purpose” described in regards to the development of this standard (Posted as background information on Project 2007-02). The stated purpose is, “To ensure that reliability-related information is conveyed effectively, accurately, consistently, and timely to ensure mutual understanding by all key parties, especially during alerts and emergencies.” With this said, The BA’s, TOP’s and RC’s are the key registered entities that have the power to take action, they are the key players in the communication of information which “impacts” the BES. We fail to see the value added by including DP’s and LSE in most of the requirements of this standard. If anything, we see the opposite affect taking place by adding DP & LSE’s. This may be an extra tier of unnecessary communication that would not only slow down this process, but just may contribute to greater inefficiencies. Please note that many DP & LSE in the WECC region are very small utilities that do not have 24 by 7 coverage.
Individual
Richard Appel
Sunflower Electric Power Corp.
Disagree
I feel the use of the NATO phonetic alphabet is over kill. You should use a phonetic alphaber that is in common use in the USA
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
I don't feel we should use NATO phonetic alphabet. Use something in common use in the USA
Agree
 
Use a Phonetic alphabet in common use in the USA
 
 
 
Individual
Kevin Koloini
American Municipal Power
Agree
Please define "directive" as a term.
Agree
 
Disagree
A written CPOP will place an unnecessary burden on smaller entities without an increase in reliable communications. I feel that the other requirements are somewhat self-explanatory and that an annual review of the phonetics and three-part communications would improve reliability more than having a written CPOP requirement.
Agree
Eliminating lax communications and improving identifiers is one of the cheapest and easiest ways to improve reliability.
Disagree
In other large industries one time zone is usually picked, and the time zone that is usually picked is the EST zone (JP Morgan Chase is an example). I feel that picking a standard time zone is very important, but I have not seen significantly good arguments to use CST. EST, on the other hand, is where the majority of the load for the electric industry resides. I suggest changing the standard to EST but with the 24 hour format.
Agree
I feel that there needs to be a way to verify what has been said. Three-part Communications accomplish the verification that may be required as a result of the communication medium. If a better method is developed I propose that it be used.
Agree
The NATO Phonetic alphabet is easy to learn and use. Most people can learn it on their own much faster than it will take the SDT to read all of the comments for COM-003.
Agree
How many substations have the same name? Unique identifiers easily and inexpensively eliminate confusion and errors.
Agree
 
Agree
 
Agree
 
Agree
 
Individual
Edward Bedder
Orange and Rockland Utilities, Inc.
Disagree
Clarification must be made to the definition "Interoperability Communication" and to the specific applicability of the term as it translates into the actions and functions both internal and external to the local TO.
Agree
 
Disagree
R4 - Use of the CST time format would present challenges affecting hardware, software, and training in the ECC and is counter to practices of scheduling, switching execution, and time-stamping of activities currently executed by the ECC. A more defined definition of “Interoperability Communications” needs to be instituted in conjunction with R4 applicability.
Agree
 
Disagree
Use of the CST time format would present significant challenges as expressed in the comments of question #3 listed above.
Agree
 
Disagree
 
Agree
 
Disagree
 
Disagree
Not aware
Disagree
Not aware
Disagree
No additional Comments
Individual
Noman Williams
Sunflower Electric Power Corporation
Agree
 
Agree
 
Disagree
We believe that distribution providers (electric cooperatives) should be removed from this standard unless they control a BES segement
Agree
As defined in Attachment 1 - COM-003-1
Agree
General question will time follow central prevailing time (standard/daylight savings)?
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
 
Disagree
 
Disagree
 
Individual
Mark Ringhausen
Old Dominion Electric Cooperative
 
Disagree
Comments: We believe that it may be important for entities registered as a Reliability Coordinator, Balancing Authority, Transmission Owner, Transmission Operator, Generator Operator, Transmission Service Provider , Load Serving Entity and Distribution Provider to have a formalized Communications Protocol Operating Procedure (CPOP) for Interoperability Communications, but this requirement will place an unnecessary burden on the personnel at many of the smaller Load Serving Entities and Distribution Providers on the NERC Compliance Registry. In most real-time scenarios, the BES facilities are not operated nor maintained by the Load Serving Entity or Distribution Provider. As with many standards, entities will be required to demonstrate why the standard/requirement is applicable. We suggest the drafting team consider modifying the applicability of this standard as follows similar to the format used in PRC-OO5: 4. Applicability: 4.1. Transmission Operator 4.2. Transmission Owner 4.3. Balancing Authority 4.4. Reliability Coordinator 4.5. Generator Operator 4.6. Distribution Provider that is responsible for Real-time generation control and Real-time operation of the interconnected Bulk Electric System 4.7. Transmission Service Provider 4.8. Load Serving Entity that is responsible for Real-time generation control and Real-time operation of the interconnected Bulk Electric System
Disagree
Comments: We believe that it may be important for entities registered as a Reliability Coordinator, Balancing Authority, Transmission Owner, Transmission Operator, Generator Operator, Transmission Service Provider , Load Serving Entity and Distribution Provider to have a formalized Communications Protocol Operating Procedure (CPOP) for Interoperability Communications, but this requirement will place an unnecessary burden on the personnel at many of the smaller Load Serving Entities and Distribution Providers on the NERC Compliance Registry. In most real-time scenarios, the BES facilities are not operated nor maintained by the Load Serving Entity or Distribution Provider. As with many standards, entities will be required to demonstrate why the standard/requirement is applicable. We suggest the drafting team consider modifying the applicability of this standard as follows similar to the format used in PRC-OO5: 4. Applicability: 4.1. Transmission Operator 4.2. Transmission Owner 4.3. Balancing Authority 4.4. Reliability Coordinator 4.5. Generator Operator 4.6. Distribution Provider that is responsible for Real-time generation control and Real-time operation of the interconnected Bulk Electric System 4.7. Transmission Service Provider 4.8. Load Serving Entity that is responsible for Real-time generation control and Real-time operation of the interconnected Bulk Electric System
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
 
 
 
 
Individual
Misty Revenew
Westar Energy
Disagree
Would like to see the Interoperability Communication definition be more specific.
Agree
 
Disagree
While I agree that a CPOP in necessary and should include the elements of the requirements, I am not sold on all of the requirements yet as written.
Agree
 
Agree
 
Agree
 
Disagree
One of the more common or ad-hoc phonetic alphabets which are easier to remember could be a better fit since these communications happen infrequently. Having operators potentially struggle to remember the NATO phonetic alphabet during communications rather than focus on the communication itself is in contradiction with the stated purpose of the standard.
Agree
 
Agree
no suggestions
Agree
not aware
Agree
not aware
Agree
no additional comments
Group
ExxonMobil Research and Engineering
Martin Kaufman
Agree
 
Agree
 
Disagree
While recording telephone conversations may be routine for utility companies, many industrial facilities that fall under the jurisdiction of this standard do not currently have the facilities necessary to record the conversations and store them for an extended length of time. If a company does not currently possess the capability to record telephone conversations, is it the intent of this standard to require them to install such facilities? If so, what is the time frame surrounding the installation of the facilities necessary to record and store telephone conversations? Currently, we maintain a log of our communications which includes the question or instruction and our (or in the case of a question the third party’s) response. Does this satisfy the requirements for evidence as defined in measures M2 through M7?
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
We have no concerns or suggestions for improvement.
Disagree
We are not aware of any regional variances that would be required as a result of this standard.
Disagree
We are not aware of any conflicts.
Agree
Compliance paragraph 1.4 bullet 2 implies that all entities retain 3 months worth of telephone voice recordings through its use of the word ‘and’ in the statement “Distribution Provider shall retain for Requirement 2 through 7, Measure 2 through 7, dated operator logs for the most recent 12 months and voice recordings or transcripts of voice recordings for the most recent 3 months”. While many utility companies employ the use of voice recorders, many industrial facilities do not. When a facility does not currently employ the use of voice recorders, is it the intent of this document to require the facility to install the infrastructure necessary to record and store telephone conversations? If so, what is the time line for deploying the infrastructure necessary to record and store telephone converstations? Currently, we maintain a log of our communications which includes the question or instruction and our (or in the case of a question the third party’s) response. Does this satisfy the evidence criteria as defined in measures M2 through M7 of the proposed standard?
Individual
Bob Casey
Georgia Transmission Corp
Disagree
The definition of Interoperability Communication is very broad and has no real benefit.
Agree
 
Disagree
This is a requirement for an operating procedure which is redundant and would require the entities to document how they met the requirement.
Disagree
Should only include physical security emergency, cyber security emergency, or transmission emergency as stated in Attachment 1 instead of Interoperability Communications.
Agree
 
Disagree
replace “directive during verbal Interoperability Communications” with “Reliability Directive”. replace "Each Responsible Entity" with "TOPs & RCs". The other entities listed in the draft standard under Applicability do not issue Reliability Directives.
Disagree
This is an operational burden and could easily cause a violation by using a different common identifier. If used, it should only apply to Reliability Directives.
Agree
 
Agree
 
Disagree
 
Disagree
 
Disagree
 
Individual
Tracy Sliman - System Operations Compliance
Tri-State Generation & Transmission Assoc.
Disagree
The term directive is not defined therefore it is unclear what constitutes a directive.
Disagree
LSE and TSP are not responsible for the reliability of the Bulk Electric System. That responsibility resides with the TOP.
Disagree
DP, LSE and TSP are not responsible for the reliability of the Bulk Electric System. Also, attachment 1 explains Operating State Alert Levels that defines colors that are already in use by the Department of Homeland Security. Re-using these colors presents confusion to the operators of the BES. This places an unnecessary additional burden on Real Time day-to-day operations with a high risk of confusion in an emergency.
Disagree
Attachment 1 explains Operating State Alert Levels that defines colors that are already in use by the Department of Homeland Security. Re-using these colors presents confusion to the operators of the BES. This places an unnecessary additional burden on Real Time day-to-day operations with a high risk of confusion in an emergency. Additionally, this is too complicated and requires a complete retraining of operators in the English language.
Disagree
We have been operating within our individual time zones for many years without incident. Modifying the time zone to which we operate will pose additional confusion and add unnecessary risk in operating the BES.
Disagree
Directive is not defined. This would require issuing a directive for each and every verbal communication between entities, even those that pose no risk to the BES, which is not necessary.
Disagree
Directive is not defined. This poses an undue burden on the operators, which does not improve the reliability of the BES. NERC should only concern themselves with issues related to maintaining the reliability of the BES.
Disagree
This is not NERC’s responsibility to define. There are too many lines and too much equipment to identify each as a NERC definition. Definitions are already agreed upon between operating entities.
Agree
The Operating State Alert Levels can be confused with DHS security levels. DSPs should not be included because they are not subject to BES standards because they do not operate the BES, that responsibility resides with the TOP. The title Distribution Service Providers should be changed to Distribution Provider to correlate with the NERC functional model. Under Additional Communication the posting of the alert level should be determined by each entities internal procedure and not included in this standard. This attachment is too invasive and restrictive.
Disagree
 
Disagree
 
Agree
This standard should not apply to DPs, LSEs or TSPs as they do not have control over the BES. That responsibility resides entirely with the TOP. Additionally, it is concerning that the term “directive” is not defined. The proposed definition for Interoperability Communication could be interpreted to include all communication between entities. This is too restrictive.
Individual
Joe O'Brien
NIPSCO
Agree
When COM-002-3 is fully incorporated, more definitions such as Reliability Directive will need to be added.
Agree
 
Agree
 
Disagree
This may not be necessary.
Agree
I believe we call this "system time" in our area
Disagree
It's not clear whether this is limited to emergency situations. In the Purpose section of this standard the line "especially during alerts and emergencies" seems rather vague. When does this standard exactly apply?
Disagree
This should not be a requirement, but could be a suggested option. If one were recorded using the wrong phonetic would that be a compliance violation? This doesn't seem reasonable.
Disagree
This question includes a mis-statement in quotes. This is not what the requirement says. Furthermore, the word "Neighboring" was removed from the TOP-002 R18 which changes the meaning and intent of the requirement. Why not bring in R18 verbatim?
Disagree
No comment
Disagree
none
Disagree
none
Disagree
This standard is based on COM-002-3 however that standard has not been voted-in or NERC approved yet. I think this COM-003 effort should be put on hold until the 2006-06 project is complete. At that time the term "directive" should be replaced by "Operational Directive" and "Reliability Directive" based on context and all of these terms should be defined in the NERC Glossary of Terms.
Individual
Joe Knight
Great River Energy
Disagree
GRE believes the proposed definition for the term Interoperability Communication is too broad and ambiguous. We recommend the following instead: Communication between two or more Functional Entities to exchange reliability-related information to be used by the entities to change the state or status of Facilities of the Bulk Electric System. The inclusion of the terms Functional Entities and Facilities removes the ambiguity which we believe is contained in the proposed definition. (Both of these terms are defined in NERC’s Glossary) The way the definition of Three-part Communication is worded applies only when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should rather reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it. GRE believes there should be a definition added for Reliability Directive to ensure consistency across the defined projects for standards development. The Drafting Team working on Project 2006-06 has defined Reliability Directive as: A communication initiated by a Reliability Coordinator, Transmission Operator or Balancing Authority where action by the recipient is necessary to address an actual or expected Emergency. GRE recommends use of this definition and the term Reliability Directive as opposed to Directive.
Disagree
TOP-002_R18 is fundamentally different from the new proposed requirement in COM-003-1_R7. TOP-002 R18 states that the BA, TOP, GOP TSP and LSE shall use uniform line identifiers when referring to transmission facilities of an interconnected network. COM-003-1_R7 states that each RC, BA, TO, TOP, GOP, TSP, LSE and DP shall use PRE-DETERMINED, MUTUALLY AGREED UPON line and equipment identifiers for verbal and written Interoperability Communications. GRE believes the TOP-002_R18 could be included in COM-003-1 but included as stated verbatim in TOP-002.
Disagree
The NERC BOT has approved pursuing the Performance-based Reliability Standard Task Force’s recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to eliminate administrative requirements. This proposal takes the opposite approach and incorporates a new administrative requirement. GRE does not support such an approach. GRE suggests deleting this Requirement from the Standard.
Disagree
It is not clear what value there is in identifying these alert levels. There does not appear to be any differentiation in actions taken based on the alert levels. Why not just state the number of substations attacked, etc? Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the listed entities such as Distribution Providers and Generator Operators cannot have access to these systems due FERC standards of conduct requirements. Attachment 1 and R2 are not consistent with the definition of Interoperability Communications. By definition, Interoperability Communication pertains to all communications about how entities change the state of the BES (not just about physical or cyber attacks). Attachment 1 is only about notifying of what physical and cyber attacks and transmission emergencies have already happened to the BES.
Disagree
There is no reliability need to use a common time zone for communications. The prevailing time zone should be used to avoid confusion between operating staff and field personnel. Use of CST will actually cause confusion with no foreseeable reliability benefit.
Disagree
Without defining directive the SDT is leaving the industry in the same situation we are currently in. As discussed in the response to Question #1 above, it is GRE’s opinion that the definition of Reliability Directive must be developed and included in the discussion of this standard. The term directive should be as defined in Project 2006-06: A communication initiated by a Reliability Coordinator, Transmission Operator or Balancing Authority where action by the recipient is necessary to address an actual or expected Emergency.. GRE believes it should be left to the entity that needs the action to be taken to establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger and easily auditable and measureable.
Disagree
While this requirement may represent a good utility practice or even a best practice, it is not so necessary to be enforceable through enforceable requirements. The NATO phonetic alphabet does not allow for the use of numbers ten and beyond. An entity WOULD be found non compliant for saying OPEN SWITCH FOURTEEN BRAVO. GRE does not believe this is reasonable as it adds nothing to the reliability of the BES. It is too prescriptive and all encompassing and could potentially confuse or slow down the communication process especially in an emergency situation.
Disagree
See comments for Question 2
 
Disagree
 
Disagree
 
Agree
GRE believes that the existing standard COM-002 is actually better than this standard. This standard actually causes more confusion and ambiguity and creates unnecessary or overly cumbersome requirements that add little or no value to reliability.
Individual
Fred Meyer
The Empire District Electric Company
Disagree
Replace the proposed COM-003-1 definition of "Thee-part Communication with what is used here: Three Part Communication: A communications protocol to be used when a Reliability Directive is initiated verbally, whereby the action to be takein is identified as a Reliability Directive; the recipient repeat the details of the Reliability Directive back to the issuer of the Reliability Directive; and the issuer acknowledges the response from the recipient of the Reliability Directive as correct, or re-issues the Reliability Directive to resolve any misunderstanding.
Disagree
A more efficient method of designation common pre-determined line and equipment identifiers would be through the Reliability Coordinator. Having the Reliability Coordinator establish this would create a single methodology as opposed to several different methodologies that would have to be agreed upon between entities and a significant amount of work for all entities.
Disagree
What benefit to the BES would this provide? Rather I see more confusion by having entities develop different CPOPs. How will this benefit real time operations? This seems to be a requirement by NERC to assist NERC in anaylysis "after the fact" of an event, but in reality it can hinder daily operations.
Disagree
This attachment is not needed. It is a duplicate of the NERC Alert process that is already established as well as CIP-001 Sabotage reporting requirement R2 along with requirements of EOP-001 R5 and EOP-004 R2 dealing with disturbance reporting. The last thing the industry needs is more paperwork requirements that are redundant when an emergency event happens on the system.
Disagree
In dealing in real time, what possible benefit can be had by this requirement? I see this requirement benefitting NERC analysis after the fact and can lead to more operating mistakes in real time than it benefits. If a situation is occuring in real time and two entities are in communication with each other, the requirement of a common time zone holds no benefit.
Disagree
When and why would a GO, TSP or LSE ever issue a directive? Directives are given by RC's. Use the definition of Third Party Communications provided earlier in this comment form.
Disagree
The NATO phonetic alphabet is too descriptive as a requirement. A common phonetic alphabet where both parties understand the communication should be a better requirement and left up to the parties in communication with each other as common across the USA.
Disagree
I would suggest a more efficient method of desinating common pre-determined line and equipment indetifiers through the Reliability Coordinator. As similar to the response earlier. A definition of "Equipment" is needed as well.
Disagree
Again this attachment is redundant to the NERC Alert process.
Agree
NO
Disagree
 
Disagree
This proposed standard seems to be a redundant standard to many other already approved NERC standards such as CIP-001, EOP-001, EOP-004, as well as the NERC alert process. I see little to no benefit from this standard as proposed.
Individual
Ed Davis
Entergy Services
Disagree
The definition for Three-part communication is deficient when compared with the requirements of the recently posted COM-002-3 which describes an interative process in which the communicating party corrects the recipient in the situation where the repeated message contains inconsistencies. The party receiving the message will not always get the message right the first time. Also, Entergy does not believe that the introduction of the term Interoperability Communications is necessary. In the questions below, we identify specific ways that the requirements could be improved by including the term Reliability Directive as included in the recently posted COM-002-3. The term Interoperability Communications is very broad, covering both normal and emergency communications, creates a new category of communications without providing any real benefit to the industry.
Disagree
TSP and LSE are not typically included in real-time communications and should not be included in this requirement. The intent this requirement in TOP-002-2 pertained to communications between neighboring BAs and TOPs. Adding LSE and TSP to this requirement doesn’t make sense, and this change should not be made.
Disagree
Interoperability communications should be removed as recommended in our response to question 1. Creating requirements for the communications protocol will by necessity require entities to document how they meet the requirements. A requirement for an operating procedure is redundant. The requirement to have an operating procedure in effect makes this a “how” requirement. An entity could choose to have more than one procedure that described their communications protocol. This requirement as written could force an entity to put all of their communications procedures into one CPOP, which doesn’t improve reliability. Therefore the requirement is not needed and should not be included in the standard.
Disagree
Term Interoperability Communications should be removed from the standard. As written, the actions that fall into interoperability communications are much broader than the set of conditions described in the table in attachment 1. To the extent that the communications are outside of the ones in the table, entities will be non-compliant because their communications are not pre-defined. Recommend that this requirement be changed to indicate that “Any Reliability Coordinator or Transmission Operator experiencing a physical security emergency, cyber security emergency, or transmission emergency will communicate their status using the conditions and processes in Attachment 1.”
Disagree
This is also a “how” requirement and not a “what” requirement. If the industry believes that confusion exists pertaining to what time zone different entities are referring to in written and verbal communications, the requirement should be focused on ensuring clear communication of time zone information is included in verbal and written communication. Forcing entities to change to any one time zone will impose significant effort and expense without a measurable improvement in reliability. However, Entergy is not aware that reliability issues have occurred as a result of entities communicating in written or verbal format in different time zones. Entergy proposes that this requirement be removed from the standard.
Disagree
Should be rewritten to say that “Each Responsible Entity shall use Three-part Communications when issuing a Reliability Directive.” This should use the definition of Reliability Directive as proposed in project 2006-06. Entergy recommends not including the definition of Interoperability Communications in this standard or in the R5 Requirement. Also, the list of responsible entities listed in the requirement R5 are not all able to issue Reliability Directives. So this requirement should be limited to Reliability Coordinators, Balancing Authorities and Transmission Operators, who can issue Reliability Directives.
Disagree
Entergy has 2 concerns with this requirement as written. First, the use of the NATO phonetic alphabet is overly prescriptive to convey alpha-numeric information. For instance, if I use the word “baker” instead of “bravo” in my communications, I would have still successfully communicated the letter “B” to the person receiving my communication. My communication may have supported reliable interconnected operations. However, according to this requirement, I would still have violated the standard. Second, the requirement as written is very broad, applying not just to directives, but also to “notifications, directions, instructions, orders and other reliability related operating information”. These terms are not defined, so I would assume that this covers Reliability Directives, and everything else. If the industry supports using a phonetic alphabet, it should be limited just to directives containing alpha-numeric information. Again, the requirement to use the NATO phonetic alphabet imposes a significant operational burden, creates a human error trap for operating personnel, and does not improve reliability. It should not be included in the new standard.
Disagree
The requirement as it was written in TOP-002-2 pertained to communication between neighbors for shared lines and facilities. That intent has been lost in this version of the requirement. Also a term “equipment identifiers” has been added, but it is not clear what additional equipment is covered by this requirement, or what reliability concern is being addressed by these changes. Entergy recommends that this requirement be changed to be similar to the language that exists in TOP-002-2 R18 “Neighboring Balancing Authorities, Transmission Operators, Generator Operators, Transmission Service Providers and Load Serving Entities shall use pre-determined mutually agreed upon line identifiers when referring to transmission facilities of an interconnected network.”
Agree
As written, the actions that fall into interoperability communications in requirement 2 are much broader than the set of conditions described in the table in attachment 1. To the extent that the communications are outside of the ones in the table, entities will be non-compliant because their communications are not pre-defined. Recommend that requirement 2 be changed to indicate that “Any Reliability Coordinator or Transmission Operator experiencing a physical security emergency, cyber security emergency, or transmission emergency will communicate their status using the conditions and processes in Attachment 1.”
Disagree
 
Disagree
 
Disagree
 
Group
NRECA RTF Members
Patti Metro
Disagree
Comments: We agree with the new terms for inclusion in the NERC Glossary. We are somewhat concerned that in this version of the draft standard there was no definition for “directive” included. We do understand that the term “directive” is no longer capitalized in this version of the standard, therefore, not required to be included in the NERC Glossary. Since several requirements of this draft standard require certain actions when a “directive” is issued, the term should be defined. It is necessary to define the term “directive” to ensure that just normal conversations between entities are not later “interpreted” to be a “directive”.
Agree
Yes, we believe that the use of pre-determined, mutually agreed upon line and equipment identifiers for verbal and written Interoperability Communications enhances the reliable operation of the BES.
Disagree
We believe that it may be important for entities registered as a Reliability Coordinator, Balancing Authority, Transmission Owner, Transmission Operator, Generator Operator, Transmission Service Provider , Load Serving Entity and Distribution Provider to have a formalized Communications Protocol Operating Procedure (CPOP) for Interoperability Communications, but this requirement will place an unnecessary burden on the personnel at many of the smaller Load Serving Entities and Distribution Providers on the NERC Compliance Registry. In most real-time scenarios, the BES facilities are not operated nor maintained by the Load Serving Entity or Distribution Provider. As with many standards, entities will be required to demonstrate why the standard/requirement is applicable. We suggest the drafting team consider modifying the applicability of this standard as follows similar to the format used in PRC-OO5: 4. Applicability: 4.1. Transmission Operator 4.2. Transmission Owner 4.3. Balancing Authority 4.4. Reliability Coordinator 4.5. Generator Operator 4.6. Distribution Provider that is responsible for Real-time generation control and Real-time operation of the interconnected Bulk Electric System 4.7. Transmission Service Provider 4.8. Load Serving Entity that is responsible for Real-time generation control and Real-time operation of the interconnected Bulk Electric System
Agree
We believe there is a need to use pre-defined system condition terminology and the ones provided in the attachment are easy to understand.
Disagree
We believe that adding the Central Time zone requirement for all verbal and written Interoperability Communications is unnecessary. For these type of activities there should already be accurate time stamps from equipment such as RTUs, EMS systems etc… for record keeping and documentation activities. In the future, with the implementation of Smart Grid technologies, time stamping will be included in the developed platforms for such technology, therefore, reducing the much of the time stamping errors. Because many of the actions required for Interoperability Communications, are completed by field personnel this requirement is onerous. It could potentially impact reliability since the field personnel might be more focused on documenting the correct time zone, for compliance to the requirement and the potential impact for non-compliance, than completing the required task safely and accurately. If time-stamping is an issue in event analysis, it might be more appropriate that Central Standard Time be utilized by recording devices such as RTUs, EMS systems etc… not for the actual verbal and written communications. In addition, how will daylight savings time be addressed in the proposed requirement of this standard?
Disagree
We agree that Three-part communication is a more accurate form of communication for issuing and responding to a Directive during verbal Interoperability Communications and should remain as a requirement of this standard. However since the term “directive” has not been defined it is unclear when Three-part communication is required.
Disagree
We agree that using the NATO phonetic alphabet is a more accurate form of communication for issuing and responding to a directive during verbal Interoperability Communications. However, other forms of phonetic alphabet communications could be utilized to achieve the same results and entities should not be forced to use only the NATO phonetic alphabet. As stated in question 6 we are concerned about the undefined term “directive”. In addition to the NATO alphabet, did the drafting team consider including the 10-Code system many utilities use for verbal communication (ex: 10-4)? If not, why not and if so, why not included?
Agree
We agree using pre-determined, mutually agreed upon line and equipment identifiers during for all verbal and written Interoperability Communications is a more accurate form of communication and should remain as a requirement of this standard.
 
Agree
POSSIBLE FRCC VARIENCE - FRCC appears to have developed a communication protocol in which “any or all conversations on the phone is considered a directive. If this case, we suggest that the drafting team review the FRCC approach and determine if a regional variance should be included in this standard or consider utilizing the FRCC approach for clearly defining the term “directive” for inclusion in the NERC Glossary.
 
We recommend replacing the term “Distribution Service Providers” in Attachment 1 with the term “Distribution Provider” as stated in the Applicability of this standard. In addition, please see our response to Question 3 regarding a modification to the Applicability portion of the standard to address concerns about the inclusion of Distribution Providers and Load Serving Entities. We are concerned with the onerous communication requirements for Load Serving Entities and Distribution Providers with field personnel that have rare or possibly no opportunities to communicate with personnel working at an entity registered as a Transmission Operator, Transmission Owner, Balancing Authority, Reliability Coordinator, Generator Operator or Transmission Service Provider.
Individual
Gordon Rawlings
British Columbia Transmission Corporation
Agree
 
Agree
 
Disagree
BCTC agrees with R1, R2, R3, R5 and R7 but strongly objects to R4 and R6. As a majority of the Interoperability Communications is within our time zone the is no advantage in using Central Standard Time as this will only make the communications more difficult as both parties are required to change time, R4 is unreasonable. R6 requiring the use of North American Treaty Organization (NATO) phonetic alphabet adds no value and will only cause confusion presently an instruction would be issued as: “At Kelly Lake open 5CB4” R6 it will now become “At Kelly Lake open Fife Charlie Bravo Fow-er”
Agree
 
Disagree
BCTC's position: as a majority of the Interoperability Communications is within our time zone there is no advantage in using Central Standard Time as this will only make the communications more difficult as both parties are required to change time, R4 is unreasonable.
Agree
 
Disagree
BCTC's position: R6 requiring the use of North American Treaty Organization (NATO) phonetic alphabet adds no value and will only cause confusion. Presently an instruction would be issued as:“At Kelly Lake open 5CB4” R6 it will now become: “At Kelly Lake open Fife Charlie Bravo Fow-er"
Agree
 
Agree
Should a move to a standard time be required then the move should be to Universal Time
Disagree
 
Disagree
 
Disagree
 
Group
PJM
Mike Bryson
Disagree
We feel that the definition of Interoperability Communication is much too broad and is inconsistent with the effort to develop results-based standards which would have a measurable and observable effect on the reliability of the bulk electric system. The definition of Interoperability Communication, as written, can include virtually any information exchange/instruction between entities, both routine and emergency. Such communication may or may not have a measurable and observable effect on bulk system reliability. Since the broad term Interoperability Communication is used in every requirement in COM-003-1, entities will be required to use the English language, the central time zone, and 3-part communication in even the most routine exchanges of information. This could create a burden on operating personnel and a distraction from their reliability duties. This group does not feel the need for a definition of Interoperability Communication, since the term Reliability Directive has been defined in draft standard COM-002-3, which is currently posted for review. The Reliability Directive term is emergency-focused and consistent with the results-based standards process. In addition, the definition of Three-part Communication in this standard does not match the three-part communication requirements stated in COM-002-3. In COM-002-3, the requirements for three-part communication (state – repeat - acknowledge) apply to Reliability Directives, while in COM-003-1 the definition of Three-part Communication refers to “information” in general. If, as stated in the Disposition of Requirements, the revisions to COM-002-3 will be moved to COM-003-1, the definition of Three-part Communication in this draft standard should be consistent with the requirements of COM-002-3. The way the definition of Three-part Communication is worded applies only when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should rather reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: “A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it.” Both element and facility are used in the Interoperability Communication definition and are NERC defined terms. Did the drafting team intend that the NERC definitions should apply? Then the terms need to be capitalized.
Disagree
Requirement R7, regarding the use of pre-determined line & equipment identifiers, applies to TSPs & LSEs. However, the other requirements of this standard do not seem to apply to these entities. For instance, most of the reliability-related alerts are communicated through the Reliability Coordinator Information System (RCIS). TSPs do not have access to this real-time communication tool, so the TSP should not be included in the applicability for the entire standard. Furthermore, Requirement R18 in TOP-002-2 mandated that neighboring Balancing Authorities use the uniform line identifiers. In COM-003-1, this requirement is lost, since Requirement R7 makes no mention of neighboring BAs. This requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how. The only real need for a requirement is to establish that each entity issuing a directive shall use three-part communications and the recipient of a directive shall also properly participate in the of use three-part communication protocol until the message has been correctly spoken and comprehended.
Disagree
It is not clear what the purpose of this communication protocol is or what should even be included in the protocol. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions. We feel that there should not be a requirement in the standard to have a “procedure”. It is our understanding that, to be auditably compliant with a standard, the responsible entity must develop a procedure, train on that procedure, and be able to demonstrate compliance via documents, data, logs, records, etc. If Requirements R2 – R7 are included in this standard, the entity will need to develop a procedure to be compliant. In other words, the procedure itself will become the focus rather than the actual communications protocol. Therefore, we feel that requirement R1 is redundant and should not be included. The NERC BOT has approved pursuing the Performance-based Reliability Standard Task Force’s recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to delineate actionable reliability requirements from record/documentation requirements. This proposal takes the opposite approach and incorporates a new administrative requirement. We – and the industry as a whole based on the response to the Task Force – do not support such an approach. We suggest deleting this Requirement from the Standard. Futhermore, the establishment of R2-R7 as elements of the CPOP required in R1 appears to contradict the recent shift in direction that NERC has taken regarding defining criteria as bullets under a requirement. See NERC’s August 10th informational filing regarding assignment of violation risk factors and violation severity levels in regards to dockets RM08-11-000, RR08-4-000, RR07-9-000, and RR07-10-000 Furthermore, R2 appears to define Interoperability Communications for attachment 1 communications only. Is this the intent of the drafting team?
Disagree
The Alert Level Guides in Attachment 1 are not consistent with the proposed definitions of reliability-related communications. Both the Reliability Directive and Interoperability Communication, as currently defined, require some emergency action or change of equipment status. Yet the Alert Level Guides were intended for announcement, not actions. Further, the “pre-defined” system conditions and alert levels are too detailed and overly prescriptive. System operators need to spend time looking for the right color and level to communicate the prevailing system condition terminology to avoid violating the standard. This task does not lend itself to promptly and effectively deal with the emergency situation. We also do not feel that these Alert Level Guides apply to all the responsible entities identified under Applicability in the draft standard – for example, TSPs and LSEs are not included in the list of notifications. The requirement to use the central time zone for logging the time of an alert is problematic in that all communication tools, such as the RCIS, will need to be re-vamped. We question whether there will be a measurable reliability benefit by doing so. There is also some redundancy in the Alert Level Guides – for example, the CIP-001 standard requires notification of sabotage events – it should not be repeated in this standard. This also needs to be reconciled with EOP-004 and CIP-001 and the SAR formed to address those redundancies. It is not clear what value there is in identifying alert levels. There does not appear to be any differentiation in actions taken based on the alert levels. Why not just state the number of substations attacked, etc? Attachment 1 and R2 do not appear to be in synch primarily due to the definition of Interoperability Communications. By definition, Interoperability Communication is about how entities change the state of the BES and Attachment 1 is about notifying of what already happened to the BES.
Disagree
We feel that this requirement of a common time zone is overly prescriptive. The requirement should be that entities operating in different time zones agree on how to best eliminate any confusion regarding the time difference. Entities that routinely operate in different time zones already have an effective system for dealing with time differences. There seems to be no incentive to change a system that already works quite well, and the cost of updating computer systems could prove prohibitive. This group feels that mandating a common time zone across all of North America can only lead to confusion and increased reliability issues.
Disagree
As suggested in Question 1 above, the term Reliability Directive (as defined in COM-002-3) should be used in place of Interoperability Communication, since the directive is specific to emergency operations. The requirement should read: “Each responsible entity shall use Three-part Communication when issuing a Reliability Directive”. In addition, this requirement should apply only to entities which issue reliability directives - BAs, TOPs & RCs. The other entities listed in the draft standard under Applicability do not issue Reliability Directives.
Disagree
Use of the NATO phonetic alphabet should be considered a “best practice” and should not be included as a requirement in a reliability standard. One failure, such as saying “Baker” instead of “Bravo”, results in a severe violation without any impact on system reliability. This group is concerned that operating personnel will be focused on using the correct word rather than managing the power system. Also, many organizations may have established communications protocols which are functioning properly and making a change may actually hinder reliable operations by introducing unnecessary confusion.
Disagree
Requirement R7 in draft COM-003-1 came from TOP-002-2, Requirement R18. The original requirement intended that neighboring Balancing Authorities use uniform line identifiers when communicating information about their tie lines. This requirement drops that clarification and introduces the additional requirement to use pre-determined “equipment” identifiers. Having to mutually agree in advance on identifiers for every switch & transformer is another example of a prescriptive requirement whose violation will not affect system reliability, yet will expose entities to large fines. The key question is: “Do the companies’ personnel understand one another?”
Agree
Our concern is that the Alert Level Guides of Attachment 1 were written for Reliability Coordinators, not the industry as a whole, and now they are being incorporated into an industry-wide standard. This attachment is very prescriptive as to how the notifications take place, such as through the RCIS. If the RCIS is not functioning and the hotline is used instead, is the entity vulnerable to a violation by virtue of the fact that these alert guides are included in the standard? We believe that the color-coded system condition terminology should be defined/required externally to the COM standards. The use of clear & consistent alert level terminology, while important, does not fit in well with the reliability-related communication standards, especially at these high violation severity levels. It is our suggestion that the Alert Level Guides be balloted separately, and include the Energy Emergency Alerts (EEA) as well. EEA requirements currently exist in NERC Standard EOP-002-2.1 It is not clear what value is realized by declaring an alert status particularly with regard to cyber and physical attacks. There does not appear to be any differing actions taken based on the alert status. Given that no differing actions are taken for cyber and physical attacks, it seems it would be more beneficial to use specific information such as 12 substations have been physically or cyber attacked. This is more meaningful than issuing a red alert that would only indicate more than one site has been attacked. Furthermore, we question the value of communicating the physical and cyber alerts. How does this notification help the BES reliability? Consider the following example. One BA in Oklahoma is 34,323 sq miles. Communicating that an attack occurred in the BA and RC tells other operators that somewhere in Oklahoma an attack occurred. This notification does not present any information that could require actions on the operators’ parts and will only generate phone calls for more information. Furthermore, PSE and CSE is a type of sabotage which is reported in CIP-001 R2 already. TEA Alerts are already covered in IRO-006-East-1, IRO-009, IRO-010, IRO-014.01 R2. Attachment 1 contains a conflict. The last sentence of the opening paragraph of Attachment 1 reads, “The time frame for declaration of these Alert states shall be consistent with the approach used to declare EEAs and would normally apply to Real Time declarations and not forecast conditions.” In Transmission Emergency Alerts Condition Yellow, Orange and RED: The Reliability Coordinator or Transmission Operator foresees or is experiencing conditions where all available generation resources are committed to respect the IROL and/or is concerned about its ability to respect the IROL. Forsees is a forecast condition. In condition Orange and Red for TEA Level Two/Three, the initial notification requirements are redundant with IRO-006-East-1 R3.2. Under the Make Final Notifications, is curtailed intended to mean canceled or terminated? The term Curtailed in operations generally means cuts for schedules/tags. EEA’s use terminated. We recommend using terminated. Distribution Service Providers should be Distribution Provider to be consistent with the Functional Model.
Disagree
Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the parties such as Distribution Provider and Generation Operator cannot have access to these systems due FERC standards of conduct requirements. Requirement 2 and the listing of functional entities required to be notified within the RC footprint in attachment 1 create a de facto requirement for them to have RCIS access or an unnecessary burden to communicate with all functional entities listed separately. Having to communicate to all functional entities in that list verbally and individually would create an unnecessary burden that distracts the RC from actual system operation and represents a detriment to reliability.
Agree
We do see a potential conflict with the Energy Policy Act 2005, which set the framework for the Electric Reliability Organization (ERO). The ERO’s mission is to oversee and protect the reliability of the Bulk Electric System. This standard seems to cross the line between reliability-related activities and other types of operating actions which may be better suited for NAESB action. The concern here is that system operators will focus on the letter of the standard rather than on good operating practice. The fear of a violation among operators may have a greater impact on reliability than the violation itself. In some market structures, TSPs and LSE do not own or operate equipment. Thus, including them in the requirements is an unnecessary burden for these areas. The requirement to use CST attempts to determine HOW entities operate within their various footprints and it would significantly change the way many Markets are structured. To implement this into existing Markets would cost significant time, money and resources while not enhancing reliability in these areas. We believe that, when operating across time-zones, simply referencing “Central Standard Time” or “Eastern Standard Time” is sufficient for other operating entities to reliably operate; also, let’s not lose sight of HOW MANY entities would have to modify their existing practices, hardware, software, Control System, billing systems, bidding systems, etc. We are strongly opposed to this requirement.
Agree
We have identified several problems with this standard, as noted above. Other observations include: The effective dates in the draft standard and in the implementation plan do not seem to match. In the standard, the effective date mentions one calendar year following regulatory approval, while the implementation plan refers to the third calendar quarter after regulatory approval. Furthermore, we do not feel that any of the requirements in this standard warrant Violation Risk Factors or Violation Severity Levels in the high or severe category. In summary, this review group feels that COM-003-1 is not yet ready to be acted upon and may have been posted too soon. There does not seem to be sufficient coordination between the drafting teams of all the COM standards, or any attempt to integrate these standards. One example is the inconsistency between COM-003-1 and COM-002-3 regarding the meaning of three-part communication (mentioned in our response to Question 1 above). Recommendation 26 of the August 14, 2003 blackout report is cited as a driver for extending three-part communications. We believe the title of Recommendation 26 is misleading and when reviewed separately from the supporting text of the recommendation and direct and contributing factors in the report results in an incorrect interpretation. “Failure to identify emergency conditions and communicate that status to neighboring systems” is one of the contributing factors and the supporting text of the recommendation clearly refer to shoring up communications during emergency and anticipated emergency conditions and establishing an emergency broadcast communication system to alert regulatory, state and local officials. The supporting text of Recommendation 26 only mentions addressing alerts, emergencies or other critical situations. Some have incorrectly inferred the initial clause of Recommendation 26, “Tighten communication protocols”, means the recommendation applies to all routine communications. As noted above, we feel that many of the requirements prescribe specific “how to” methods for compliance rather than focusing on the “what” of the requirement. Overall, COM-003-1 is much too prescriptive to be tied to million dollar-level fines.
Group
PJM SOS Comments
Mike Bryson
Disagree
We feel that the definition of Interoperability Communication is much too broad and is inconsistent with the effort to develop results-based standards which would have a measurable and observable effect on the reliability of the bulk electric system. The definition of Interoperability Communication, as written, can include virtually any information exchange/instruction between entities, both routine and emergency. Such communication may or may not have a measurable and observable effect on bulk system reliability. Since the broad term Interoperability Communication is used in every requirement in COM-003-1, entities will be required to use the English language, the central time zone, and 3-part communication in even the most routine exchanges of information. This could create a burden on operating personnel and a distraction from their reliability duties. This group does not feel the need for a definition of Interoperability Communication, since the term Reliability Directive has been defined in draft standard COM-002-3, which is currently posted for review. The Reliability Directive term is emergency-focused and consistent with the results-based standards process. In addition, the definition of Three-part Communication in this standard does not match the three-part communication requirements stated in COM-002-3. In COM-002-3, the requirements for three-part communication (state – repeat - acknowledge) apply to Reliability Directives, while in COM-003-1 the definition of Three-part Communication refers to “information” in general. If, as stated in the Disposition of Requirements, the revisions to COM-002-3 will be moved to COM-003-1, the definition of Three-part Communication in this draft standard should be consistent with the requirements of COM-002-3. The way the definition of Three-part Communication is worded applies only when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should rather reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: “A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back to the party that initiated the communication by the second party that received the communication, and the information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it.” Both element and facility are used in the Interoperability Communication definition and are NERC defined terms. Did the drafting team intend that the NERC definitions should apply? Then the terms need to be capitalized.
Disagree
Requirement R7, regarding the use of pre-determined line & equipment identifiers, applies to TSPs & LSEs. However, the other requirements of this standard do not seem to apply to these entities. For instance, most of the reliability-related alerts are communicated through the Reliability Coordinator Information System (RCIS). TSPs do not have access to this real-time communication tool, so the TSP should not be included in the applicability for the entire standard. Furthermore, Requirement R18 in TOP-002-2 mandated that neighboring Balancing Authorities use the uniform line identifiers. In COM-003-1, this requirement is lost, since Requirement R7 makes no mention of neighboring BAs. This requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how. The only real need for a requirement is to establish that each entity issuing a directive shall use three-part communications and the recipient of a directive shall also properly participate in the of use three-part communication protocol until the message has been correctly spoken and comprehended.
Disagree
It is not clear what the purpose of this communication protocol is or what should even be included in the protocol. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions. We feel that there should not be a requirement in the standard to have a “procedure”. It is our understanding that, to be auditably compliant with a standard, the responsible entity must develop a procedure, train on that procedure, and be able to demonstrate compliance via documents, data, logs, records, etc. If Requirements R2 – R7 are included in this standard, the entity will need to develop a procedure to be compliant. In other words, the procedure itself will become the focus rather than the actual communications protocol. Therefore, we feel that requirement R1 is redundant and should not be included. The NERC BOT has approved pursuing the Performance-based Reliability Standard Task Force’s recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to delineate actionable reliability requirements from record/documentation requirements. This proposal takes the opposite approach and incorporates a new administrative requirement. We – and the industry as a whole based on the response to the Task Force – do not support such an approach. We suggest deleting this Requirement from the Standard. Futhermore, the establishment of R2-R7 as elements of the CPOP required in R1 appears to contradict the recent shift in direction that NERC has taken regarding defining criteria as bullets under a requirement. See NERC’s August 10th informational filing regarding assignment of violation risk factors and violation severity levels in regards to dockets RM08-11-000, RR08-4-000, RR07-9-000, and RR07-10-000 Furthermore, R2 appears to define Interoperability Communications for attachment 1 communications only. Is this the intent of the drafting team?
Disagree
The Alert Level Guides in Attachment 1 are not consistent with the proposed definitions of reliability-related communications. Both the Reliability Directive and Interoperability Communication, as currently defined, require some emergency action or change of equipment status. Yet the Alert Level Guides were intended for announcement, not actions. Further, the “pre-defined” system conditions and alert levels are too detailed and overly prescriptive. System operators need to spend time looking for the right color and level to communicate the prevailing system condition terminology to avoid violating the standard. This task does not lend itself to promptly and effectively deal with the emergency situation. We also do not feel that these Alert Level Guides apply to all the responsible entities identified under Applicability in the draft standard – for example, TSPs and LSEs are not included in the list of notifications. The requirement to use the central time zone for logging the time of an alert is problematic in that all communication tools, such as the RCIS, will need to be re-vamped. We question whether there will be a measurable reliability benefit by doing so. There is also some redundancy in the Alert Level Guides – for example, the CIP-001 standard requires notification of sabotage events – it should not be repeated in this standard. This also needs to be reconciled with EOP-004 and CIP-001 and the SAR formed to address those redundancies. It is not clear what value there is in identifying alert levels. There does not appear to be any differentiation in actions taken based on the alert levels. Why not just state the number of substations attacked, etc? Attachment 1 and R2 do not appear to be in synch primarily due to the definition of Interoperability Communications. By definition, Interoperability Communication is about how entities change the state of the BES and Attachment 1 is about notifying of what already happened to the BES.
Disagree
We feel that this requirement of a common time zone is overly prescriptive. The requirement should be that entities operating in different time zones agree on how to best eliminate any confusion regarding the time difference. Entities that routinely operate in different time zones already have an effective system for dealing with time differences. There seems to be no incentive to change a system that already works quite well, and the cost of updating computer systems could prove prohibitive. This group feels that mandating a common time zone across all of North America can only lead to confusion and increased reliability issues.
Disagree
As suggested in Question 1 above, the term Reliability Directive (as defined in COM-002-3) should be used in place of Interoperability Communication, since the directive is specific to emergency operations. The requirement should read: “Each responsible entity shall use Three-part Communication when issuing a Reliability Directive”. In addition, this requirement should apply only to entities which issue reliability directives - BAs, TOPs & RCs. The other entities listed in the draft standard under Applicability do not issue Reliability Directives.
Disagree
Use of the NATO phonetic alphabet should be considered a “best practice” and should not be included as a requirement in a reliability standard. One failure, such as saying “Baker” instead of “Bravo”, results in a severe violation without any impact on system reliability. This group is concerned that operating personnel will be focused on using the correct word rather than managing the power system. Also, many organizations may have established communications protocols which are functioning properly and making a change may actually hinder reliable operations by introducing unnecessary confusion.
Disagree
Requirement R7 in draft COM-003-1 came from TOP-002-2, Requirement R18. The original requirement intended that neighboring Balancing Authorities use uniform line identifiers when communicating information about their tie lines. This requirement drops that clarification and introduces the additional requirement to use pre-determined “equipment” identifiers. Having to mutually agree in advance on identifiers for every switch & transformer is another example of a prescriptive requirement whose violation will not affect system reliability, yet will expose entities to large fines. The key question is: “Do the companies’ personnel understand one another?”
Agree
Our concern is that the Alert Level Guides of Attachment 1 were written for Reliability Coordinators, not the industry as a whole, and now they are being incorporated into an industry-wide standard. This attachment is very prescriptive as to how the notifications take place, such as through the RCIS. If the RCIS is not functioning and the hotline is used instead, is the entity vulnerable to a violation by virtue of the fact that these alert guides are included in the standard? We believe that the color-coded system condition terminology should be defined/required externally to the COM standards. The use of clear & consistent alert level terminology, while important, does not fit in well with the reliability-related communication standards, especially at these high violation severity levels. It is our suggestion that the Alert Level Guides be balloted separately, and include the Energy Emergency Alerts (EEA) as well. EEA requirements currently exist in NERC Standard EOP-002-2.1 It is not clear what value is realized by declaring an alert status particularly with regard to cyber and physical attacks. There does not appear to be any differing actions taken based on the alert status. Given that no differing actions are taken for cyber and physical attacks, it seems it would be more beneficial to use specific information such as 12 substations have been physically or cyber attacked. This is more meaningful than issuing a red alert that would only indicate more than one site has been attacked. Furthermore, we question the value of communicating the physical and cyber alerts. How does this notification help the BES reliability? Consider the following example. One BA in Oklahoma is 34,323 sq miles. Communicating that an attack occurred in the BA and RC tells other operators that somewhere in Oklahoma an attack occurred. This notification does not present any information that could require actions on the operators’ parts and will only generate phone calls for more information. Furthermore, PSE and CSE is a type of sabotage which is reported in CIP-001 R2 already. TEA Alerts are already covered in IRO-006-East-1, IRO-009, IRO-010, IRO-014.01 R2. Attachment 1 contains a conflict. The last sentence of the opening paragraph of Attachment 1 reads, “The time frame for declaration of these Alert states shall be consistent with the approach used to declare EEAs and would normally apply to Real Time declarations and not forecast conditions.” In Transmission Emergency Alerts Condition Yellow, Orange and RED: The Reliability Coordinator or Transmission Operator foresees or is experiencing conditions where all available generation resources are committed to respect the IROL and/or is concerned about its ability to respect the IROL. Forsees is a forecast condition. In condition Orange and Red for TEA Level Two/Three, the initial notification requirements are redundant with IRO-006-East-1 R3.2. Under the Make Final Notifications, is curtailed intended to mean canceled or terminated? The term Curtailed in operations generally means cuts for schedules/tags. EEA’s use terminated. We recommend using terminated. Distribution Service Providers should be Distribution Provider to be consistent with the Functional Model.
Agree
Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the parties such as Distribution Provider and Generation Operator cannot have access to these systems due FERC standards of conduct requirements. Requirement 2 and the listing of functional entities required to be notified within the RC footprint in attachment 1 create a de facto requirement for them to have RCIS access or an unnecessary burden to communicate with all functional entities listed separately. Having to communicate to all functional entities in that list verbally and individually would create an unnecessary burden that distracts the RC from actual system operation and represents a detriment to reliability.
Agree
We do see a potential conflict with the Energy Policy Act 2005, which set the framework for the Electric Reliability Organization (ERO). The ERO’s mission is to oversee and protect the reliability of the Bulk Electric System. This standard seems to cross the line between reliability-related activities and other types of operating actions which may be better suited for NAESB action. The concern here is that system operators will focus on the letter of the standard rather than on good operating practice. The fear of a violation among operators may have a greater impact on reliability than the violation itself. In some market structures, TSPs and LSE do not own or operate equipment. Thus, including them in the requirements is an unnecessary burden for these areas. The requirement to use CST attempts to determine HOW entities operate within their various footprints and it would significantly change the way many Markets are structured. To implement this into existing Markets would cost significant time, money and resources while not enhancing reliability in these areas. We believe that, when operating across time-zones, simply referencing “Central Standard Time” or “Eastern Standard Time” is sufficient for other operating entities to reliably operate; also, let’s not lose sight of HOW MANY entities would have to modify their existing practices, hardware, software, Control System, billing systems, bidding systems, etc. We are strongly opposed to this requirement.
Agree
We have identified several problems with this standard, as noted above. Other observations include: The effective dates in the draft standard and in the implementation plan do not seem to match. In the standard, the effective date mentions one calendar year following regulatory approval, while the implementation plan refers to the third calendar quarter after regulatory approval. Furthermore, we do not feel that any of the requirements in this standard warrant Violation Risk Factors or Violation Severity Levels in the high or severe category. In summary, this review group feels that COM-003-1 is not yet ready to be acted upon and may have been posted too soon. There does not seem to be sufficient coordination between the drafting teams of all the COM standards, or any attempt to integrate these standards. One example is the inconsistency between COM-003-1 and COM-002-3 regarding the meaning of three-part communication (mentioned in our response to Question 1 above). Recommendation 26 of the August 14, 2003 blackout report is cited as a driver for extending three-part communications. We believe the title of Recommendation 26 is misleading and when reviewed separately from the supporting text of the recommendation and direct and contributing factors in the report results in an incorrect interpretation. “Failure to identify emergency conditions and communicate that status to neighboring systems” is one of the contributing factors and the supporting text of the recommendation clearly refer to shoring up communications during emergency and anticipated emergency conditions and establishing an emergency broadcast communication system to alert regulatory, state and local officials. The supporting text of Recommendation 26 only mentions addressing alerts, emergencies or other critical situations. Some have incorrectly inferred the initial clause of Recommendation 26, “Tighten communication protocols”, means the recommendation applies to all routine communications. As noted above, we feel that many of the requirements prescribe specific “how to” methods for compliance rather than focusing on the “what” of the requirement. Overall, COM-003-1 is much too prescriptive to be tied to million dollar-level fines.
Group
New York State Reliability Council
Robert Ganley
Disagree
Comments: NYSRC agrees with the definitions for Communication Protocol. NYSRC disagrees with the definition for Three-Part Communication. NYSRC prefers the process offered in COM-002-03 (draft). In COM-003 the listener must understand the communication the first time. Failure to understand and repeat back correctly could be a violation of the requirement. The intent three part communication is to have an iterative process whereby the person issuing the message is ultimately satisfied that the recipient understands the information and will perform the required action. It should not be defined as three steps and only three steps. NYSRC offers the following definition: A Real-Time Operating Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back to the party that initiated the communication by the second party that received the communication, and the information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it. NYSRC disagrees with the definition of Interoperability Communication. NYSRC believes the Standard is addressing the communication of the Operating State of BES equipment and facilities. The proposed definition utilizes the phrase “change the state … of a BES facility” which can be interpreted as the position, e.g. open, close, tap position, etc… thereby extending this Standard into routine switching and operation of the BES. The SAR stated this Standard was “to use specific communications protocols under normal, abnormal and emergency conditions to relay critical reliability-related information in a timely and effective manner”. The proposed definition can be interpreted in a manner that extends this to all reliability related information for every BES operation. The drafting team should also consider adding a definition for Directive or acknowledge the definition in draft Com-002-03.
Agree
 
Disagree
Comments: NYSRC agrees with the need for CPOP but does not agree that R4 can or should apply to all interoperability communications between entities. Since the examples in Attachment 1 specifically state RC and TOP, this standard should not apply to any other entity except for the RC and TOP. COM-002-03(draft) could require the other entities to utilize three part communication for reliability-related Interoperability communication.
Disagree
Comments: NYSRC believes the use of “shall” and “all” coupled with the broad applicability of this Standard and the broad definition of Interoperability Communication will result in entities either not complying with R2 or making statements regarding the Operating Alert State when unnecessary. Attachment 1-Com-003 is very prescriptive in the use pre-defined terminology, colors and levels, and what to report on. There is no benefit to specifying the specific terminology. This requirement should require the RC to define the terms/levels/alert states to include within the CPOP that sufficiently communicate the increased levels of Alert or Response encountered/required. Many entities have invested time and training in the existing processes that meet the intent of this requirement. Read strictly, the only predefined alert conditions are Physical security, Cyber security and Transmission Security as it applies to the RC and TOP only. NYSRC notes that R2 in the draft Standard does not match R2 in this question. Specifically the word ALL is not in the Standard.
Disagree
Comments: This requirement will burden those entities whose operations and communication needs are with other entities in the same time zone, which represents the overwhelming majority of all communications performed. It will increase the likelihood of errors for such entities. Further, some entities are operating both NERC BES elements and non-BES elements from the same control room. This requirement will significantly impact the efficiency and the safety of workers within those entities. NYSRC notes that R4 in the draft Standard does not match R2 in this question. Specifically the word ALL is not in the Standard.
Disagree
Comments: The SDT should define Directive. Draft Com-002 -3 has a similar requirement to identify a directive and then utilize three-part communication. Also Com-002-3 Three part communication differs from the description of Three-part communication in this Standard. NYSRC prefers Com-002-3 usage of the word “intent” in the repeat back. Also see comments to Question 1.
Disagree
Comments: While NYSRC understands the benefit of utilizing a phonetic alphabet, we question the designation of a specific phonetic alphabet. This prescriptive requirement may result in absurd non-compliance reports, such as, using “Dog” for “D” instead of “Delta”. R6 requires the use of the alphabet when issuing information, but not in the repeat back step. This may be an oversight. Also Does the RC in its communication utilize the abbreviation for the threat type, e.g PSEA, or does the RC use the NATO-Alphabet? If NATO, then the example in Attachment 1 should state this need.
Agree
Comments: NYSRC notes that R7 in the draft Standard does not match R2 in this question. Specifically the word ALL is not in the Standard.
Agree
Comments: In addition to the response to Question 4, NYSRC does not understand why there are Levels and color designations since only the threat level numeral is being communicated. Attachment 1-Com-003 is very prescriptive in the use pre-defined terminology, colors and levels. There is no benefit to specifying the specific terminology. Requiring system Operators to state Colors and Levels would seem to result in slower and more confused communication.
 
Disagree
 
Agree
Comments: R1 requires each entity to create a CPOP. There is not a requirement to coordinate CPOP’s amongst entities beyond the requirements in the Standard. There is no requirement to exchange CPOP’s between entities with an operating relationship. The SDT should consider adding a requirement either that allows entities with operating relationships to request and be provided a copy of the other’s CPOP, or a requirement requiring the exchange of CPOP between entities with operating relationships. Additionally, we cannot understand how all requirements but R1 have been determined to have a HIGH VRF when, many of them are dictating HOW communications should take place and not when and why or what. High Risk Factor requirement (a) is one that, if violated, could directly cause or contribute to bulk power system instability, separation, or a cascading sequence of failures, or could place the bulk power system at an unacceptable risk of instability, separation, or cascading failures. NYSRC does not believe that any requirement in this Standard if violated would have the results specified in the definition of a High VRF, especially since these requirements are addressing the HOW of communication.
Individual
Greg Rowland
Duke Energy
Disagree
When viewed in the context of its use in R5 and R6, the definition of Interoperability Communication is excessively broad and unclear. R5 refers to the issuing of a “directive” during verbal Interoperability Communications. The term “directive” is undefined. R6 requires the use of the NATO phonetic alphabet during verbal Interoperability communications such as directives, notifications, directions, instructions, orders or other reliability related operating information. This could conceivably encompass all communications. Also, the definition refers to communications between two or more “entities”. Does “entities” refer to functional entities or registered entities?
Disagree
We disagree with moving R18 into COM-003-1 and broadening it to include every line and piece of equipment. This would create an enormous amount of effort to implement, and would substantially increase compliance risk, without any increase in reliability. Furthermore, if R18 is moved into COM-003-1, when would it be removed from TOP-002-2? Until R18 is actually removed from TOP-002-2, entities would be subject to compliance double jeopardy.
Disagree
There is no need to have a CPOP to describe how an entity will comply with R2 through R7. A CPOP would just be a restatement of the requirements. If an entity complies with R2 through R7, there’s no reliability related benefit to having a CPOP.
Disagree
Attachment 1 is limited to notifications from the RC to other entities regarding Alerts for Physical Security Emergency, Cyber Security Emergency or Transmission Emergency. Also, these types of notifications wouldn’t meet the definition of “Interoperability Communications”, because they wouldn’t necessarily be used to effect a change in the state or status of an element or facility of the Bulk Electric System.
Disagree
We don’t agree with this requirement because it would introduce confusion into communications, especially in all communications other than RC to RC. RC’s already have protocols in place to deal with time zone differences, and changing that and applying it to all entities would create reliability errors. We think that this is “a solution in search of a problem”.
Disagree
We believe that the term “directive” should be defined. This SDT should work with the COM-002 SDT to come up with common phraseology and definition for the term “Directive”. Work on COM-003-1 should have begun by defining “directive”, and limiting the requirement to use 3-part communications to “directives”, and not requiring it for general day-to-day communications. The entity issuing a “directive” should inform the receiving entity that it is a directive and therefore requires the use of 3-part communications.
Disagree
We believe that R6 should be deleted, because it is focused on the details of the “how” rather than the “what” in communications. The key is accurate 3-part communications for “directives”, as required by R5. R6 is far too broad in the communications that would be included. Also, we believe that there is no reasonable way to implement, self-certify or audit compliance with this requirement.
Disagree
Delete this requirement. See our response to Question #2 above.
Agree
We support the development of this attachment, but question whether it belongs in this standard, especially since it is under field trial. We think it belongs in the EOP standards. We note the Attachment 1 is only associated with notifications by the RC, so we question whether these are Interoperability Communications as that term is defined. Also, the introduction on Attachment is very confusing. Attachment 1 states that definitions for Transmission Loading, Physical and Cyber Security Alert states align with the Emergency Energy Alert (EEA) states as already described in Standard EOP-002-2.1. EOP-002-2.1 and associated EEA Levels provides guidance on Energy and Capacity Emergencies rather than Transmission or Physical/Cyber Alerts. Energy Emergency is defined as a condition when a LSE has exhausted all other options and can no longer provide its customers’ expected energy requirements. This is a totally different classification of Emergency Alert. We suggest deleting the 2nd and 3rd sentences of the introduction to Attachment 1. In addition, Attachment 1 does not contain four system condition alerts, as the SDT has proposed.
Disagree
 
Disagree
 
Agree
As a general comment, all the requirements other than R1 are High VRFS with only Severe VSLs. As this standard is written to apply broadly to routine as well as emergency communications between entities, we believe that failure to meet these requirements would rarely impact the reliability of the Bulk Electric System. For example if in routine switching an operator says “Baker” instead of “Bravo”, the entity is subject to FERC’s most severe penalty. Clearly the basis for this standard needs to be reassessed. If we use the test that if a requirement or a standard supports/encourages reliability and security, then entities should invest the time and effort to track performance to ensure auditable compliance. For example – Does DCS compliance support/encourage reliability/security? The industry would generally say yes – so the tracking and determination of auditable compliance is justified. But would auditable compliance to this draft of COM-003-1 support/encourage reliability/security? We don’t think so, given the vague and general nature of this draft. It certainly would not justify the amount of work and effort it would take to ensure auditable compliance with this COM-003-1 draft, given the amount of effort it would take to monitor all recorded communications that fit within this vague draft standard. Bottom line is that we think COM-003 is not needed. As proposed, it is a “how” and not a “what” based standard that will create more distraction from reliability/security than any value it might add.
Individual
Frank Cumpton
Transmission System Operations
Disagree
The definition of “Interoperability Communication” is not clear. What does the term “reliability-related” information entail? Does “Interoperability Communication” include instructions from a control room to a generator to adjust vars, from the control room to field personnel to direct the changing of transformer taps, from the control room to field personnel to implement switching instructions, etc? What is the definition of “entity”? Does this mean if switching instructions are given from a control room of one company to personnel in its own company (i.e., the same entity), that the interaction would not be classified as “Interoperability Communication”?
Agree
 
Disagree
We believe the phrase, “but is not limited to” should be deleted. The elements required to be in the CPOP should be well-defined.
Agree
 
Disagree
We believe that the use of Central Standard Time in non-CST areas would create confusion between the Reliability Coordinator, Transmission Operator, Transmission Owner, Generator Operators, and field personnel.
Disagree
As stated in Question #1, the definition of “Interoperability Communication” needs further clarification. Also, further clarification is needed as to when “Interoperability Communications” is required to be used.
Disagree
As stated in Question #1, the definition of “Interoperability Communication” needs further clarification. Directives, notifications, directions, instructions, orders, and other reliability operating information needs to be clearly defined, including what it consists of and when it is to be utilized.
Agree
 
Agree
It should be made clear that Attachment 1 applies to the RC’s. It is not specifically stated in R2 that it is the RC’s responsibility to make notifications. In Attachment 1, we believe the wording under “Initial Notifications” should be changed. For example, on the 2nd row and 1st column of the matrix, it states that the RC makes initial notification and states that “…there is a Physical Emergency Alert, PSEA Level One within….” Nowhere is it ever mentioned that there is a “Condition Yellow”. Since it is never mentioned by the RC in the notification that the Condition is “Yellow”, what is the use or benefit of having the conditions? It should also be made clear that when the RC states, for example, that “There is a Physical Security Emergency Alert-PSEA Level One within…” that this refers to specific definitions given in Attachment 1 of EOP-002-2.1. This fact is mentioned at the top of the matrix, but the wording of this explanation is not consistent with the wording used in the body of the matrix.
Agree
Refer to Question #5; we do not agree with using Central Standard Time.
Disagree
 
Agree
We think the SDT should coordinate their work closely with the team of the Reliability Coordination Project 2006-06, especially regarding new definitions related to communications and reliability directives.
Group
We Energies
Howard Rulf
Disagree
Communications Protocol: This defined term appears only in the Three-part Communication definition and in titles. Titles are expected to be capitalized and are not necessarily the defined term. The COM-003-1 Standard title is “Operating Personnel Communications Protocols”, but the purpose is not restricted to verbal and written information, so “Communications Protocol” does not seem to refer to the defined term in this title. Similarly, it is not necessarily the defined term in CPOP. It is not clear where this definition is being utilized in the standard. Three-Part Communication: Should be required for “Reliability Directives” only. It seems that this is currently being addressed, and could remain, in an updated version of COM-002-003. This should be coordinated between standards and duplication should be avoided. Interoperability Communication: This definition is excessively broad, and the terminology “reliability related information” is ambiguous and vague. Communication is used elsewhere within the NERC Standards to include voice, data, email, memos, NERCnet, etc. Since communication of any type may be used to change the “state or status” of the Bulk Electric System, this definition seems to pertain to every communication in every form, which could be interpreted to include market information which is continuously used to drive changes to the “state or status”. By extension, a CPOP would need to include every communication of any type (voice, data, email, memos, etc.), which is over-reaching and open to conflict with the CPOP’s developed independently by other entities. Interoperability Communications should apply only to situations covered in Attachment 1, and definitions should better reflect applicability to communications between separate, distinct entities (not communications within the same organization).
Disagree
Because applicability to a TSP and LSE of this standard stems solely from TOP-002-2 R18, R7 should be the only requirement that applies to a TSP or LSE.
Disagree
It is not clear what the purpose of the CPOP is, or how having it would improve reliability of the Bulk Electric System. This standard, (or alternatively COM-002-003) should focus on requiring Three-Part Communication during Reliability Directives. In addition, the vague and broad nature of the existing definition of Interoperability Communication makes creating CPOP’s problematic and open to conflict with the CPOP’s developed independently by other entities. As noted in question 2, R1 should not apply to a TSP or LSE.
Disagree
Attempting to mold all possible circumstantial situations into the pre-defined terminologies is overly restrictive and may result in reduced accuracy, unnecessary confusion and misinterpretation. R2 should have the word “all” included (as is stated in this question) in order to restrict the applicability of Interoperability Communications to only those situations defined in Attachment 1. As noted in question 2, R2 should not apply to a TSP or LSE.
Disagree
If requiring one standard time zone, it would seem prudent to specify Greenwich Mean Time (GMT) as a universal standard. That being said, solely utilizing Central Standard Time (CST), or even GMT, as the common time zone may cause undue confusion given that MISO and PJM already operate with established processes and systems that are inconsistent with this, and are based on their own market timing. In addition, many plant personnel and procedures already have a long and engrained history of successful operation under existing timing directions, which are not aligned with market timing. Forcing every plant across multiple time zones to establish a new standard ignores the need for cases of special consideration and historical circumstances. The potential confusion due to the forced timing standard across many entities within a given area is too high a price to pay for the possible clarity by a limited few due to the switch to CST. A preferred alternative would include focusing the standard on requiring very clear communication of the time zone being specified for a given Reliability Directive. Thus, compliance enforcement would only pertain to Reliability Directives.
Disagree
The term ”directive” should be replaced with the term “Reliability Directive” as defined by the Drafting Team working on Project 2006-06 which states it as: “A communication initiated by a Reliability Coordinator, Transmission Operator or Balancing Authority where action by the recipient is necessary to address an actual or expected Emergency”. Three-part Communication should be required (with regard to compliance) during emergency situations in which Reliability Directives are being issued. This requirement should not apply to normal or non-emergency situations, and should be enforceable between Functional Entities (distinct entities, not within a given organization). As noted in question 2, R5 should not apply to a TSP or LSE.
Disagree
While R6 could be recommended as a good utility practice when communicating Reliability Directives, it is not appropriate to enforce it as a requirement for all communications. The focus of the standard should be on the achievement of clear communications, with individual organizations retaining some freedom to implement practices appropriate for their own unique situations. If Violation Severity Levels will be “high” as indicated in Attachment 1-COM-003-1, then the standard must be much more specific as to what constitutes “directives, notifications, directions, instructions, orders or other reliability operating information”. Assigning a high Violation Severity Level to the failure to use a specific phonetic alphabet (NATO) instead of to a failure to use any phonetic alphabet seems unreasonable and is likely to cause as much confusion as failing to use any sort of phonetic pronunciation. If attachment 2 is utilized, it should only be required for situations where Attachment 1 applies. As noted in question 2, R6 should not apply to a TSP or LSE.
Disagree
TOP-002-2 R18 requires uniform line identifiers. The wording of R7 and the statement by the SDT that “the Requirement does not stipulate a single/unique identifier as long as all parties mutually agree” is in conflict with TOP-002-2 R18. Allowing multiple line and equipment identifiers to be used does not improve reliability or improve communications in an emergency. TOP-002-2 applies to Transmission Facilities of an Interconnected Network…R7 should do the same for clarity. Having the term ”mutually agreed upon” in a standard is unworkable, since it allows a non-cooperative party to disrupt the genuine efforts of others and to exploit unfair leverage in discussions or negotiations. A better approach is having the Transmission Owners develop identifiers for transmission, and Generation Operators develop identifiers for generation. The process should be defined such that comments are solicited and input within a pre-specified convention, and then a specific entity is given the ability to make the final determination. Again, R7 is more appropriate as a best practices recommendation, rather than a requirement.
Agree
Attachment 1 is written for an RC. Usage of Attachment 1 by entities other than an RC should be clarified.
Disagree
 
Agree
In general, establishing CST as a uniform time zone may conflict with individual Tariffs regarding references to wholesale electric market commercial activities and could cause additional confusion if commercial market time zone references are independent of reliability time zone references.
Agree
Remove “timely” from the Purpose section, since a time period is not part of any requirement. According to the NERC Reliability Standards Development Procedure, Compliance Monitoring Period and Reset are required elements, and should be included. M1 through M7 should indicate which requirement they pertain to. Compliance enforcement should be focused on Reliability Directives only. Rather than proving 100% compliance, it is more practical if each party is obligated to report instances of unclear communication to the other party/parties involved in the Reliability Directive(s). Defining a remediation plan could be part of the requirement, with a measure being whether or not the remediation was implemented. An overall observation is that the intended communication updates could be implemented through modification of existing COM-001 & COM-002 standards without the need for another overlapping standard. Additional industry focus regarding communication protocols could be further emphasized through NERC System Operation Certification Program requirements and training.
Individual
Greg Mason
Dynegy
Disagree
The way the definition of “Three-part Communication” is worded applies only when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should rather reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: “A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it.” It should also be noted that these principles are included in Requirements R2 and R3 in the recently issued draft Standard COM-002-3 in Project 2006-06. This definition in this Standard is not needed. We believe the term “Interoperability Communication” creates confusion within the industry and contradicts the work by RTO and RC SDT in Project 2006-06 that limits the requirement to use three-part communications when issuing Reliability Directives (defined in Project 2006-06) that address anticipated and actual emergency conditions. Additionally, it appears that this definition would encompass all verbal communications and, as such, would be a distraction to Operators. Therefore, there is no reliability need for this definition. While using three-part communications during routine operations may be a best operating practice, we do not believe that it is so critical to reliability that it needs to become an enforceable requirement for routine operating instructions. Rather we believe the enforceable requirement should be limited to require three-part communications during actual emergency and anticipated emergency conditions only. Both element and facility are used in the Interoperability Communication definition and are NERC defined terms. Did the drafting team intend that the NERC definitions should apply? Then the terms need to be capitalized. In addition, the term “entities” is confusing and needs to be defined.
Disagree
The SDT actually expanded Requirement R18 of TOP-002-2 by adding the term “equipment”. In any event, this Requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how. The only real need for a requirement is to establish that each entity issuing a directive shall use three-part communications and the recipient of a directive shall also properly participate in the use of the three-part communication protocol until the message has been correctly spoken and comprehended.
Disagree
This proposed communication protocol is redundant to Requirements R2-R7 and should not be included in this Standard. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions. The NERC BOT has approved pursuing the Performance-based Reliability Standard Task Force’s recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to eliminate administrative requirements. This proposed Requirement takes the opposite approach and incorporates a new administrative requirement. We – and the industry as a whole based on the response to the Task Force – do not support such an approach. We suggest deleting this Requirement from the Standard.
Disagree
It is not clear what value there is in identifying these alert levels. There does not appear to be any differentiation in actions taken based on the alert levels. Why not just state the number of substations attacked, etc? Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the listed entities such as Distribution Provider and Generator Operator cannot have access to these systems due FERC standards of conduct requirements. Attachment 1 and R2 are not consistent with the definition of Interoperability Communications. By definition, Interoperability Communication pertains to all communications about how entities change the state of the BES (not just about physical or cyber attacks). Attachment 1 is only about notifying of what physical and cyber attacks have already happened to the BES .
Disagree
There is no reliability need to use a common time zone for communications. There is already a requirement to use hour ending for scheduling purposes, inadvertent accounting, CPS and other standards where needed. The time zone should be identified in the communication. Use of CST in all time zones will actually cause confusion and significant and unnecessary costs with no foreseeable reliability benefit. Some of the costs will arise to change systems such as RCIS, IDC, scheduling and E-Tag systems, etc.
Disagree
Based on the definition of Interoperability Communications, R5 implies that three-part communications is required to communicate routine operating instructions. We believe this Requirement contradicts the work that has been done and substantially progressed through two other SDTs and creates confusion within the industry. We believe this Requirement would, in fact, be adverse to reliability instead of enhancing reliability by reducing the amount of pre-action communications that may occur prior to taking action because operators may be more concerned with not repeating back during such pre-action, strategic calls and/or discussion. We support the work being done by the RC SDT and RTO SDT in Project 2006-06 which would define a Reliability Directive based on the determination of the person giving such an order. We believe, it should be left to the entity that needs the action to be taken to establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger and auditable and measureable. R5 is not consistent with the Functional Model. Only the RC, BA, and TOP can issue directives.
Disagree
While this Requirement may represent a good utility practice in certain situations, it is not necessary to be used in all verbal Interoperability Communications and is certainly not necessary to be included as an enforceable Requirement. Imagine the situation in which an operator says “A as in apple” instead of using the NATO Alpha. Even though the listener should clearly be able to discern the correct meaning, the speaker’s company could be sanctioned even if the correct actions were taken as a result of the clear communication. There is no reliability need for this Requirement.
Disagree
This may represent a good utility practice but it is not necessary to be included as a Requirement. The key question is: “Do the companies’ personnel understand one another?” If I know that my company refers to a tie-line as Alpha and my neighboring company calls it Beta, I know what he means when communicating to me. That is all that matters. This is a “how” based Requirement that should be eliminated.
Disagree
It is not clear what value is realized by declaring an alert status particularly with regard to cyber and physical attacks. There does not appear to be any differing actions taken based on the alert status. Given that no differing actions are taken for cyber and physical attacks, it seems it would be more beneficial to use specific information such as 12 substations have been physically or cyber attacked. This is more meaningful than issuing a red alert that would only indicate more than one site has been attacked. Furthermore, we question the value of communicating the physical and cyber alerts. How does this notification help the BES reliability? Consider the following example. One BA in Oklahoma is 34,323 sq miles. Communicating that an attack occurred in the BA and RC tells other operators that somewhere in Oklahoma an attack occurred. This notification does not present any information that could require actions on the operators’ parts and will only generate phone calls for more information. Furthermore, PSE and CSE is a type of sabotage which is reported in CIP-001 R2 already. TEA Alerts are already covered in IRO-006-East-1, IRO-009, IRO-010, IRO-014.01 R2. Distribution Service Providers should be Distribution Provider to be consistent with the Functional Model.
Disagree
 
Disagree
 
Agree
We believe that the existing standard COM-002 is better than this proposed Standard. This Standard actually causes more confusion and ambiguity and creates unnecessary or overly cumbersome requirements that add little or no value to reliability. Additionally, we cannot understand how all requirements but R1 have been determined to have a HIGH VRF when, many of them are dictating HOW communications should take place and not when and why or what. The stated retirement of COM-002 does not appear to be consistent with the direction of the RC SDT in Project 2006-06. The RC SDT is adding requirements. More coordination is certainly required between these two teams. In addition, as stated earlier, this Standard focuses on “how” certain tasks should be performed and conflicts with NERC’s position of pursuing performance based and results based Standards.
Individual
Dustin Smith
Washington City Light & Power
Disagree
 
Disagree
 
Disagree
We believe that it may be important for entities registered as a Reliability Coordinator, Balancing Authority, Transmission Owner, Transmission Operator, Generator Operator, Transmission Service Provider , Load Serving Entity and Distribution Provider to have a formalized Communications Protocol Operating Procedure (CPOP) for Interoperability Communications, but this requirement will place an unnecessary burden on the personnel at many of the smaller Load Serving Entities and Distribution Providers on the NERC Compliance Registry. In most real-time scenarios, the BES facilities are not operated nor maintained by the Load Serving Entity or Distribution Provider. As with many standards, entities will be required to demonstrate why the standard/requirement is applicable.
 
 
 
 
 
 
 
 
 
Individual
Kirit Shah
Ameren
Disagree
The definition for three part implies the exact message must be repeated back. What should be said is the content must be repeated back in original or modified forms such that the originator is sure the recipient understands and can execute the action. As far as Interoperability, what is state or status? Is the dispatch instruction to change from 500 MW to 505 MW such a communication? (which changed, state or status?)
Agree
 
Disagree
This is a near fill-in-the-blank requirement. The mere inclusion, or recitation, of the R2-7 elements does not assure a meaningful plan. It is easy to say “Our plans includes R3”. That does not assure reliable communications. This requirement should describe a functional CPOP.
Disagree
This is an ambiguous reference in all of NERC standards for all but the RC. How would an LSE interpret this in communication between them and a DP. Would there ever be a red condition for issues that affect them? And as it relates to operating, it looks like this is exclusive of EEA type events, i.e. BA type emergencies seem to not be represented. It would seem that the pre-defined conditions should be established for each interaction that each entity might have, e.g. a predefined set for a BA to a TOP, a BA to an LSE, et al. While each entity can certainly address the 3 scenarios in Attachment 1 (RC to entity) those are not the only conditions where communication affects BES reliability.
Disagree
We agree that all inter-entity operability communication should be on common time zone but if said communication includes routine dispatch instructions several RTOs use EST time for market operations, would they then need to change to CST? And while CST seems to have some value because it is used for time error, wouldn’t it make more sense to use UTC? It is a world standard and has the benefit of not being associated with daylight savings times as Central time does (may be confusion at some times between CST and CDT)
Agree
 
Disagree
Requirement should be revised to say that Attachment 2 needs to be used when single alphabetic characters, or when needed for clarity, are needed in communications. If we have a Bee Hollow-51 circuit, that is alpha-numeric information. But we wouldn’t support that Bee Hollow needs to be spelled out as Bravo-Echo-Echo-space-Hotel…….
Agree
But how does CMEP process check this “mutually agreed”. Much more work needs to be done with this requirement and measures to address this.
Agree
As stated earlier, this is an excellent document for RC interactions. But it is wholly unclear how this impacts other entity-to-entity relationships in pre-defining states. And as mentioned having only Attachment 1 seems to ignore the energy balance alerts/emergencies
 
 
We understand the binary function of VSL that forces Severe for most requirements. However, the standard itself seems to offer some hope with the definition to address the VSL issue better. The definition has at the end, “especially during alerts and emergencies” Given that this implies stratification, couldn’t Severe VSL be assigned to violations during emergencies, High be assigned to alerts, and moderate to all other system conditions. When emergency conditions exist, entities should have their “A” game on, and failure to communicate during these times is a more severe violation of the communication protocols than during the thousands of daily interactions that are note likely to affect BES, (alternatively, the VRF could be adjusted for the situation)
Individual
Kathleen Goodman
ISO New England Inc.
Disagree
The way the definition of Three-part Communication is worded applies only when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should rather reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it. We believe the term “Interoperability Communication” contradicts the work by the RTO and RC SDT that limits the requirement to use three-part communications to only those communications that explicitly state that the communication is a Reliability Directive and creates confusion within the industry. Additionally, it appears that this definition would encompass all verbal communications and, as such, we question the need for such definition. While we support using three-part communications during routine operations as a best operating practice, we do not believe that it is so critical to reliability that it becomes an enforceable requirement for routine operating instructions. Rather we believe the enforceable requirement should be left to the entity that needs the action to be taken to establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger and auditable and measureable.
Disagree
This requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how. The only real need for a requirement is to establish that each entity issuing a directive shall use three-part communications and the recipient of a directive shall also properly participate in the of use three-part communication protocol until the message has been correctly spoken and comprehended.
Disagree
It is not clear what the purpose of this communication protocol is or what should even be included in the protocol. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions. The NERC BOT has approved pursuing the Performance-based Reliability Standard Task Force’s recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to delineate actionable reliability requirements from record/documentation requirements. This proposal takes the opposite approach and incorporates a new administrative requirement. We – and the industry as a whole based on the response to the Task Force – do not support such an approach. We suggest deleting this Requirement from the Standard. Furthermore, the establishment of R2-R7 as elements of the CPOP required in R1 appears to contradict the recent shift in direction that NERC has taken regarding defining criteria as bullets under a requirement. See NERC’s August 10th informational filing regarding assignment of violation risk factors and violation severity levels in regards to dockets RM08-11-000, RR08-4-000, RR07-9-000, and RR07-10-000. COM-003 R2 states: “shall use pre-defined system condition terminology as defined in Attachment 1-COM-003-1 for verbal and written Interoperability Communications.” Why does R1 establish the requirement for a procedure, when the procedure is essentially defined by R2-R7. If there is such a reliability need to establish these requirements, one could conclude nothing else is so important that it needs to be included because it is not identified in the standard. Furthermore, R2 appears to define Interoperability Communications for attachment 1 communications only. Is this the intent of the drafting team?
Disagree
It is not clear what value there is in identifying alert levels. There does not appear to be any differentiation in actions taken based on the alert levels. Why not just state the number of substations attacked, etc? Further, the “pre-defined” system conditions and alert levels are too detailed and overly prescriptive. System operators need to spend time looking for the right color and level to communicate the prevailing system condition terminology to avoid violating the standard. This task does not lend itself to promptly and effectively deal with the emergency situation. Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the parties such as Distribution Provider and Generator Operator cannot have access to these systems due FERC standards of conduct requirements. Attachment 1 and R2 do not appear to be in synch primarily due to the definition of Interoperability Communications. By definition, Interoperability Communication is about how entities change the state of the BES and Attachment 1 is about notifying of what already happened to the BES.
Disagree
There is no need to use a common time zone for communications. There is already a requirement to use hour ending for scheduling purposes, inadvertent accounting, CPS and other standards where needed. There is no demonstrated benefit to reliability to use a common time zone. The time zone should be identified in the communication. Use of CST will cause significant and unnecessary costs and the resulting reliability benefit is not clear. Some of the costs will arise to change systems such as RCIS, IDC, scheduling and E-Tag systems, etc. Not only does this requirement attempt to determine HOW entities operate within their various footprints, it would significantly change the way many markets are structured. To implement this into existing Markets would cost significant time, money and resources while not enhancing reliability in these areas. We believe that, when operating across time-zones, simply referencing “Central Standard Time” or “Eastern Standard Time” is sufficient for other operating entities to reliably operate; also, let’s not lose sight of HOW MANY entities would have to modify their existing practices, hardware, software, Control System, billing systems, bidding systems, etc. We, and our members, are strongly opposed to this requirement.
Disagree
Based on the definition of Interoperability Communications, R5 could imply that three-part communications is required to communicate routine operating instructions. We believe this Requirement contradicts the work that has been done and substantially progressed through two other SDTs and creates confusion within the industry. We believe this Requirement would, in fact, be adverse to reliability instead of enhancing reliability by reducing the amount of pre-action communications that may occur prior to taking action because operators may be more concerned with not repeating back during such pre-action, strategic calls and/or discussion. We support the work being done by the RC SDT and RTO SDT which would define a directive based on the determination of the person giving such an order. We believe, it should be left to the entity that needs the action to be taken to establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger and auditable and measureable.
Disagree
Not only does this requirement attempt to determine HOW entities operate with their various footprints, it may change the way many Markets are structured. What is the difference between using the word “Zebra” instead of “Zulu” to signify the letter “Z”? And, why would this be enforceable? Perhaps this would be better served as a guideline document rather than and enforceable Requirement. Also, many organizations may have established communications protocols which are functioning properly and making a change may actually hinder reliable operations by introducing unnecessary confusion.
Agree
We agree that the stipulation of a single/unique identifier is unnecessary as long as all parties mutually agree on the identifier for the line or equipment, and therefore, support this change to the existing Requirement in TOP-002.
Agree
It is not clear what value is realized by declaring an alert status particularly with regard to cyber and physical attacks. There does not appear to be any differing actions taken based on the alert status. Given that no differing actions are taken for cyber and physical attacks, it seems it would be more beneficial to use specific information such as 12 substations have been physically or cyber attacked. This is more meaningful than issuing a red alert that would only indicate more than one site has been attacked. Furthermore, we question the value of communicating the physical and cyber alerts. How does this notification help the BES reliability? Consider the following example. One BA in Oklahoma is 34,323 sq miles. Communicating that an attack occurred in the BA and RC tells other operators that somewhere in Oklahoma an attack occurred. This notification does not present any information that could require actions on the operators’ parts and will only generate phone calls for more information. Furthermore, PSE and CSE is a type of sabotage which is reported in CIP-001 R2 already. TEA Alerts are already covered in IRO-006-East-1, IRO-009, IRO-010, IRO-014.01 R2. Also, several entities have observed confusion during the field-test of these Alert Levels because there are inconsistencies in the implementation of various stages of Alerts. It certainly has not enhanced Reliability. Attachment 1 contains a conflict. The last sentence of the opening paragraph of Attachment 1 reads, “The time frame for declaration of these Alert states shall be consistent with the approach used to declare EEAs and would normally apply to Real Time declarations and not forecast conditions.” In Transmission Emergency Alerts Condition Yellow, Orange and RED: The Reliability Coordinator or Transmission Operator foresees or is experiencing conditions where all available generation resources are committed to respect the IROL and/or is concerned about its ability to respect the IROL. “Forsees” is a forecast condition. In condition Orange and Red for TEA Level Two/Three, the initial notification requirements are redundant with IRO-006-East-1 R3.2. Under the Make Final Notifications, is curtailed intended to mean canceled or terminated? The term Curtailed in operations generally means cuts for schedules/tags. EEA’s use terminated. We recommend using terminated. Distribution Service Providers should be Distribution Provider to be consistent with the Functional Model.
Agree
Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the parties such as Distribution Provider and Generation Operator cannot have access to these systems due FERC standards of conduct requirements. Requirement 2 and the listing of functional entities required to be notified within the RC footprint in attachment 1 create a de facto requirement for them to have RCIS access or an unnecessary burden to communicate with all functional entities listed separately. Having to communicate to all functional entities in that list verbally and individually would create an unnecessary burden that distracts the RC from actual system operation and represents a detriment to reliability.
Agree
In some market structures, TSPs and LSE do not own or operate equipment. Thus, including them in the requirements is an unnecessary burden for these areas. The requirement to use CST attempts to determine HOW entities operate within their various footprints and it would significantly change the way many Markets are structured. To implement this into existing Markets would cost significant time, money and resources while not enhancing reliability in these areas. We believe that, when operating across time-zones, simply referencing “Central Standard Time” or “Eastern Standard Time” is sufficient for other operating entities to reliably operate; also, let’s not lose sight of HOW MANY entities would have to modify their existing practices, hardware, software, Control System, billing systems, bidding systems, etc. We are strongly opposed to this requirement.
Agree
We believe that the existing standard COM-002 is actually better than this standard. This standard causes more confusion and ambiguity and creates unnecessary or overly cumbersome requirements that add little or no value to reliability. Additionally, we cannot understand how all requirements but R1 have been determined to have a HIGH VRF when, many of them are dictating HOW communications should take place and not when and why or what. COM-002 retirement does not appear to be consistent with the direction of the RC SDT. The RC SDT appears to be adding requirements. More coordination is requirement between these two teams. Recommendation 26 of the August 14, 2003 blackout report is cited as a driver for extending three-part communications. We believe the title of Recommendation 26 is misleading and when reviewed separately from the supporting text of the recommendation and direct and contributing factors in the report results in an incorrect interpretation. “Failure to identify emergency conditions and communicate that status to neighboring systems” is one of the contributing factors and the supporting text of the recommendation clearly refer to shoring up communications during emergency and anticipated emergency conditions and establishing an emergency broadcast communication system to alert regulatory, state and local officials. The supporting text of Recommendation 26 only mentions addressing alerts, emergencies or other critical situations. Some have incorrectly inferred the initial clause of Recommendation 26, “Tighten communication protocols”, means the recommendation applies to all routine communications. Lastly, this on-line submittal asks many questions that are YES/NO in nature (i.e. "do you have any concerns with...", or "if, yes, please explain...") but the radial selections are "agree/disagree" which may be taken out of context. We suggest changing the on-line submittal back to YES/NO.
Group
ATC and ITC
Jason Shaver
Disagree
ATC believes that the proposed definition for the term “Interoperability Communication” is too broad and ambiguous. We recommend the following: “Communication between two or more Functional Entities (not within the same organization) to exchange reliability-related information to be used by the entities to change the state or status of Facilities of the Bulk Electric System.” The inclusion of the terms “Functional Entities” and “Facilities” removes the ambiguity which we believe is contained in the proposed definition. (Both of these terms are defined in NERC’s Glossary) In addition, the inclusion of the phrase “not within the same organization” clarifies that the focus of definition is to address communication between different Functional Entities. ATC understands that this Drafting Team is working closely with the Drafting Team working on Project 2006-06 and believes that this team needs to use the term “Reliability Directive” as a replacement for the term “directive” which is currently being used. The Drafting Team working on Project 2006-06 has defined Reliability Directive as: “A communication initiated by a Reliability Coordinator, Transmission Operator or Balancing Authority where action by the recipient is necessary to address an actual or expected Emergency.”
Disagree
TOP-002 R18 states that BA, TOP, GOP TSP and LSE shall use uniform line identifiers when referring to transmission facilities of an interconnected network. COM-003 R7 states that each RC, BA, TO, TOP, GOP, TSP, LSE and DP shall use pre-determined, mutually agreed upon line and equipment identifiers for verbal and written Interoperability Communications. TOP-002 allowed the TOP to communicate what the line identifiers were via a list and use during communications. The new requirement implies that the parties must agree upon the line identifiers and that agreement must be documented. ATC believes that the requirement should state that “mutual agreement” allows for multiple identifiers. We believe that this is needed in order to avoid the following issues. 1) This clarification will avoid any need for arbitration or formal dispute resolution steps. 2) If the standard does not allow for this provision entities will be forced to deviate from their own line naming convention and will result in entities to modify their drawings, field signs, and SCADA systems.
Disagree
: Based upon the concerns that we have with R2-R7 we would not support this requirement. We would support the requirement if it stopped after the first sentence and then merely listed the minimum requirements that should be included in the Procedure such as; (1) time zone, (2) language spoken, (3) when phonetic alphabet will be used, etc.. This will allow the Entities to draft their own CPOP per the intent of the requirement and avoid the concerns that we have documented for the remainder of the requirements.
Disagree
The Attachment pertains to requirements of the RC, not all entities. Either the attachment should be changed or the requirement should be changed for accurate accountabilities.
Disagree
ATC is in the Central Standard Time zone, and would not be directly impacted by this requirement. With that being said we are concerned that forcing an organization to refer to a time zone that is not local may result in an increase of errors and a decrease in reliability. See comments for question #3.
Disagree
ATC believes that the term “directive” should be replaced with the term “Reliability Directive” which is being developed under Project 2006-06. It is important for BES reliability that NERC use clearly defined term which will identify the circumstances under which this requirement is enforceable. We provide the definition for “Reliability Directive”, as it appears in the latest posting for Project 2006-06, in our response to question 1. It is our understanding and interpretation that the intent of this requirement is to require entities to use Three-Part Communication during emergency situations in which “Reliability Directives” are being issued. In other words this requirement as proposed does not apply to normal (non-emergency) day-to-day switching. The replacement of the term “directive” with “Reliability Directive” provides the additional clarity around an entity’s compliance obligation.
Disagree
The use of the phonetic alphabet should be documented in the Entities CPOP per our comments to question #3. We do not agree that it needs to be included in Requirement 5 because it is too prescriptive and all encompassing and could potentially confuse or slow down the communication process. As we recommended in question 6 the term “directive” should be replaced with “Reliability Directive”.
Disagree
TOP-002 R18 states that BA, TOP, GOP TSP and LSE shall use uniform line identifiers when referring to transmission facilities of an interconnected network. COM-003 R7 states that each RC, BA, TO, TOP, GOP, TSP, LSE and DP shall use pre-determined, mutually agreed upon line and equipment identifiers for verbal and written Interoperability Communications. TOP-002 allowed the TOP to communicate what the line identifiers were via a list and use during communications. The new requirement implies that the parties must agree upon the line identifiers and that agreement must be documented. ATC believes that the requirement should state that “mutual agreement” allows for multiple identifiers. We believe that this is needed in order to avoid the following issues. 1) This clarification will avoid any need for arbitration or formal dispute resolution steps. 2) If the standard does not allow for this provision entities will be forced to deviate from their own line naming convention and will result in entities to modify their drawings, field signs, and SCADA systems.
Disagree
See question #4.
Disagree
 
Disagree
 
Disagree
 
Group
FirstEnergy
Sam Ciccone
Disagree
Three-part Communication � The phrase "the information is repeated back correctly" may pose compliance problems if the second party does not repeat the information back correctly the first time. We suggest the definition be revised as follows: "A Communications Protocol where information is verbally stated by one person to a second person whereby communication is initiated, the second person repeats the information back to the first person as means to verify the communication. The initiating party either confirms the response as correct or repeats the original statement and resolves any misunderstandings." Interoperability Communication � We recommend this definition be removed and be incorporated into the RCSDT's proposed definition of Reliability Directive. Please see our comments in Question 6 for a complete explanation.
Agree
 
Disagree
We feel that procedures are beneficial for entities to have as far as internal training of new personnel and as a reference guide for all personnel, but we do not agree that it should be a requirement of a reliability standard. It is not appropriate to subject an entity to monetary fines for not having a procedure even if that entity has fully complied with all the other requirements (R2 through R7) of this standard that the procedure is referencing. Although this requirement may fall into the category of best practices and administrative requirements, it certainly does not rise to the level of performance-based, risk-based, or competency-based requirements. The real evidence of an entity implementing R2 through R7 is by evaluating the measures of those requirements and a variety of information could be used by an entity such as training records, procedures, voice recordings etc. Having a procedure does not need to be a stand alone requirement.
Disagree
We do not support R2 and its referenced attachment and feel that they should be removed. The requirement and attachment are too convoluted, create confusion among system operators, and not necessary with regard to the goal of this standard. This standard mandates proper three-part communication in all reliability-related communication (including alert level situations). Other standards should define and mandate rules associated with the specifics surrounding urgent action situations (i.e. CIP, TOP, EOP standards). Together these standards will arrive at proper communication between entities during alerts.
Disagree
Using a specific time zone that is subject to adjustments for daylight savings introduces additional complexity for an operator and has potential to introduce additional reliability issues. A significant portion of the Eastern Interconnection transmission operators have dealings with entities that do not span multiple time zones and are solely within the Eastern Time Zone. We do not feel that it is appropriate for this standard to mandate how time is communicated during three-part communication. Operating communication can deal with several different subjects and data during a conversation, and it would be inappropriate to mandate all the possible subjects and data through standard requirements. As a best practice, and not as a mandated requirement, it would be appropriate for operators to state the time zone they are in if necessary for the situation or if requested by an entity.
Disagree
Although we agree that proper communication should be used during actions that affect the reliability of the BES, we do not agree with this requirement as written. The following contains our rationale and suggestions: 1. The lower case term "directive" is ambiguous, not defined, and confusing. This is especially true in light of the proposal of the RCSDT to modify COM-002-3 to include a definition of "Reliability Directive" and their plan to use this defined term to invoke 3-part communication. Since the plan of this OPCPSDT is to eventually incorporate the COM-002-3 requirements into this new COM-003-1 standard, we feel the definition of Reliability Directive should be moved to this standard now (instead of later) and the term should be broadened to include any actions that affect the BES reliability. Essentially then, the current proposed R1 of COM-002-3 can be moved to this COM-003-1 standard. 2. Our proposal for the term Reliability Directive in item 1 above incorporates the verbiage of the proposed Interoperability Communication definition. Therefore, the proposed term Interoperability Communication is no longer required and can be eliminated. 3. Once the term Reliability Directive and proposed R1 from COM-002-3 are moved to this COM-003-1 standard, the current R5 of COM-003-1 requiring the use of Three-Part Communication could then be revised to require three-part when a Reliability Directive is issued and continue until the operating condition that invoked the Reliability Directive is resolved, mitigated, or ended. 4. With respect to the proposed R2 and R3 of COM-002-3 which essentially discuss three-part communication, these requirements could be eliminated and would be covered by COM-003-1. As a result, the COM-002-3 requirements being proposed by the RCSDT can be eliminated in their entirety since we have now incorporated all of them into this new COM-003-1. 5. Since COM-002-3 included the Purchasing-Selling Entity as an applicable entity, since they could be the recipient of a Reliability Related Directive and since, with our proposed changes, COM-002-3 can be retired; the Purchasing-Selling Entity can be added to the applicability section of and incorporated into this new COM-003-1 standard as recommended below. In conclusion, we suggest the following changes/additions to COM-003-1: A. Move a revised version of the term "Reliability Directive" from COM-002-3 to this new COM-003-1 standard and define it as follows: "A communication initiated by a Reliability Coordinator, Transmission Operator, or Balancing Authority where the recipient is directed to change the state or report the status of an Element or Facility of the Bulk Electric System." B. Delete proposed definition "Interoperability Communication". C. Delete R2 and R3 of COM-002-3 as suggested in item 4 above. D. Insert a New Requirement R4, renumbered as R2, into new standard COM-003-1 taken from COM-002-3 R1: "When a Reliability Coordinator, Transmission Operator or Balancing Authority issues a Reliability Directive, the Reliability Coordinator, Transmission Operator or Balancing Authority shall identify the action as a Reliability Directive to the recipient. [Violation Risk Factor: High][Time Horizon: Real-Time]" E. Revise Requirement R5 and renumber as R3: "Each Reliability Coordinator, Balancing Authority, Transmission Owner, Transmission Operator, Generator Operator, Transmission Service Provider, Load Serving Entity, Distribution Provider, and Purchasing-Selling Entity shall use Three-part Communication for all communications concerning a Reliability Directive that was issued per Requirement R1 and continuing until the actions or status reporting identified in the Reliability Directive has been completed. [Violation Risk Factor: High][Time Horizon: Real time]" F. Add the Purchasing-Selling Entity as an applicable entity to COM-003-1.
Disagree
While we agree that using the NATO phonetic alphabet may be a best practice, we feel that it is not practical to regulate its use. This requirement is too prescriptive. The focus should be on the correct understanding of verbal communication which will be accomplished via Three-party Communication, whether an entity uses NATO or "A as in Apple, B as in Boy", this should not be codified within the standard. Substantiating compliance with this requirement is not reasonable to expect, practical to prove, nor does it produce an improvement in reliability.
Disagree
Although we agree with moving this current TOP-002 R18 requirement to this standard, we question the use of the phrase "mutually agreed upon". It is not clear how the line and equipment identifiers will be mutually agreed upon and how this will be measured. We suggest using similar wording from the current TOP-002 R18 and reword COM-003-1 R7 as follows: "Each Reliability Coordinator, Balancing Authority, Transmission Owner, Transmission Operator, Generator Operator, Transmission Service Provider, Load Serving Entity and Distribution Provider shall use uniform line and equipment identifiers for verbal and written communications."
Disagree
We do not support Att. 1 and feel that it should be removed. This attachment is too convoluted, creates confusion among system operators, and not necessary with regard to the goal of this standard. This standard mandates proper three-part communication in all reliability-related communication. Other standards should define and mandate rules associated with the specifics surrounding urgent action situations (i.e. CIP, TOP, EOP standards). Together these standards will arrive at proper communication between entities during alert level situations.
Not aware of any
Not aware of any
Agree
Coordination of SDT Efforts – We feel that the NERC Standards Committee should direct the Reliability Coordination SDT to hand over COM-002 to this OPCPSDT since those requirements will eventually be moved to COM-003-1. It is difficult to coordinate all these changes on a separate basis and moving the development to one SDT would help better coordinate these efforts. The current path forward is inefficient and causes confusion, not only for industry but also for the two drafting teams. Purpose Statement – We feel the phrase "especially during alerts and emergencies" implies that using proper communications protocol during normal operating situations is not as important as during emergencies. It is not appropriate to include this phrase in the purpose statement of a standard, and we suggest it be removed. Also, we suggest removing the word "timely" since this standard does not mandate time limits on communications. Compliance Section 1.4 Data Retention – We do not agree with the following statement for data retention "If a Transmission Operator, Transmission Owner, Balancing Authority, Reliability Coordinator, Generator Operator, Transmission Service Provider, Load Serving Entity or Distribution Provider is found non-compliant, it shall keep information related to the non-compliance until found compliant." We feel that this is not appropriate in a reliability standard since it is already mandated through Compliance Violation Investigations (CVI). Also, we feel that it is more applicable to NERC’s Rules of Procedure. Therefore, we suggest it be removed from the standard.
Group
Pepco Holdings, Inc. - Affiliates
Richard Kafka
Disagree
PHI believes the proposed definition for the term Interoperability Communication is too broad and ambiguous.It is inconsistent with the effort to develop results based standards which would have an effect in the reliability of bulf electric system. Additionally, PHI does not see the need of a definition of Interoperability Communication now that the term Reliability Directive has been defined in draft standard COM-002-3 which is currently posted for review.
Agree
 
Disagree
PHI agrees that communications procedures are necessary. We do not see the need to create a CPOP that includes requirements R2 through R7 given that each requirement defines how and what is to be communicated. This requirement as written could force entities to incorporate all of their communication procedures into a CPOP which will not improve reliability.
Disagree
Requiring system operators to use the color-coded system condition terminology during communication adds a layer of responsibility that will distract from the operator’s real-time reliability-related tasks.
Disagree
PHI believes that mandating one time zone for all Interoperability Communications will create more confusion during an emergency that it will prevent and may contribute to increased reliability issues.
Disagree
: As mentioned in Question 1 above, the term Reliability Directive has been defined in the draft standard COM-002-3 and should be considered in place of Interoperability Communication since the directive is specific to emergency operations. PHI recommends that the requirement changed to read “Each responsible entity shall use Three Part Communication when issuing or receiving a Reliability Directive”.
Disagree
Having system operators potentially struggle to remember the NATO phonetic alphabet during communications rather than focus on the communication and managing the bulk electric system itself is in contradiction with the purpose of the standard. Use of the NATO phonetic alphabet should be considered a “best practice” and should not be included as a requirement in a reliability standard. One failure, such as saying “Baker” instead of “Bravo”, results in a severe violation without any impact on system reliability.
Disagree
This requirement came from TOP-002 R18 and is fundamentally different from the new proposed requirement in COM-003-1 R7. TOP-002 R18 states that the BA, TOP, GO, LSE and TSP shall use uniform line identifiers when referring to transmission facilities of an interconnected network. The requirement in COM-003-1 R7 introduces an additional requirement to use pre-determined “equipment” identifiers is another example of a prescriptive requirement that will not impact bulk electric system reliability and will expose entities to large fines. PHI believes the TOP-002 R18 could be included in COM-003-1 but included as defined in TOP-002 R18.
Agree
As noted in our comments to Question 4, Attachment 1 has examples for Reliability Coordinators only. It is not a good guide for other Interoperability Communications. Additionally, Attachment 1 identifies the Level 1, Level 2 and Level 3 communications by color codes that are not referenced in the sample messages. PHI finds the addition of color codes to not be helpful and possibly confused with national security Alert Levels. The color coding should be eliminated and examples for entities in addition to the Reliability Coordinator should be included.
Agree
PHI asserts that WECC would say NO to Central Standard Time.
Disagree
 
Disagree
 
Individual
Henry Masti
NYSEG
Disagree
The definition for Interoperability Communication needs to be further explained. The current definition would appear to include not only communication between two control centers, but also between a control center and field personnel for all normal and routine switching, which we do not believe is the intent of the Standard. Communication Protocol as a separate definition does not appear to be necessary. The provided definition describes the term in a simple and generic way and is not specific enough to provide anymore guidance than is already provided in a general understanding of the word “communication” or “protocol”. Three-part communication should be revised as follows: An iterative process where verbal communication from a sender to receiver is repeated back to the sender by the receiver to eventually ensure correct and accurate transmission of the entire message. We believe this definition is more consistent with COM-002 R2, which is proposed to be retired once COM-003-1 is approved and Three-part Communication is adopted.
Agree
 
Disagree
It is not clear when the Interoperability Communication is required to be used. Is it only for communications between registered entities (inter) or internal to a registered entity (intra)? And is it required for all communications or used only in certain circumstances (i.e. emergency (if emergency, it needs to be defined what constitutes an emergency))?
Disagree
R2 indicates the need to use pre-defined system condition terminology for all verbal and written Interoperability Communications yet Attachment 1 only defines transmission loading and physical and cyber security threats. Either need to rewrite the Requirement to include only these circumstances, or define every possible system condition used in Interoperability Communications. Additionally, there does not appear to be any benefit in attempting to pre-define transmission loading, and physical and cyber alert system conditions since the actions associated with each are similar, if not the same, for almost all conditions.
Disagree
Unless the communication is across time zones, there is no benefit to using Central Standard Time, nor is it sensible. Entire system infrastructures and business processes are driven by current, local standard time and it is far more safe, reliable, and practical to use the established current time for system operations. If there is a compelling need for definitive time notation across time zones then the requirement should dictate the addition of the time zone when referring to a specific clock time (i.e, 1400 CST, 1400 EST, 1400 ED[aylight]T, etc.).
Disagree
The definition of Three-part Communications and Interoperability Communications needs to be revised as explained above.
Disagree
While it is perhaps a good practice to include the use of phonetics to avoid miscommunications, it should be left up to each entity to determine the appropriateness of adopting such a practice (e.g., field switching, internal instructions, etc.) and should not be included in the Requirement, especially if Interoperability is not further clarified/defined.
Agree
COM-003-1 R7 is more clearly defined than TOP-002 RI8 in that R7 and associated M7 speak only to written and verbal Interoperability Communication, where TOP-002 R18 and M10 dictate a more extensive use of the identifier. The adoption of a more narrow purpose is preferred.
Agree
There does not appear to be any compelling practical or reliability reason to adopt the Attachment.
Disagree
 
Disagree
 
Disagree
 
Individual
Jose Medina
NextEra Energy Resources, LLC
Agree
 
Disagree
This requirement is already covered by TOP-002. If the TOP-002 standard is deemed deficient because certain entities have been excluded or language appears to be missing, the changes need to occur to TOP-002 as opposed to copying and revising the existing requirement elsewhere. This would ensure that compliance oversight, understanding, and adherence goals are unencumbered by unnecessary redundancies. Moreover, this would ensure that the industry continues to re-enforce standards with changes that are within the scope of their original reliability purpose. The latter is in line with one of the core objectives of the Performance-based Reliability Standards Task Force’s recommendations to focus on identifying and minimizing duplicated requirements.
Disagree
NextEra agrees with the reliability goal of establishing a set of agreed upon communication standards to ensure consistent communications particularly for actual and anticipated emergency coordination needs. NextEra believes that existing coordination/communication standards already fulfill this objective and that it might be of “training” or “reference” value to aggregate those requirements to a single document or view. However, NextEra is not convinced that this requirement, largely administrative in nature, will result in marked improvement in reliability. Organizations tend to take the path of least resistance and unless forced out of that path with extensive and granular guidance on what CPOPs should contain above and beyond existing standards or contract language, CPOPs would likely become a simple patchwork of requirements constructed out of existing NERC standard language and contract language. Standards need to be clearly implementable before they are approved yet important implementation questions do not appear to have been answered. (1) What if parties cannot reach agreement? (2) Is it enough to have attempted to coordinate? (3) What if parties already have agreed upon procedures such as NPIRs, or those stated in Interconnection Agreements – do they take precedent or must they be redesigned/relegated? (4) What if CPOPs differ greatly across interconnections because of differing parties? (One might conclude that by formalizing these different practices, as opposed to mandating standard practices, the goal of more reliable coordination may not have been achieved) (5) What level of evidence constitutes “agreement” especially in circumstances where entities may be remiss to agree? (6) What if CPOPs are simply a patchwork of requirements constructed out of existing NERC standard language and contract language – does that achieve the CPOP goal?
Disagree
NextEra agrees that standard system condition terminology could be beneficial in communications but this requirement introduces alert level conventions with no clarity on what the corresponding associated actions for such levels are and as a result, aside from the value derived from having improvement in terminology during communications, it is unclear what reliability improvements this will achieve in carrying out instructions.
Disagree
Existing market and reliability communication methods already ensure that time-zone adjustments occur. It is critical that the feasibility, impact, and logistical aspects of implementing this change be rigorously reviewed and understood to inform this standard’s development. Conceivably, the result of that analysis could expose significant risks outweighing the purported benefits of implementing a single time-zone policy. Any implementation or transition gaps between the time format and references used by reliability coordinators, their corresponding systems, and the interfaced systems of market participants would be extremely detrimental to system stability and ongoing market operations.
Disagree
NextEra believes that by associating the “3-part communication” method with “directives” this standard drafting team could be at risk of unintentionally defining a directive as anything that takes the 3-part communication form. We would encourage the standard drafting team to continue to use the terms already employed in the draft standard: “… three-part communication be used when issuing instructions related to actual or expected emergency conditions.”
Disagree
NextEra believes that though aspiring to use a single strict phonetic alphabet may be beneficial it is more important to ensure that ease of communication takes precedent especially under emergency conditions. The requirement for 3-part communication already ensures that understanding between two parties occurs. Moreover, it is overly burdensome to require that the phonetic alphabet be used in all communications which would include communications related to mundane interactions between interconnected parties and that might broadly fit the mold of the “interoperability” definition but not truly require the formality or rigor commanded by a phonetic approach.
Disagree
NextEra believes that R7 should be withdrawn as it repeats TOP-002 R18 requirements. Please refer to comments on Q3.
Disagree
None at this time.
Disagree
None at this time.
Disagree
None at this time.
Agree
In the case of nuclear plant operations, NRC communication requirements and the requirements of NERC NUC-001 for nuclear facilities more than adequately cover communication requirements. COM-003 should not be applicable to Nuclear Generator Operators since doing so will introduce an additional, unnecessary, and potentially conflicting level of requirements. Measures: NextEra suggests that the SDT clarify the periodicity of providing evidence of compliance and on what constitutes sufficient evidence of CPOP acceptance. Violation Severity Levels: NextEra encourages the SDT to revisit the violation severity levels. In the case of most of the requirements it is unreasonable to levy Severe penalties in instances where the operator may have deviated from the requirements but the communication occurred in an unencumbered and successful manner as evidenced by the use/acknowledgement outcomes of three-part communication.
Individual
Dan Rochester
Independent Electricity System Operator
Disagree
The way the definition of Three-part Communication is worded seems to only apply when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation. The definition should, rather, reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back to the party that initiated the communication by a second party that received the communication, and the information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it.
Disagree
This requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how. The only real need for a requirement is to establish that each entity issuing a directive shall use three-part communications and the recipient of a directive shall also use three-part communication protocol until the message’s correct understanding is confirmed.
Disagree
It is not clear what the purpose of this communication protocol is or what should even be included in the protocol. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions without inclusion of the elements to be communicated as they cover a wide range of conditions which can vary among the communicating parties.
Disagree
It is not clear what value there is in identifying alert levels. There does not appear to be any differentiation in actions taken based on the alert levels. Why not just state the number of substations attacked, etc? Further, the “pre-defined” system conditions and alert levels are too detailed and overly prescriptive. System operators need to spend time looking for the right color and level to communicate the prevailing system condition terminology to avoid violating the standard. This task, in and of itself, does not ensure nor improve reliability and does not lend itself to promptly and effectively deal with the emergency situation.
Agree
 
Disagree
3-part communication should be used for communicating a directive that must be complied with. The “must be complied with” is needed to distinguish between an “instruction type” of directive and a “need to perform type” of directive. We believe it is the latter that should require 3-part communication.
Disagree
While this requirement may represent a good utility practice or even a best practice, it is not so necessary to be enforceable through sanctionable requirements. Similar to R2, having to use the NATO phonetic alphabet is overly prescriptive and forces system operators to learn and remember “languages” in addition to the power system language. System operators should not be penalized for using some means other than the NATO phonetic alphabet to communicate equally effectively. We see no short coming in operations that would require these additional requirements and that the added complexity and additional training requirements may deteriorate reliability.
Disagree
This may represent a good utility practice but it is not necessary to be a requirement. The key is whether or not operation personnel understand one another. Similar comments as in Q4 and Q7 also apply here.
Agree
It is not clear what value is realized by declaring an alert status particularly with cyber and physical attacks. There does not appear to be any differing actions taken based on the alert status. Given that no differing actions are taken for cyber and physical attacks, it seems it would be more beneficial to use specific information such as the number of substations that have been physically or cyber attacked, etc. This is more meaningful than issuing a red alert that would only indicate more than one site has been attacked. Also, please see our comments under Q4.
Disagree
 
Disagree
 
Agree
We believe that the existing standard COM-002 can be simply modified to cover the 3-part communication requirement. This COM-003 standard actually causes more confusion and ambiguity, and creates unnecessary or overly cumbersome requirements that add little or no value to reliability. This standard is not needed.
Individual
Daryl Curtis
Oncor Electric Delivery
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Agree
 
Disagree
 
Disagree
 
Disagree
 
Disagree
 
Individual
Brady Baker
City Of Greenfield
 
 
Disagree
Listed as an LSE & DP, we are a small municipal utility that does not own nor operate any generation or transmission equipment. Therefore this standard is not applicable to our facility. Keep in mind, not all LSE's & DP's operate generation or transmission equipment.There are several small utilities that this standard would not be applicable to. LSE's & DP's should be put into class sizes depending on the size of the company or utility. Example: Class #1 LSE & DP : Companies that own & operate generation & transmission Class #2 LSE & DP : Companies that do not own or operate generation & transmission.(municipals,co-ops,etc)
 
 
 
 
 
 
 
 
 
Group
Southern Company Transmission
JT Wood
Disagree
Southern Company supports the SERC SOS comments. SERC SOS comments: We feel that the definition of Interoperability Communication is much too broad and is inconsistent with the effort to develop results-based standards. Adherence to such results-based standards would have a measurable and observable effect on the reliability of the bulk electric system. The definition of Interoperability Communication, as written, can include virtually any information exchange/instruction between entities, both routine and emergency. Such communication may or may not have a measurable and observable effect on bulk system reliability. The concern is that, since the broad term Interoperability Communication is used in every requirement in COM-003-1, entities will be required to use the English language, the central time zone, and 3-part communication in even the most routine exchanges of information. This could create a burden on operating personnel and a distraction from their reliability duties. This group does not feel the need for a definition of Interoperability Communication, since the term Reliability Directive has been defined in draft standard COM-002-3, which is currently posted for review. The Reliability Directive term is emergency-focused and consistent with the results-based standards process. In addition, the definition of Three-part Communication in this standard does not match the three-part communication requirements stated in COM-002-3. In COM-002-3, the requirements for three-part communication (state – repeat - acknowledge) apply to Reliability Directives, while in COM-003-1 the definition of Three-part Communication refers to “information” in general. If, as stated in the Disposition of Requirements, the revisions to COM-002-3 will be moved to COM-003-1, the definition of Three-part Communication in this draft standard should be consistent with the requirements of COM-002-3. Southern Company comments: Interoperability Communication — Communication between two or more entities to exchange reliability-related information regarding the Bulk Electric System. Why is a change in state or status required to make a communication between two entities an Interoperability Communication? What term should be used when a conference call is made to all of the RCs in an Interconnection to discuss low frequency?
Disagree
Southern Company supports SERC SOS comments. SERC SOS comments: Requirement R7, regarding the use of pre-determined line & equipment identifiers, applies to TSPs & LSEs. However, the other requirements of this standard do not seem to apply to these entities. For instance, most of the reliability-related alerts are communicated through the Reliability Coordinator Information System (RCIS). TSPs do not have access to this real-time communication tool, so the TSP should not be included in the applicability for the entire standard. Furthermore, Requirement R18 in TOP-002-2 mandated that neighboring Balancing Authorities use the uniform line identifiers. In COM-003-1, this requirement is lost, since Requirement R7 makes no mention of neighboring BAs. Southern Company comments: No proposed revision to remove R18 from TOP-002-2 has been provided in this SDT proposal. If this standard is adopted and TOP-002-2 is not revised at the same time the same requirement will be in two reliability standards.
Disagree
Southern Company supports the SERC SOS comments. SERC SOS comments: This group feels that there should not be a requirement in the standard to have a “procedure”. It is our understanding that, to be auditably compliant with a standard, the responsible entity must develop a procedure, train on that procedure, and be able to demonstrate compliance via documents, data, logs, records, etc. If Requirements R2 – R7 are included in this standard, the entity will need to develop a procedure to be compliant. Therefore, we feel that requirement R1 is redundant and should not be included. Southern company comments: The VSF for not having a written procedure is Severe. If an entity does not have a written procedure but complies with the other requirements in this standard has the reliability of the Bulk Electric System been affected? If the reliability of the Bulk Electric System is not affected by not having a written procedure why is this requirement in a Reliability Standard?
Disagree
Southern Company supports the SERC SOS comments. SERC SOS comments: The Alert Level Guides in Attachment 1 are not consistent with the proposed definitions of reliability-related communications. Both the Reliability Directive and Interoperability Communication, as currently defined, require some emergency action or change of equipment status. Yet the Alert Level Guides were intended for announcement, not actions. Requiring system operators to use the color-coded system condition terminology during communication adds a layer of responsibility that will distract from the operator’s real-time reliability-related tasks. We also do not feel that these Alert Level Guides apply to all the responsible entities identified under Applicability in the draft standard – for example, TSPs and LSEs are not included in the list of notifications. The requirement to use the central time zone for logging the time of an alert is problematic in that all communication tools, such as the RCIS, will need to be re-vamped. We question whether there will be a measurable reliability benefit by so doing. There is also some redundancy in the Alert Level Guides – for example, the CIP-001 standard requires notification of sabotage events – it should not be repeated in this standard.
Disagree
Southern Company supports the SERC SOS comments. SERC SOS comments: We feel that this requirement of a common time zone is overly prescriptive. The requirement should be that entities operating in different time zones agree on how to best eliminate any confusion regarding the time difference. Entities that routinely operate in different time zones already have an effective system for dealing with time differences. There seems to be no incentive to change a system that already works quite well, and the cost of updating computer systems could prove prohibitive. This group feels that mandating a common time zone across all of North America can only lead to confusion and increased reliability issues.
Disagree
Southern Company supports the SERC SOS comments. SERC SOS comments: As suggested in Question 1 above, the term Reliability Directive (as defined in COM-002-3) should be used in place of Interoperability Communication, since the directive is specific to emergency operations. The requirement should read: “Each responsible entity shall use Three-part Communication when issuing a Reliability Directive”. In addition, this requirement should apply only to BAs, TOPs & RCs. The other entities listed in the draft standard under Applicability do not issue Reliability Directives. Southern Company comments: conditional on if the definition of directive is not routine operational instruction.
Disagree
Southern Company supports the SERC SOS comments. SERC SOS comments: Use of the NATO phonetic alphabet should be considered a “best practice” and should not be included as a requirement in a reliability standard. One failure, such as saying “Baker” instead of “Bravo”, results in a severe violation without any impact on system reliability. This group is concerned that operating personnel will be focused on using the correct word rather than managing the power system. Southern Company comments: This requirement should be removed from the standard. Requirement 5 requires understanding by both parties during communication. Requirement 6 requires common identifiers which will enhance the chances of both parties understanding communications. Although using the phonetic alphabet may be necessary some times in order to gain understanding between two parties it should not be required. If both parties understand A as well as they do Alpha the reliability of the system has not been affected. No entity should be found in non-compliance of a Reliability Standard if reliability was not affected.
Disagree
Southern Company supports the SERC SOS comments. SERC SOS comments: Requirement R7 in draft COM-003-1 came from TOP-002-2, Requirement R18. The original requirement intended that neighboring Balancing Authorities use uniform line identifiers when communicating information about their tie lines. This requirement drops that clarification and introduces the additional requirement to use pre-determined “equipment” identifiers. Having to mutually agree in advance on identifiers for every switch & transformer is another example of a prescriptive requirement whose violation will not affect system reliability, yet will expose entities to large fines.
Agree
Southern Company supports the SERC SOS comments. SERC SOS comments: Our concern is that the Alert Level Guides of Attachment 1 were written for Reliability Coordinators, not the industry as a whole, and now they are being incorporated into an industry-wide standard. This attachment is very prescriptive as to how the notifications take place, such as through the RCIS. If the RCIS is not functioning and the hotline is used instead, is the entity vulnerable to a violation by virtue of the fact that these alert guides are included in the standard? We believe that the color-coded system condition terminology should be defined/required externally to the COM standards. The use of clear & consistent alert level terminology, while important, does not fit in well with the reliability-related communication standards, especially at these high violation severity levels. It is our suggestion that the Alert Level Guides be balloted separately, and include the Energy Emergency Alerts (EEA) as well. EEA requirements currently exist in NERC Standard EOP-002-2.1
Disagree
 
Agree
Southern Company supports the SERC SOS comments. SERC SOS comments: We do see a potential conflict with the Energy Policy Act 2005, which set the framework for the Electric Reliability Organization (ERO). The ERO’s mission is to oversee and protect the reliability of the Bulk Electric System. This standard seems to cross the line between reliability-related activities and other types of operating actions. The concern here is that system operators will focus on the letter of the standard rather than on good operating practice. The fear of a violation among operators may have a greater impact on reliability than the violation itself.
Agree
Southern Company supports SERC SOS comments. SERC SOS comments: This review group has identified several problems with this standard, as noted above. Other observations include: The effective dates in the draft standard and in the implementation plan do not seem to match. In the standard, the effective date mentions one calendar year following regulatory approval, while the implementation plan refers to the third calendar quarter after regulatory approval. Furthermore, we do not feel that any of the requirements in this standard warrant Violation Risk Factors or Violation Severity Levels in the high or severe category. In summary, this review group feels that COM-003-1 is not yet ready to be acted upon and may have been posted too soon. There does not seem to be sufficient coordination between the drafting teams of all the COM standards, or any attempt to integrate these standards. One example is the inconsistency between COM-003-1 and COM-002-3 regarding the meaning of three-part communication (mentioned in our response to Question 1 above). As noted above, we feel that many of the requirements prescribe specific “how to” methods for compliance rather than focusing on the “what” of the requirement. Overall, COM-003-1 is much too prescriptive to be tied to million dollar-level fines. Southern Company comments: There are possible inconsistencies with the references to the term “CIP Free Form” and a more generic term “Free Form” in the tables described in Attachment 1 – COM-003-1 – Operating State Alert Levels. Reference the fields where functional entities “outside” the Reliability Coordinator Area are identified for both the initial alert notification and the end of alert notification. For Physical Security, the field mentions only RC’s using the “CIP Free Form.” For Cyber Security, the field mentions RC’s and CIP Participants using the “CIP Free Form.” For Transmission Emergency Alerts, the field mentions only RC’s using the generic “Free Form.” Is there a distinction between the two forms? Is it consistent to reference CIP Participants only for Cyber Security alerts and not for Physical or Transmission? Although this standard is well intentioned it is not ready for presentation to the ballot body. When this standard is applicable is in question just by the way the Title and Purpose are written. The Purpose needs to make it absolutely clear to all parties, complying entities as well as compliance enforcement, when the standard is applicable. For example, the Purpose of the standard is subject to interpretation. Does this standard apply all of the time or just during Alerts and Emergencies? Or does the word especially mean that a non-compliance during an emergency is more severe? Is the phonetic alphabet required when an alert is declared or just after the alert is declared?
Group
PSEG Companies
Kenneth D. Brown
Disagree
The PSEG Companies agree with the concerns expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Disagree
The PSEG Companies agree with the concerns expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Disagree
The PSEG Companies agree with the concerns expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Disagree
The PSEG Companies agree with the concerns expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Disagree
The PSEG Companies agree with the concerns expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Disagree
The PSEG Companies agree with the concerns expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Disagree
The PSEG Companies agree with the concerns expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Disagree
The PSEG Companies agree with the concerns expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Agree
Yes. The PSEG Companies agree with the concerns and suggestions expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Disagree
No regional variances would be required to the best of PSEG's knowledge.
Agree
Yes. The PSEG Companies agree with the concerns expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Agree
Yes. The PSEG Companies agree with the concerns expressed in the comments filed by the PJM System Operations Subcommittee (SOS) Group.
Individual
James H. Sorrels, Jr.
American Electric Power
Disagree
Given that Three-part Communications is required when using a directive, a “directive” must be clearly defined. Without this determination, the definitions are incomplete. There are undefined conditions, such as conference calls with multiple parties. Does each participant repeat back in three-part? Also, the definitions do not address communication of directives that are made in a non-oral format. This is an important area to address in this standard. Lastly, please expand “entities” in the Interoperability Communication definition to be “NERC registered functional entities.” We are concerned that the definition is much too broad and may expand the scope of required communication beyond alerts and emergencies.
Disagree
Based on definitions provided in the functional model, the inclusion of the TSP and LSE in this standard is inappropriate. These entities manage the relationship with the end-use customer and are not responsible for the operation or maintenance of BES facilities.
Disagree
While having a procedure is important and the responsible entities should have a procedure to be compliant, there is not necessary to establish this requirement to have a procedure. We need to stay focused on what the purpose of the standard is to be and not dilute its effectiveness by focusing on documented procedures. Furthermore, if the extent of communication concerns warrants the extensive effort to establish pre-defined line and equipment identifiers, then this should be established in a uniform manner and not left to result in multitudes of approaches. There will likely need to be system modifications to address character limitations with respect to line and equipment identifiers.
Disagree
AEP suggests that RCIS be expanded to include the additional parties necessary to support Interoperability Communications. Without such an expansion, the communication requirements for the RC are burdensome and the effectiveness may be compromised by the volume of parties that will need to be included. Is it practical for RFC to communicate across some 60 parties or should this be limited to only those that need to know? Attachment 1 does not seem consistent with the stated purpose of this standard as Attachment seems to focus on defining the operating condition, not communication during alerts and emergencies. The SDT should consider if the scope of the standard is appropriate to resolve this discrepancy. To the extent that it gets mandated, Attachment 1 could be administered through the addition of “check boxes” on the expanded RCIS.
Disagree
AEP believes that the significant efforts and significant system changes necessary to support a common time zone does not provide a significant enough reliability benefit. In fact, the focus on a common time may divert attention away from more pressing operational reliability needs.
Disagree
Is a “directive” from the RC a “directive” all the way through the communication process, including down to the plant orders? Again, based on definitions provided in the functional model, the inclusion of the TSP and LSE in this standard is inappropriate. These entities manage the relationship with the end-use customer and are not responsible for the operation or maintenance of BES facilities. Consequently, when would such entities be responsible for issuing “directives?”
Disagree
AEP does not believe that this should be a requirement. It is understood that three-part communications represent best practices, but it is not necessary to mandate the NATO phonetic alphabet. We are not aware of an instance where the use of “Ed” rather than “Echo” has resulted in a reliability compliance breakdown.
Disagree
AEP does not believe it is appropriate for the standard to have been edited to remove the clarification that neighboring BAs use uniform line identifiers when communicating information about their lines and to add the addition requirement of using pre-determined “equipment” identifiers.
Agree
“Transmission Loading” should be replaced with “IROLs.” The attachment is very prescriptive as to the notifications are to take place, but not on conveyance of information to be communicated during alerts and emergencies. The attachment is not a good fit in this standard.
Disagree
 
Disagree
 
Agree
Unfortunately, the standard seems to be losing its value as the emphasis overly focusing on procedures while missing the intent. The SDT should reconsider the standard in the context of “what” rather than “how.” Lastly, we do not believe that this standard is ready to advance and needs significant re-working before the revised draft is posted. The SDT should attempt to better coordinate with the necessary other drafting teams as these standards are integrated.
Individual
Alice Murdock
Xcel Energy
Agree
 
Agree
 
Disagree
We agree with the structure of the standard, however we have issues with several of the CPOP elements being proposed. (See detail comments in following questions.)
Disagree
The use of Yellow, Orange and Red, as related to the various alert levels, may conflict with existing color requirements that entities already have in use. We recommend instead only refer to the PSEA, CEA and TEA levels. Additionally, it is unclear how R2 applies to anyone other than the RC. Attachment 1 seems to only apply to the RC. If this is correct, then why would the other entities listed in R2 have to incorporate that terminology into their CPOP? If this is not correct, please clarify the requirement so that the other entities can clearly understand what is expected.
Disagree
Do not agree with the requirement to use CST. By requiring the use of CST it may actually introduce an element of error for those who do not routinely operate in that time zone and must make mental corrections for the time zone they are in. Additionally, some agreements already exist that stipulate what time zone is to be used.
Disagree
The way the standard is written, the term "directive" is still open to interpretation and could be inconsistently applied. The term "directive" should be defined.
Disagree
Use of the NATO phonetic alphabet should be a best practice not a reliability requirement. We are not convinced that there is any threat to reliability if someone were to use a different phonetic than what is indicated. Additionally, we do not feel that it is necessary to use the phonetic alphabet unless there is an indication that the initial communication has been misunderstood. If the drafting team feels this requirement should remain in the standard, we feel it should be modified to address: 1) there should be an exception for approved acronyms, such as NERC, FERC, etc., 2) it should only be required upon repeat-back, when the first communication was misunderstood, and 3) any phonetic alphabet should be acceptable for use, such as military or police, not just NATO's.
Disagree
We feel this requirement needs clarification, particularly regarding how granular an entity would have to go into the various pieces of equipment/lines. We would also recommend that R7 be modified to not require mutual agreement. We feel the owner (or majority owner) of the line or equipment should be the one setting the identifiers. For example, R7 could instead read like this: “Owner-determined line and equipment identifiers shall be used for all verbal and written Interoperability Communications.”
Agree
Please see our response to question 4.
Disagree
 
Disagree
 
Agree
1) Recommend removal of the references to measures in the data retention section of the standard. It is only necessary to refer to the requirements, which is already included. 2) The data retention section should also be modified to refer generically to evidence, instead of "dated operator logs… and voice recordings or transcripts of voice recordings…". This is because the measures specifically allow for other types of evidence, as stated: "Evidence of use may include but is not limited to voice recordings, transcripts, operating logs, or on site observations."
Individual
Laura Zotter
ERCOT ISO
Disagree
The purpose of the standard is for timely communication of reliability-related information “especially during alerts and emergencies”. The definition and use of Interoperability Communication in this standard expands the intended scope of the standard beyond alerts and emergencies. Guidance should be provided for verbal communications with respect to hot-line calls (one party to many) and how three-part communication should be handled. This definition assumes a one on one communication.
Agree
 
Disagree
This approach of an administrative type requirement is in conflict with the NERC BOT approval of pursuing the development of standards to support reliability performance and eliminate administrative requirements. It is not necessary to have a separate CPOP document to insure operating personnel communicate effectively.
 
Disagree
This is an administrative task and prescribes how something should be done. Written Interoperability Communications are typically done through automated systems, in which time zone conversion should not be an issue. Verbal communication should be thorough enough to confirm the conversion. If the industry is in favor of this requirement, then perhaps consideration should be to use Central Prevailing Time to alleviate potential confusion with changes with Daylight Savings Time.
Disagree
The requirement, based on the definitions of the terms, introduces ambiguity or even conflict. Three part communication should be required for emergency situations and with the issuance of Reliability Directives (term not yet formally defined – in the works by the Reliability Coordination SDT). Interoperability communications refer to any communications in which a status of a facility or element is to be changed, which means not specifically related to emergencies.
Disagree
ERCOT ISO does not agree with this approach, which seems to be overly prescriptive (“directives, notifications, directions, instructions, orders, or other reliability related information”), which goes beyond the purpose of “during alerts and emergencies”. This is an administrative requirement that would increase communication timing and possibly negatively affect reliability. If using a common language and three part communication for directives is effective this is not required.
Disagree
Does the phrase ‘mutually agreed upon line and equipment identifiers’ mean that identifiers do not have to be identical, but that all parties understand the equipment discussed? If this is the general understanding, then no further comment, otherwise, please clarify. Although the related bullet item in the Background Information section describes that they do not have to be identical, many auditors many only look at the requirement language.
Agree
The intent is for a simple way to look and know the high-level status of an area. This goes way too far into HOW to do it instead of stating what must be done.
Disagree
 
Disagree
 
Agree
 
Individual
Leland McMillan
NorthWestern Energy
Agree
 
 
Disagree
COM-001 and COM-002 standards, along with Operator Training, adequately address this issue. Therefore there is no need for this additional requirement.
Disagree
Attachment 1 seems too overly complicated for emergency Operating circumstances and provides an additional burden for Real Time personnel who are stressed with difficult decisions already.
Disagree
NorthWestern appreciates the opportunity to comment. We believe the requirement to use Central Standard Time will cause unnecessary confusion (translating to a different time zone and possibly to a different time reckoning – standard or daylight) at a time when the need for clarity is critical. NorthWestern suggests that each entity use their local time zone when issuing switching orders. Each entity should state the time zone they are using when giving any time reference (e.g., 15:20 Mountain Daylight Time) if necessary.
Agree
 
Disagree
NorthWestern appreciates the opportunity to comment. The requirement, as drafted, appears to open the possibility of sanctions for incorrect use of the NATO phonetic alphabet during any verbal communication between entities. The use of the NATO phonetic alphabet would be difficult when performing local switching orders to field personnel. NorthWestern suggests that the requirement be reworded to state that entities “shall use a phonetic code (e.g., the NATO phonetic alphabet) when necessary, to verify accurate reception of alpha-numeric information.”
 
 
Disagree
 
 
Agree
NorthWestern feels that the current communication standards are sufficient for reliable BES Operations.
Individual
Saurabh Saksena
National Grid
Disagree
Interoperability Communication: Virtually all communications in a control room environment deal with changing the state or status of an element of facility, as such there is not a need to define this communication protocol. However, addition of “real time communication” in the definition will to an extent address the issue. The definition should be revised as follows: Real Time Communication between two or more entities to exchange reliability-related information to be used by the entities to change the state or status of an element or facility of the Bulk Electric System. Three-part Communication: The way the definition of Three-part Communication is worded applies only when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should rather reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: A Real-Time Operating Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it.
National Grid has no specific stand either ways. However, please refer to response to Question 8 for issues pertaining to the language of the requirement.
Disagree
It is not clear what the purpose of this communication protocol is or what should even be included in the protocol. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions.
Disagree
Defining specific wording per Attachment 1 is overly prescriptive. The requirements should focus on what is required not how. The RC and incompassing entities should be required to define terms that will be used in communications. This would allow for the use of terms that are well understood in an area rather than adding new terms. Also, System operators need to spend time looking for the right color and level to communicate the prevailing system condition terminology to avoid violating the standard. This task does not lend itself to promptly and effectively deal with the emergency situation. There is still plenty of grey area in Attachment 1 and there does not appear to be any differentiation in actions taken based on the alert levels. Finally, the section Background Information in the Comments form mentions “The SDT proposes four system condition alerts instead of initial three in the RCWG version.” However, Attachment 1 only mentions 3 alerts – Physical Security, Cyber Security, and Transmission Emergency Alerts leading to confusion.
Disagree
The use of central time is unnecessary and may cause more confusion when converting times. The requirement should be that those entities which need to communicate and are in different time zones, define which time they will use for communications.
Disagree
Based on the definition of Interoperability Communications, this would require 3- part communication to be used during virtually all control room communications. The definition of Interoperability Communications should be revised as proposed in response to Question 1.
Disagree
Using the NATO phonetic alphabet is useful, but to what extent? Does it apply to facility identifications, key words, or every letter of every word? Is it upto the judgment of the operators? If so how will compliance be monitored? If during a communication, personnel used a term different than that in the NATO alphabet i.e. D as in Dog rather than Delta however, the listener understood the message and the correct action was taken would there still be the possibility of a compliance violation?
Disagree
The way this and TOP-002 R18 requirements are written they could be interpreted to mean that the line identifiers have to be unique. The requirement should be written similar to the bullet on page 7 of the comment form also listed below. “TOP-002 R18. Neighboring Balancing Authorities, Transmission Operators, Generator Operators, Transmission Service Providers and Load Serving Entities shall use uniform line identifiers when referring to transmission facilities of an interconnected network.” “Pre-determined Line and Equipment Identifiers: COM-003-1 requires the use of predetermined line and equipment identifiers in Requirement R7 however the Requirement does not stipulate a single/unique identifier as long as all parties mutually agree on the identifier for the line or equipment. The mutual agreement shall be reached in advance of the use of the identifiers as described in the functional entity’s CPOP”
Disagree
Please see response to Question 4.
Disagree
None
Disagree
None
Agree
We believe that the existing standard COM-002 is actually better than this standard. This standard actually causes more confusion and ambiguity and creates unnecessary or overly cumbersome requirements that add little or no value to reliability. Additionally, we cannot understand how all requirements but R1 have been determined to have a HIGH VRF when, many of them are dictating HOW communications should take place and not when and why or what. COM-002 retirement does not appear to be consistent with the direction of the RC SDT. The RC SDT appears to be adding requirements. More coordination is required between these two teams.
Group
NERC Staff
Howard Gugel
Disagree
NERC staff recommends that the term “Communications Protocol” be removed from the definition section because the term is only used in the title and in another definition. In addition, the definition adds no additional clarity than can be provided by a commonly used definition of the terms. Similarly, the term “Three-part Communication” can be removed since it is used in only one requirement, and the definition can be incorporated in the requirement. Furthermore, Three-part Communication refers to a process or procedure, not a term. NERC staff recommends that the term “Interoperability Communication” be modified to “Operating Communication” with the definition of “communication with the intent to change or maintain the state, status, output, or input of an Element or Facility of the Bulk Electric System.” This captures all communication that affects BES reliability, not just communication between function entities.
Disagree
NERC staff agrees with the proposal, but would offer the following modification in order to add clarity. We recommend that the phrase “when issuing directives, notifications, directions, instructions, orders or other reliability related operating information that involves alpha-numeric information during verbal Interoperability Communications” be replaced with “when verbal Operating Communications with alpha-numeric information is involved.” This would utilize the definition of Operating Communications offered in the response to Question 1. This will hopefully eliminate the need to further define what communication is or is not included in the phrase “directives, notifications, directions, instructions, orders or other reliability related operating information.”
Disagree
NERC staff recommends that Requirement R1 be deleted because it is strictly an administrative requirement that is not necessary. It is not results-based, and is redundant given the imbedded reference to Requirements R2 to R7. If an entity can demonstrate compliance with the other requirements, Requirement R1 performs no additional reliability enhancement. A Requirement should state a performance outcome or a risk to be mitigated. If there is a need to document something, the appropriate location for that is in the Measures section of the standard. A distinction should be made here that producing a document containing specific content necessary for reliability, such as a system restoration procedure, can be an effective requirement used to minimize risk. However, documentation that does not stand on its own as a result necessary for reliability should not be made into a requirement. Such documentation requirements should either be eliminated or moved to an administrative, informational section of the standards. An example of a weak requirement is “the Responsible Entity shall document the implementation of security patches”. The requirement that directly contributes to a risk reduction outcome is to implement applicable cyber security patches. Documentation of the implementation is simply a vehicle for demonstrating compliance. The NERC staff does not find that the CPOP satisfies the criterion of reducing risk.
Disagree
NERC staff agrees with the principle behind Requirement R2. However, it appears that two separate communication actions are being performed, the action to notify the Reliability Coordinator, and the action by the Reliability Coordinator to communicate the alert level to affected functional entities. Therefore, we recommend that that Requirement R2 be split into two requirements and offer the following wording: A Balancing Authority, Transmission Owner, Transmission Operator, Generator Operator, Transmission Service Provider, Load Serving Entity and Distribution Provider shall notify its Reliability Coordinator when it becomes aware that there is a situation involving the facilities under its control that meets the criteria for an alert, as specified in Attachment 1 – Operating State Alert Levels, to keep the Reliability Coordinator informed on the initial and subsequent status of the situation. When a Reliability Coordinator is notified (or becomes aware) that there is a situation within its Reliability Coordinator Area that meets conditions specified in Attachment 1 – Operating State Alert Levels, the Reliability Coordinator shall use the phraseology when making the notifications specified in Attachment 1 to keep others informed on the initial and subsequent status of the situation. The NERC staff recommends that the SDT review the content of the Attachment for consistency, clarity and omissions (such as found in the table on page 14 of the draft – the cell, “Notify the following entities:” is blank).
Disagree
In the “Background Information” section of this Comment Form, you state, “The SDT believes that Interoperability Communications would be enhanced with the use of a common time zone. Central Standard Time was chosen as it is already in use for NERC Time Error Corrections. The Blackout Report cited the need to tighten communication protocols and the SAR includes consideration of a common time zone to minimize mis-matched time signature issues between control systems especially during an emergency.” NERC staff would like to see more detailed justification on how reliability would be enhanced with this requirement. This appears to solve issues for communications between time zones, but may add additional confusion for all additional communications that exist within a common time zone.
Disagree
NERC staff agrees with the principle behind Requirement R5. We recommended in Question 1 that the term “Three-part Communication” be removed since it is only used in this requirement. We feel that this requirement should be split into two requirements so that the sender and receiver each have responsibility in the communication. Therefore, we offer the following as suggested replacement language for Requirement R5: Each Reliability Coordinator, Balancing Authority, Transmission Owner, Transmission Operator, Generator Operator, Transmission Service Provider, Load Serving Entity and Distribution Provider that receives a verbal Operating Communication shall repeat the communication to the initiator. Each Reliability Coordinator, Balancing Authority, Transmission Owner, Transmission Operator, Generator Operator, Transmission Service Provider, Load Serving Entity and Distribution Provider that initiates a verbal Operating Communication shall ensure that the receiving party has repeated the communication, and shall verbally confirm the communication to be correct or reinitiate the communication.
Disagree
As stated in response to Question 2, NERC staff agrees with the proposal, but would offer the following modification in order to add clarity. We recommend that the phrase “when issuing directives, notifications, directions, instructions, orders or other reliability related operating information that involves alpha-numeric information during verbal Interoperability Communications” be replaced with “when verbal Operating Communications with alpha-numeric information is involved.” This would require using the definition of Operating Communications offered in the response to Question 1. This will hopefully eliminate the need to further define what communication is or is not included in the phrase “directives, notifications, directions, instructions, orders or other reliability related operating information.”
Disagree
NERC staff is unaware of any instance where not having a mutually agreed upon nomenclature has led to an adverse reliability event. Rather than requiring a national database for all line and equipment identifiers, it appears that restricting the list to jointly-owned facilities and tie-line would accomplish the team’s goal. We recommend that the phrase “Interoperability Communications” be replaced with “Operating Communications involving jointly-owned Facilities and tie lines.”
Agree
NERC staff recommends that a line be added to each table that provides the expectation for entities communicating events to the Reliability Coordinator. Using the existing tables, all expectations and requirements rest solely on the Reliability Coordinator. We also recommend eliminating the color designations of yellow, orange, red and the Alerts be changed to Level One, Two and Three for consistency. The use of colors does not appear to add anything to the clarity or effectiveness in conveying the content of an Alert and may be inconsistent with the Department of Homeland Security’s threat level system. Additionally, the team should update Attachment 1 to include the criteria and notifications for Energy Emergency Alerts.
Agree
Although no questions were asked about Requirement R3, NERC staff is aware that some areas in North America require a language other than English for official communication. In addition, it may be hard to define what “internal communications” are. NERC staff recommends that the phrase “Interoperability Communications. Responsible Entities may use an alternate language for internal communications” be replaced with “Operating Communications between functional entities, unless prohibited by law.” In addition, regions that exist solely in one time zone may ask for a variance from the requirement to use CST for communication.
Agree
Although no questions were asked about Requirement R3, NERC staff is aware that some areas in North America require a language other than English for official communication. In addition, it may be hard to define what “internal communications” are. NERC staff recommends that the phrase “Interoperability Communications. Responsible Entities may use an alternate language for internal communications” be replaced with “Operating Communications between functional entities, unless prohibited by law.”
Agree
NERC staff questions whether this standard applies to the Transmission Service Provider and the Transmission Owner. It is unclear from the functional model where they would be involved in real-time operations communications. It is also unclear why the Violation Risk Factor for every requirement is High, and the Violation Severity Level for all but the first requirement is Severe. This automatically elevates any violation of any of these requirements to the highest penalty level that is imposed. The NERC staff recommends that the SDT review the latest guidelines for assignment of VSLs and consider alternatives that could expand/gradate the VSLs to account for varying severity of non-compliances.
Individual
Roger Champagne
Hydro-Québec TransÉnergie
Disagree
The way the definition of “Three-part Communication” is worded applies only when the communication is understood by the listener the first time. The RC SDT requirement which includes “and shall acknowledge the response as correct or repeat the original statement to resolve any misunderstandings” is more complete. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. A suggested revision to the definition: A Real-Time Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back to the party that initiated the communication by the second party that received the communication, and the information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it. These principles are included in Requirements R2 and R3 in the recently issued draft Standard COM-002-3 in Project 2006-06. An alternative suggestion to the definition of Three-part Communication: A Real-Time Operating Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the information is verbally confirmed to be correct by the party who initiated the communication. In the definition of Communications Protocol, the term “Interoperability Communication” creates confusion within the industry, and contradicts the work by RTO and RC SDT in Project 2006-06 that limits the requirement to use three-part communications when issuing Reliability Directives (defined in Project 2006-06) that address anticipated and actual emergency conditions, and do not agree with its definition. What also must be considered is that the RC SDT has stated that when someone “says”, it is a directive--operating conditions are not distinguished. This definition unnecessarily and counterproductively encompasses all verbal communications and, as such, is not needed. It is not so critical to reliability that it should become an enforceable requirement for routine operating instructions. The enforceable requirement should be limited to require three-part communications, and be left to the entity that needs the action to be taken to establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger, and be auditable and measurable. Virtually all communications in a control room environment deal with changing the state or status of an element of facility, as such there is not a need to define this communication protocol. Both element and facility are used in the Interoperability Communication definition and are NERC defined terms. Did the drafting team intend that the NERC definitions should apply? If so, the terms need to be capitalized. The term “entities” is confusing and needs to be defined.
Disagree
The SDT expanded Requirement R18 of TOP-002-2 by adding the term “equipment”. This Requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how. The only real need for a requirement is to establish that each entity issuing a directive shall use three-part communications and the recipient of a directive shall also properly participate in the of use three-part communication protocol until the message has been correctly spoken and understood. LSEs and TSPs do not own or operate equipment, and as such should not fall under the mandates of this requirement. Neither the TSP nor the LSE provide or receive information about specific lines or equipment in real-time. Therefore, requirement R7 should not apply to them absent clear evidence that a realistic (not hypothetical) threat to reliability would exist if they are omitted. We do not think that such a threat would exist.
Disagree
This proposed communication protocol is redundant to Requirements R2-R7, and should not be included in this Standard. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions for all entities involved in real time operations. The NERC BOT has approved pursuing the Results-based Reliability Standard Task Force’s recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to eliminate administrative requirements. This proposal takes the opposite approach and incorporates a new administrative requirement. The industry as a whole, based on the response to the Task Force, does not support such an approach. This Requirement should be deleted from the Standard. There is no need to create a CPOP that includes requirements R2 through R7 given that each requirement spells out how and what is to be communicated. A CPOP may be needed for Interoperability Communications that are not addressed in R2-7.
Disagree
It is not clear what value there is in identifying these alert levels. There does not appear to be any differentiation in actions taken based on the alert levels. Just stating the severity and details of the incident should suffice. Further, the “pre-defined” system conditions and alert levels are too detailed and overly prescriptive. System operators will need to spend time looking for the right color and level to communicate the prevailing system condition terminology to avoid violating the standard. This task does not lend itself to promptly and effectively deal with the emergency situation. The level(s) identified in the notification text are at odds with the condition (color versus numerical). Suggest that the standard either use Condition (color) or the level (numerical). Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the listed entities such as Distribution Provider and Generator Operator cannot have access to these systems due FERC standards of conduct requirements. Attachment 1 and R2 are not consistent with the definition of Interoperability Communications. By definition, Interoperability Communication pertains to all communications about how entities change the state of the BES (not just physical or cyber attacks). Attachment 1 is about notifying of what physical and cyber attacks have already happened to the BES. It is not clear in the context of Interoperability Communications what the recipient of a specific notification is expected to do when there is a change of state or status of an element or facility of the Bulk Electric System. Attachment 1 pertains specifically to Operating State Alert Levels and says nothing about the communication of information to be used to change the state or status of a BES element or facility (which is the SDT’s proposed definition of Interoperability Communications). Therefore, it is not appropriate to require that all verbal and written Interoperability Communications use the pre-defined terminology in Attachment 1. Only those communications concerning Operating State Alert Levels should be required to use that terminology. By the proposed definition, such communications are not Interoperability Communications since the information is not used to change the state or status of a BES element or facility. The SDT needs to revise this requirement to clarify that it pertains only to communicating the Operating State Alert Levels and nothing more. None of the examples in either of the attachments appear to address EEAs (EEA is mentioned in the top paragraph of page 9 that is included in EOP-002-2.1) or SOLs. This limits the use of Interoperability Communications to only events where there exists either a physical or cyber threat, or where an IROL can’t be mitigated. The requirements should focus on what is required, not how. The RC and encompassed entities should be required to define terms that will be used in communications. This would allow for the use of terms that are well understood in an area, rather than having to add new terms. The Background Information in this Comment Form introductory section mentions “The SDT proposes four system condition alerts instead of initial three in the RCWG version.” However, Attachment 1 only mentions 3 alerts – Physical Security, Cyber Security, and Transmission Emergency Alerts leading to confusion. Finally, Attachment should only be used as a guide.
Disagree
HQT agrees with using 24 hour format. However, there is no reliability need to use a common time zone for communications. There is already a requirement to use hour ending for scheduling purposes, inadvertent accounting, CPS and other standards where needed. There is no additional reliability need to use a common time zone. The time zone should be identified in the communication. Not only does this requirement attempt to determine HOW entities operate within their various footprints, it would significantly change the way many markets are structured. To implement this into existing Markets would cost significant time, money and resources while not enhancing reliability in these areas. When operating across time-zones, simply referencing “Central Standard Time” or “Eastern Standard Time” is sufficient for operating entities to reliably operate. The time zone adopted by the respective Reliability Coordinator (RC) and their area control center, e.g., NYISO Eastern Standard Time (EST), should be used. If each entity in the area and the RC are all using EST (or daylight savings), then why would a time zone be used that is foreign to all parties in the area? This can lead to considerable confusion. What cannot be ignored is how many entities would have to modify their existing practices, hardware, software, Control System, billing systems, bidding systems, etc. We are strongly opposed to this requirement. The requirement should be that those entities which need to communicate and are in different time zones define which time they will use for communications. Any confusion about what time is being verbally communicated should be cleared up through three-part communications. There should be no confusion about what time is being communicated as long as the time zone (where applicable), and the 24 hour format designations are included. Besides, many entities exchange written information via web-enabled applications that allow the users to configure their interface to show time in whatever format and time zone they prefer. This eliminates confusion.
Disagree
Based on the definition of Interoperability Communications, R5 implies that three-part communications is required to communicate routine operating instructions, or during operational strategic discussions as well as other “non-action” oriented communications. This Requirement contradicts the work that has been done and substantially progressed through two other SDTs and creates confusion within the industry. This Requirement would, in fact, be adverse to reliability instead of enhancing reliability by reducing the amount of pre-action communications that may occur prior to taking action because operators may be more concerned with not repeating back during such pre-action, strategic calls and/or discussion. The work being done by the RC SDT and RTO SDT in Project 2006-06 defines a Reliability Directive based on the determination of the person giving such an order. The entity that needs the action to be taken should establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger, auditable, and measureable. R5 is not consistent with the Functional Model. Only the RC, BA, and TOP can issue directives. Outside of allowing the individual who NEEDS the action to be taken, this is an auditable or measureable requirement whether it be for 3-part communications or for the receiving entity to actually take said action. By definition, Three-part Communications presumes the second party will repeat the information back “correctly.” Failure to do so is assigned a High VRF and a Severe VSL. The practical application of Three-part Communication involves a sender communicating information, a receiver repeating back the information, and the sender verifying the repeat back is either correct or incorrect. If the repeat back is incorrect, the process repeats until both parties have the same understanding of what is being communicated.
Disagree
While this Requirement may represent a good utility practice in certain situations, it is not necessary to be used in all verbal Interoperability Communications, and is certainly not necessary to be included as an enforceable Requirement. For example, a situation in which an operator says “A as in apple” instead of using the NATO Alpha. Even though the listener should clearly be able to discern the correct meaning, the speaker’s company could be sanctioned even if the correct actions were taken as a result of the clear communication. The objective of good communications is to assure that the parties understand each other. The statement “… shall use the NATO phonetic alphabet” doesn’t make sense for North America. If the Real-Time Operator states “breaker 6-North,” under the NATO phonetic alphabet that would be unacceptable, because the operator did not use the appropriate NATO term “breaker 6-November,” even thought the “N” on the one line diagram refers to the “North” breaker and not the “South” breaker. Many organizations may have established communications protocols which are working well. Making a change may actually hinder reliable operations by introducing unnecessary confusion and questioning. Not only does this requirement attempt to determine HOW entities operate with their various footprints, it may change the way many Markets are structured. What is the difference between using the word “Zebra” instead of “Zulu” to signify the letter “Z”? And, why would this be enforceable. Perhaps this should be a guideline document rather than an enforceable Requirement. There is no reliability need for this Requirement. Furthermore, the use of three part communication eliminate the need for a mandatory use of NATO phonetic alphabet.
Agree
 
Agree
It is not clear what value is realized by declaring an alert status particularly with regard to cyber and physical attacks. There do not appear to be any differing actions taken based on the alert status. Given that no differing actions are taken for cyber and physical attacks, it seems it would be more beneficial to use specific information, for example 12 substations have been physically or cyber attacked. This is more meaningful than issuing a red alert that would only indicate more than one site has been attacked. Furthermore, we question the value of communicating the physical and cyber alerts. How does this notification help the BES reliability? Consider the following example. One BA in Oklahoma is 34,323 sq miles. Communicating that an attack occurred in the BA and RC tells other operators that somewhere in Oklahoma an attack occurred. This notification does not present any information that could require actions on the operators’ parts, and will only generate phone calls for more information. Furthermore, PSE and CSE is a type of sabotage already reported in CIP-001 R2. TEA Alerts are already covered in IRO-006-East-1, IRO-009, IRO-010, IRO-014.01 R2. Also it has been the experience of several entities during the field test of these Alert Levels that there are inconsistencies as to when to implement various stages of Alerts, and this introduces more confusion than exists today. Reliability has not been enhanced. Attachment 1 contains a conflict. The last sentence of the opening paragraph of Attachment 1 reads, “The time frame for declaration of these Alert states shall be consistent with the approach used to declare EEAs and would normally apply to Real Time declarations and not forecast conditions.” In Transmission Emergency Alerts Condition Yellow, Orange and RED: The Reliability Coordinator or Transmission Operator foresees or is experiencing conditions where all available generation resources are committed to respect the IROL and/or is concerned about its ability to respect the IROL. Foresees is a forecast condition. There is an inconsistency between the inclusion of Attachment 1 and what is stated in the document posted with the standard entitled Disposition of Requirements Identified in the SAR for Operations Communications Protocols as Possibly Needing either Modification or Movement. The document states that the standard focuses on “how to” communicate rather than on specified scenarios of “to whom” or “when to” communicate; however, Attachment 1 does just the opposite. In condition Orange and Red for TEA Level Two/Three, the initial notification requirements are redundant with IRO-006-East-1 R3.2. Under the Make Final Notifications, is curtailed intended to mean canceled or terminated? The term Curtailed in operations generally means cuts for schedules/tags. EEA’s use terminated. Terminated is the preferred term. Distribution Service Providers should be Distribution Provider to be consistent with the Functional Model. Refer to the response to Question #4.
Agree
In the Province of Québec, the use of French is mandatory, according to law, for communication within the Province. R3 should include: Within the Québec Interconnection, the French language shall be used for verbal and written interoperability communication between entities (RC, BA, TO, TOP, GOP, TSP, LSE and DP). For their interoperability communication with entities outside of the Québec Interconnection, they shall use the English language.
Agree
In some market structures, TSPs and LSE do not own or operate equipment. Thus, including them in the requirements is an unnecessary burden for these areas. The requirement to use CST attempts to determine HOW entities operate within their various footprints and it would significantly change the way many Markets are structured. To implement this into existing Markets would cost significant time, and resources while not enhancing reliability in these areas. When operating across time-zones, simply referencing “Central Standard Time” or “Eastern Standard Time” is sufficient for other operating entities to reliably operate. Many entities would have to modify their existing practices, hardware, software, Control System, billing systems, bidding systems, etc. We are strongly opposed to this requirement.
Agree
The existing standard COM-002 is better than this proposed Standard. This Standard actually causes more confusion and ambiguity, and creates unnecessary or overly cumbersome requirements that add little or no value to reliability. All requirements with the exception of R1 have been determined to have a HIGH VRF, when many of them are dictating HOW communications should take place and not when, why, or what. COM-002 retirement does not appear to be consistent with the direction of the RC SDT in Project 2006-06. The RC SDT is adding requirements. More coordination is required between the Standard Drafting Teams. Again, we support the work being done by the RC SDT and RTO SDT and do not believe this adds more necessary requirements. Many of the requirement proposed in this posting either reiterate the drafts as posted (i.e. English language) or introduce confusion when compared to the drafts as posted. The SDTs should limit their scope to R2 and R7, so as not to duplicate or contradict the on-going work of other SDTs. The SDT appears to have adopted severe violations for every infraction. There should be some gradations, using increasing severity based on the number of or severity of any infractions. Definitions: The standard should define other terms, as well, including the following: • reliability-related information, • “… state or status of an element or facility of the BES …” The standard should also have provision to include the boundaries (components) of an “element,” and the meaning of the terms “state or status” in the written communication protocol. For example, is the gas compressor of a 345kV breaker considered part of this element, and so would a change in its “state or status” be covered? The VRFs for R2-R7 are all “High”, and the VSLs are all “Severe” are too harsh. Failing to comply with one of the requirements does not automatically mean that a miscommunication occurred that caused a reliability problem. There should be a “Moderate” VSL for failure to comply with a requirement, but no miscommunication occurred. There should be a “High” VSL for failure to comply with a requirement that caused a miscommunication but resulted in no violation of another reliability standard. The “Severe” VSL should only apply to failures to comply with a requirement that caused a miscommunication that lead to a violation of another reliability standard, or caused a reliability problem. In addition, as stated earlier, this Standard focuses on “how” certain tasks should be performed and conflicts with NERC’s position of pursuing performance based and results based Standards. Based on these considerations, work on this Standard should be stopped until work on Project 2006-06 has been completed and approved. This approach is consistent with the August 2003 Blackout Recommendation #26 “failure to identify emergency conditions and communicate that status to neighboring systems, and upgrade communication system hardware where appropriate” which actually focused on communications during emergencies, which is the scope of Project 2006-06. After Project 2006-06 is completed, a determination can be made on the disposition of this Standard. This Standard should be effective uniformly continent-wide.
Group
Santee Cooper
Terry L. Blackwell
Disagree
The definition of Interoperability Communication needs to be clarified. What is the intent of the word “entities” in this definition? This definition may no longer be needed with the recent definition of a Reliability Directive. Three-part Communication should be required when issuing and receiving a Reliability Directive. This term has recently been defined by a SDT.
Disagree
A TSP and LSE should not be subjected to other requirements within the COM003 Standard such as Three-part Communications. In addition, R18 of TOP002-2 required the use of uniform line identifiers among neighboring BAs. As this requirement (R7) is now written in COM003 it is not clear that this is when the use of uniform line identifiers is required. As currently written, it could be interpreted that the use of uniform line identifiers is required for all communication which is more restricting.
Disagree
We believe that a company’s documentation demonstrating compliance for R2 through R7 would eliminate the need for a CPOP document.
Disagree
Utilization of a color-coded system for all verbal and written Interoperability Communications adds a layer of complexity to the System Operator that is not necessary.
Disagree
A common time zone is not necessary and is overly prescriptive. Companies should not have to worry about self-reporting or receiving a compliance violation if someone states the wrong time during a conversation.
Disagree
The SDT should consider using the now defined term Reliability Directive in place of Interoperability Communications. Typically, only BAs, TOPs, or RCs issue Reliability Directives so this requirement should only be applicable to those entities.
Disagree
Use of the NATO phonetic alphabet should not be a requirement of this standard. This also adds a layer of complexity to the system operator position that is not necessary.
Disagree
See previous comment on Question 2. In addition the use of the words “equipment identifiers” could be interpreted to include all pieces of equipment within a line.
Disagree
 
Disagree
 
Agree
A lot of the requirements in this standard could be considered a “best practice” for the industry rather than reliability related.
Agree
The SDT has put a lot of work into this standard and we appreciate their effort. The SDT of COM-002 and COM-003 may need to integrate the reliability related requirements of these two standards into one standard that the industry can approve. This standard as written could lead to some extremely high dollar fines when in reality the reliability of the bulk electric system has not been affected at all.
Group
Bonneville Power Administration
Denise Koehn
Disagree
BPA does not agree with the aspects of Interoperability Communications. We do not need a common time standard. Why use the NATO Standard. This could add a lot of time to a directive that needs to be given immediately. The 3 part communication is already used by BPA.
Disagree
BPA Would like further clarification about what is meant by “pre-determined, mutually agreed upon line and equipment identifiers”. Is it a specified format no matter which part of the system is being used, or is it only for 115 kV and above as it apllies to LSE’s and TSP’s. If it only refers to Transmission equipment above 115 kV, then BPA would likely agree.
Disagree
BPA does not agree with the one time zone or the NATO Standard. We believe the protocols are unnecessary and in fact will add more confusion to the process. We also do not agree, if this requires creating a brand new documented procedure just to address this standard, when elements are already covered in a different standard (common language in TOP).
Agree
In Attachment #1 - Operating State Alert Levels, for the Transmission Emergency Alert (TEA) Level 2 definition, a “why” needs to be incorporated into the definition. It appears that the reason we're going to TEA 2 is to avoid violation of an SOL but it needs to be called out.
Disagree
This creates a communication barrier between the utility and it's customers and the local population. Do not go ahead with this provision. The very last thing that we want to do is to create confusion and this approach, given that the country itself is using different time zones, will do just that. With 3-part communications with specified time zones in Interoperability Communications as required and a common English language, the matter is covered.
Agree
Suggest that each entity is also required to use the full station name in verbal communications.
Disagree
 
Disagree
BPA Would like further clarification about what is meant by “pre-determined, mutually agreed upon line and equipment identifiers”. Is it a specified format no matter which part of the system is being used, or is it only for 115 kV and above as it apllies to LSE’s and TSP’s. If it only refers to Transmission equipment above 115 kV, then BPA would likely agree.
Agree
In Attachment #1 - Operating State Alert Levels, for the Transmission Emergency Alert (TEA) Level 2 definition, a “why” needs to be incorporated into the definition. It appears that the reason we're going to TEA 2 is to avoid violation of an SOL but it needs to be called out. The color scheme may be confusing with (DHS) Homeland Security's terrorist alert levels. (The RC makes the notifications to all based upon the Operator’s reported conditions per the scheme.). Suggest only using the Emergency Energy Alert numerical levels versus the color scheme, to avoid confusion with Homeland Security alerts. An example: A red alert is a breakup like 2003 and 1996, not shedding of load to prevent it, The color scheme does not work for this. Agree with Notifications for Physical Security and Cyber Security. Disagree with Notifications for Transmission Emergency Alerts. This appears to be only IROL related, but could progress to SOL. May have too many of these issued. Suggest the following: Yellow – approaching IROL limit; Orange – procedures implemented to correct IROL; RED – shedding firm to respect an IROL.
Disagree
 
Disagree
 
Agree
R3 creates a special need for multi language operators. US and US-involved entities need to use English in all instances, not only for reliability purposes, but for internal communication purposes and to be able to hire replacements without competing for an artificially small set of operators and to be auditable by NERC.
Group
IRC Standards Review Committee
Ben Li
Disagree
The way the definition of Three-part Communication is worded applies only when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should rather reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it. We believe the term “Interoperability Communication” contradicts the work by the RTO and RC SDT that limits the requirement to use three-part communications to only those communications that explicitly state that the communication is a Reliability Directive and creates confusion within the industry. Additionally, it appears that this definition would encompass all verbal communications and, as such, we question the need for such definition. While we support using three-part communications during routine operations as a best operating practice, we do not believe that it is so critical to reliability that it becomes an enforceable requirement for routine operating instructions. Rather we believe the enforceable requirement should be left to the entity that needs the action to be taken to establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger and auditable and measureable. Both element and facility are used in the Interoperability Communication definition and are NERC defined terms. Did the drafting team intend that the NERC definitions should apply? Then the terms need to be capitalized.
Disagree
This requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how. The only real need for a requirement is to establish that each entity issuing a directive shall use three-part communications and the recipient of a directive shall also properly participate in the of use three-part communication protocol until the message has been correctly spoken and comprehended.
Disagree
It is not clear what the purpose of this communication protocol is or what should even be included in the protocol. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions. The NERC BOT has approved pursuing the Performance-based Reliability Standard Task Force’s recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to delineate actionable reliability requirements from record/documentation requirements. This proposal takes the opposite approach and incorporates a new administrative requirement. We – and the industry as a whole based on the response to the Task Force – do not support such an approach. We suggest deleting this Requirement from the Standard. Furthermore, the establishment of R2-R7 as elements of the CPOP required in R1 appears to contradict the recent shift in direction that NERC has taken regarding defining criteria as bullets under a requirement. See NERC’s August 10th informational filing regarding assignment of violation risk factors and violation severity levels in regards to dockets RM08-11-000, RR08-4-000, RR07-9-000, and RR07-10-000. COM-003 R2 states: “shall use pre-defined system condition terminology as defined in Attachment 1-COM-003-1 for verbal and written Interoperability Communications.” Why does R1 establish the requirement for a procedure, when the procedure is essentially defined by R2-R7. If there is such a reliability need to establish these requirements, one could conclude nothing else is so important that it needs to be included because it is not identified in the standard. Furthermore, R2 appears to define Interoperability Communications for attachment 1 communications only. Is this the intent of the drafting team?
Disagree
It is not clear what value there is in identifying alert levels. There does not appear to be any differentiation in actions taken based on the alert levels. Why not just state the number of substations attacked, etc? Further, the “pre-defined” system conditions and alert levels are too detailed and overly prescriptive. System operators need to spend time looking for the right color and level to communicate the prevailing system condition terminology to avoid violating the standard. This task does not lend itself to promptly and effectively deal with the emergency situation. Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the parties such as Distribution Provider and Generator Operator cannot have access to these systems due FERC standards of conduct requirements. Attachment 1 and R2 do not appear to be in synch primarily due to the definition of Interoperability Communications. By definition, Interoperability Communication is about how entities change the state of the BES and Attachment 1 is about notifying of what already happened to the BES.
Disagree
There is no need to use a common time zone for communications. There is already a requirement to use hour ending for scheduling purposes, inadvertent accounting, CPS and other standards where needed. There is no demonstrated benefit to reliability to use a common time zone. The time zone should be identified in the communication. Use of CST will cause significant and unnecessary costs and the resulting reliability benefit is not clear. Some of the costs will arise to change systems such as RCIS, IDC, scheduling and E-Tag systems, etc. Not only does this requirement attempt to determine HOW entities operate within their various footprints, it would significantly change the way many markets are structured. To implement this into existing Markets would cost significant time, money and resources while not enhancing reliability in these areas. We believe that, when operating across time-zones, simply referencing “Central Standard Time” or “Eastern Standard Time” is sufficient for other operating entities to reliably operate; also, let’s not lose sight of HOW MANY entities would have to modify their existing practices, hardware, software, Control System, billing systems, bidding systems, etc. We are strongly opposed to this requirement.
Disagree
Based on the definition of Interoperability Communications, R5 could imply that three-part communications is required to communicate routine operating instructions. We believe this Requirement contradicts the work that has been done and substantially progressed through two other SDTs and creates confusion within the industry. We believe this Requirement would, in fact, be adverse to reliability instead of enhancing reliability by reducing the amount of pre-action communications that may occur prior to taking action because operators may be more concerned with not repeating back during such pre-action, strategic calls and/or discussion. We support the work being done by the RC SDT and RTO SDT which would define a directive based on the determination of the person giving such an order. We believe, it should be left to the entity that needs the action to be taken to establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger and auditable and measureable. R5 is not consistent with the Functional Model. Only the RC, BA, and TOP issue directives. Thus, the term “….when issuing a directive….” should be “….when communicating directives….” , so both the issuer and receiver are included in the requirement.
Disagree
While this requirement may represent a good utility practice or even a best practice, it is not so necessary to be enforceable through enforceable requirements. Imagine the situation in which an operator says “A as in apple” instead of using the NATO Alpha. Even though the listener should clearly be able to discern the correct meaning, the speaker’s company could be sanctioned even if the correct actions were taken as a result of the clear communication. Also, many organizations may have established communications protocols which are functioning properly and making a change may actually hinder reliable operations by introducing unnecessary confusion.
Disagree
Please confirm our understanding of this requirement. We believe that the SDT intends for the requirement to compel all companies to use the same name for all facilities. If this is the intention, we disagree with the requirement. This may represent a good utility practice but it is not necessary to be a requirement. The key question is: “Do the companies’ personnel understand one another?” If I know that my company refers to a tie-line as Alpha and my neighboring company calls it Beta, I know what he means when communicating to me. That is all that matters.
Disagree
It is not clear what value is realized by declaring an alert status particularly with regard to cyber and physical attacks. There does not appear to be any differing actions taken based on the alert status. Given that no differing actions are taken for cyber and physical attacks, it seems it would be more beneficial to use specific information such as 12 substations have been physically or cyber attacked. This is more meaningful than issuing a red alert that would only indicate more than one site has been attacked. Furthermore, we question the value of communicating the physical and cyber alerts. How does this notification help the BES reliability? Consider the following example. One BA in Oklahoma is 34,323 sq miles. Communicating that an attack occurred in the BA and RC tells other operators that somewhere in Oklahoma an attack occurred. This notification does not present any information that could require actions on the operators’ parts and will only generate phone calls for more information. Furthermore, PSE and CSE is a type of sabotage which is reported in CIP-001 R2 already. TEA Alerts are already covered in IRO-006-East-1, IRO-009, IRO-010, IRO-014.01 R2. Also, several entities have observed confusion during the field-test of these Alert Levels because there are inconsistencies in the implementation of various stages of Alerts. It certainly has not enhanced Reliability. Attachment 1 contains a conflict. The last sentence of the opening paragraph of Attachment 1 reads, “The time frame for declaration of these Alert states shall be consistent with the approach used to declare EEAs and would normally apply to Real Time declarations and not forecast conditions.” In Transmission Emergency Alerts Condition Yellow, Orange and RED: The Reliability Coordinator or Transmission Operator foresees or is experiencing conditions where all available generation resources are committed to respect the IROL and/or is concerned about its ability to respect the IROL. “Forsees” is a forecast condition. In condition Orange and Red for TEA Level Two/Three, the initial notification requirements are redundant with IRO-006-East-1 R3.2. Under the Make Final Notifications, is curtailed intended to mean canceled or terminated? The term Curtailed in operations generally means cuts for schedules/tags. EEA’s use terminated. We recommend using terminated. Distribution Service Providers should be Distribution Provider to be consistent with the Functional Model.
Agree
Many RC communications are issued to multiple parties using blast communication systems such as the RCIS. Several of the parties such as Distribution Provider and Generation Operator cannot have access to these systems due FERC standards of conduct requirements. Requirement 2 and the listing of functional entities required to be notified within the RC footprint in attachment 1 create a de facto requirement for them to have RCIS access or an unnecessary burden to communicate with all functional entities listed separately. Having to communicate to all functional entities in that list verbally and individually would create an unnecessary burden that distracts the RC from actual system operation and represents a detriment to reliability.
Agree
In some market structures, TSPs and LSE do not own or operate equipment. Thus, including them in the requirements is an unnecessary burden for these areas. The requirement to use CST attempts to determine HOW entities operate within their various footprints and it would significantly change the way many Markets are structured. To implement this into existing Markets would cost significant time, money and resources while not enhancing reliability in these areas. We believe that, when operating across time-zones, simply referencing “Central Standard Time” or “Eastern Standard Time” is sufficient for other operating entities to reliably operate; also, let’s not lose sight of HOW MANY entities would have to modify their existing practices, hardware, software, Control System, billing systems, bidding systems, etc. We are strongly opposed to this requirement.
Agree
We believe that the existing standard COM-002 is actually better than this standard. This standard causes more confusion and ambiguity and creates unnecessary or overly cumbersome requirements that add little or no value to reliability. Additionally, we cannot understand how all requirements but R1 have been determined to have a HIGH VRF when, many of them are dictating HOW communications should take place and not when and why or what. COM-002 retirement does not appear to be consistent with the direction of the RC SDT. The RC SDT appears to be adding requirements. More coordination is requirement between these two teams. Recommendation 26 of the August 14, 2003 blackout report is cited as a driver for extending three-part communications. We believe the title of Recommendation 26 is misleading and when reviewed separately from the supporting text of the recommendation and direct and contributing factors in the report results in an incorrect interpretation. “Failure to identify emergency conditions and communicate that status to neighboring systems” is one of the contributing factors and the supporting text of the recommendation clearly refer to shoring up communications during emergency and anticipated emergency conditions and establishing an emergency broadcast communication system to alert regulatory, state and local officials. The supporting text of Recommendation 26 only mentions addressing alerts, emergencies or other critical situations. Some have incorrectly inferred the initial clause of Recommendation 26, “Tighten communication protocols”, means the recommendation applies to all routine communications. The first paragraph in Attachment 1 of COM-003-1 an EEA is stated as being an Emergency Energy Alert rather than an Energy Emergency Alert. This should be corrected for consistency with other standards and to avoid confusion. Also in this paragraph, the term "states" should be replaced with "levels" in order to maintain consistency with the tables in the Attachment as well as EOP-002-2.1 to which this Attachment refers.
Individual
Brett Koelsch
Progress Energy Carolina, Inc
Disagree
The definition for Interoperability Communication needs more clarification/an interpretation since the type of communications is not defined, the term "reliability-related information" undefined, and it may be so diluting as to de-emphasize true reliability directives.
Disagree
The word "Neighboring" is used in TOP-002 R18. Excluding this word in the proposed COM-003-1 means that each entity would have to coordinate the uniform identifiers with an undefined number of entities in the entire Interconnection.
Disagree
A requirement to create a CPOP and mandating absolute adherence to that CPOP is overly prescriptive, may not improve reliability of BES operations, and may serve to delay communications and therefore delay actions necessary to respond to threats to the reliability of the BES.
Disagree
The link between COM-003-1 R2 and Attachment 1 for entities other than the Reliability Coordinator is unclear. R2 links with Attachment 1 and is applicable to a host of entities while Attachment 1 seems to only provide pre-defined system condition terminology for use during notifications by the RC to other entities.
Disagree
Mandating that all “Interoperability Communications” be based on Central Standard Time could generate an error precursor- (i.e. some entity communicating a reliability directive in a location using EST to a different entity in a location using EST having to convert the time stamp to CST introduces possibilities of errors and/or delays.) A better approach for those entities that communicate across time zones is for those entities to agree/coordinate on a time standard reference.
Disagree
PEC supports creating a definition of Reliability Directives. PEC may then agree that each entity shall use 3-part communications when issuing Reliability Directives during “Interoperability Communications.” Alternatively, simplify and change to use Three Part Communications when using Interoperability Communications.
Disagree
NATO stands for North Atlantic Treaty Organization. This proposed requirement is a best practice and does not serve to increase the reliability of the BES.
Disagree
 
Agree
R2 which links with Attachment 1 is applicable to a host of entities while the Attachment seems to only provide pre-defined system condition terminology for use during notifications by the RC to other entities. PEC feels that unscripted specific language used by RCs now on RCIS and in verbal communications currently provides the necessary awareness and information to entities without personnel having to refer to a procedure or remember color codes to decipher the meaning. This attachment does not serve to increase the reliability of the BES.
 
no
Agree
This proposed revision, if implemented, may introduce unnecessary complications into communications between entities which may lead to delays and misunderstandings, potentially decreasing the reliability of the BES.
Group
PEF
Dania Colon
Disagree
PEF does not agree with the adoptation of the proposed term “Interoperability Communication”. The term “Reliability Communication” should be used instead. The proposed term “Interoperability Communication” is defined such that it applies to a state or status change of an element or facility of the BES – but there are many reliability-related communications which do not necessarily apply to a state or status change.
Agree
 
Agree
 
Disagree
PEF recommends that the color coding and definitions that are used by Homeland Security also be used for the notification of physical and cyber emergency alerts reported to the RC. This would follow the ES-ISAC standard already adopted by the electric industry. If the attachment is adopted as is, PEF recommends adding the EEA levels to provide “pre-defined system condition terminology.”
Disagree
PEF feels that the use of CST will create too much confusion within the different entities, particularly during emergency communications. We recommend the use of GMT instead.
Agree
 
Agree
 
Agree
 
Agree
PEF recommends that the color coding and definitions that are used by Homeland Security also be used for the notification of physical and cyber emergency alerts reported to the RC. This would follow the ES-ISAC standard already adopted by the electric industry. If the attachment is adopted as is, PEF recommends adding the EEA levels to provide “pre-defined system condition terminology.”
Disagree
 
Agree
PEF recommends that the color coding and definitions that are used by Homeland Security also be used for the notification of physical and cyber emergency alerts reported to the RC. This would follow the ES-ISAC standard already adopted by the electric industry.
Agree
PEF believes additional NERC defined entities (such as Generators Owners) should be made applicable to this standard. Specifically, PEF believes that the Interchange Authority should be added due to the communications required between the Reliability Coordinator and the Interchange Authority. PEF also believes that the adoption of R4 would have major implications on the tagging process. PEF believes that all tagging would be required to be done using CST due to schedule check-out between BAs, TSPs, LSEs and RCs. Therefore, PSEs should be made applicable as well for R3 and R4.
Group
PPL
Annette Bannon
Disagree
Three-part Communication is too prescriptive. How will “all call/blast” communications be handled? Also, it is unclear what communications are included in Interoperability Communication.
Disagree
It is not clear what real time communications take place with a TSP and/or a LSE that would put the BES in jeopardy and thus necessitate them to be included as an applicable entity.
Disagree
Will the CPOPs be developed regionally, by RCs, by TOPs, by BAs? Will some entities have to adhere to various CPOPs since they may operate in various areas? Too many unanswered questions to support this concept.
Disagree
This requirement should be applicable to a RC only. Some registered entities may not even receive these types of communications. Since the responses are the same for all levels noted in attachment 1, there is questionable value to defining this level of additional administrative detail.
Disagree
This requirement is overly prescriptive and the benefit to reliability by switching everyone to CST is unclear.
Disagree
Only RCs, TOPs, & Bas issue directives. The other entities should be removed from this requirement.
Disagree
The way this could be interpreted is that every type of communication between every applicable entity would have to use the NATO phonetic alphabet. This would be impractical since many of the current communications do not require this level of specificity.
Disagree
Requirement R7 in draft COM-003-1 came from TOP-002-2, Requirement R18. The original requirement intended that neighboring Balancing Authorities use uniform line identifiers when communicating information about their tie lines. This requirement drops that clarification and introduces the additional requirement to use pre-determined “equipment” identifiers. Having to mutually agree in advance on identifiers for every switch & transformer is another example of a prescriptive requirement whose violation will not affect system reliability, yet will expose entities to large fines.
No comments either way since this applies specifically to RCs.
Disagree
 
Disagree
 
Agree
If this draft standard would be approved as it is currently proposed, the implementation plan is way too short considering all the process and system changes that are needed to comply with the numerous additional requirements.
Individual
Scott Berry
Indiana Municipal Power Agency
Disagree
It is not clear in the definition of Interoperability Communication if this is communication between two outside entities (two different companies) or could apply to communication between two entities within the same company. For example, communication between a company's generation plant and the same company's dispatcher.
Disagree
The OPCP SDT does not give a real justified reason on making this requirement move from TOP-002-2 to COM-003-1, except saying that the team believes it is appropriate. Unless there is a very sound or technical justification for moving it, the requirement should be left in the current standard (TOP-002-2) to reduce the extra work and confusion this may cause among the industry. In addition, since Inoperability Communication is not clearly defined, if two LSE entities are communicating, do they have to follow the cummunication protocal required in COM-003?
Disagree
What reliability purpose is served by restating requirements two through seven in a Communications Protocol Operating Procedure (CPOP)? Since these requirements are the only required items in the CPOP, entities will just be restating these requirements in their CPOP. In addition, this is an administrative requirement which does not fit into the new performance-based standard principle that should be used by SDT's.
Disagree
No. Does attachment 1 cover all possible communication scenarios and terminology? Using pre-defined condition terminology does not allow flexiability in communications and for near changes in communications that might be needed depending on the situation.
Disagree
There is no need to use a common time zone. The time zone should be identified in the communication, if needed. The reliability benefit is not clear for using one time zone, and the cost associated with using one time zone will be significant and unnecessary. The use of just CST will cause confusion, because one ISO has all its systems in EST and another ISO systems has its systems in EPT. If an entity is required to use CST when verbally communicating to one or both of these two ISOs, then many mistakes and confusion will result because their portals continue to be in their respective times.
Disagree
The definition of Interoperability Communications is not clear and this requirement could require Three-part Communications to communicate routine, internal instructions within an entity. In addition, the definition of a directive is being worked on by a NERC SDT, and this definition might help clear up any confusion in this requirement, along with a better definition of Interoperability Communications.
Disagree
An entity should not be required to use a specific phonetic alphabet. If a letter needs to be clarified, then boy, bob or beta should be allowed to convey the letter "B". In an emergency, an entity wants its coordinators to be concentrating on the situation and not worrying about using the proper phonetic alphabet word for the letter "B".
 
 
 
 
Agree
This standard is not needed because requirement two in COM-002 takes into account the use of Three-part Communication which is the main reliability requirement from COM-003. The use of a procedure (R1), the English language (R3), a standard time zone (R4), the NATO phonetic alphabet (R6), and a pre-defined system condition terminology (R2) are administrative requirements (not performance based requirements) and if not used, all of them definitely do not have a high VRF. If an entity does not use a procedure, but ensures they follow requirement 2 of COM-002 and both parties have a clear understanding of the directive what other reliability requirement is necessary. One recommendation might be for the COM-002 Standard Drafting Team or another SDT to come up with a definition for a directive.
Individual
Michael R. Lombardi
Northeast Utilities
Disagree
The term “Interoperability Communication” creates confusion within the industry and contradicts the work by RTO and RC SDT in Project 2006-06 that limits the requirement to use three-part communications when issuing Reliability Directives (defined in Project 2006-06) that address anticipated and actual emergency conditions. Additionally, it appears that this definition would encompass all verbal communications and, as such, we question the need for such definition. The definition of “three-part communication” may be viewed as accurate and consistent with the work that has been done and substantially progressed through two other SDTs, we believe the RC SDT requirement, which includes “and shall acknowledge the response as correct or repeat the original statement to resolve any misunderstandings”, is more complete. Again, we believe the term “Interoperability Communication” contradicts this work and creates confusion within the industry. It appears to mandate 3-part communication during operational strategic discussions, as well as other “non-action” oriented communications. We believe this Requirement would, in fact, be adverse to reliability instead of enhancing reliability by reducing the amount of pre-action communications that may occur prior to taking action because operators may be more concerned with not repeating back during such pre-action, strategic calls and/or discussion.
Disagree
The SDT expanded Requirement R18 of TOP-002-2 by adding the term “equipment”. This Requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how. The only real need for a requirement is to establish that each entity issuing a directive shall use three-part communications and the recipient of a directive shall also properly participate in the of use three-part communication protocol until the message has been correctly spoken and understood. LSEs and TSPs do not own or operate equipment, and as such in a market environment should not fall under the mandates of this requirement. Neither the TSP nor the LSE provide or receive information about specific lines or equipment in real-time. Therefore, requirement R7 should not apply to them absent clear evidence that a realistic (not hypothetical) threat to reliability would exist if they are omitted. We do not think that such a threat would exist.
Disagree
This proposed communication protocol is redundant to Requirements R2-R7, and should not be included in this Standard. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions. The NERC BOT has approved pursuing the Results-based Reliability Standard Ad Hoc Working Group recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to eliminate administrative requirements. This proposal takes the opposite approach and incorporates a new administrative requirement. The industry as a whole, based on the response to the Task Force, does not support such an approach. This Requirement should be deleted from the Standard.
Disagree
It is not clear what value there is in identifying alert levels since there does not appear to be any differentiation in actions taken based on the alert levels. Additionally, it has been our experience of during the field-test of these Alert Levels, that there are inconsistencies in when to implement various stages of Alerts and, we believe, this introduces more confusion than exists today.
Disagree
There is no reliability need to use Central Standard Time (CST) a common time zone for communications. Eastern Standard Time (EST) is used in New England and within the NPCC region. Converting to a different time zone will be confusing to the operators and the field personnel. The time zone that will be used should be agreed between each operating entity. This should only impact those entities that cross two time zones. If NERC or a Region were to perform an investigation that involves entities across the eastern interconnection, it would be appropriate for the investigation team to request data using a specific time zone.
Disagree
Based on the definition of Interoperability Communications, R5 implies that three-part communications is required to communicate routine operating instructions, or during operational strategic discussions as well as other “non-action” oriented communications. This Requirement contradicts the work that has been done and substantially progressed through two other SDTs and creates confusion within the industry. This Requirement would, in fact, be adverse to reliability instead of enhancing reliability by reducing the amount of pre-action communications that may occur prior to taking action because operators may be more concerned with not repeating back during such pre-action, strategic calls and/or discussion. The work being done by the RC SDT and RTO SDT in Project 2006-06 defines a Reliability Directive based on the determination of the person giving such an order. The entity that needs the action to be taken should establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger, auditable, and measurable.
Disagree
Not only does this requirement attempt to determine HOW entities operate with their various footprints, it may change the way many Markets are structured. What is the difference between using the word “Zebra” instead of “Zulu” to signify the letter “Z”? And, why would this be enforceable. Perhaps this should be a guideline document rather than an enforceable Requirement. There is no reliability need for this Requirement.
Agree
 
Disagree
No concerns or suggestions (Disagree = No)
Disagree
(Disagree = No)
Disagree
(Disagree = No)
Agree
Many of the requirement proposed in this posting either reiterate the drafts as posted (i.e. English language) or introduce confusion when compared to the drafts as posted. The scope should be limited to R2 and R7, so as not to duplicate or contradict the on-going work of other SDTs. (Agree = Yes)
Individual
Eric Olson
Transmission Agency of Northern California
 
Disagree
There is no additional reliability benefit to the proposed applicability of COM-003-1 Requirement R7 to Transmission Service Providers (TSP) and Load Serving Entities (LSE), since TSP and LSE must already comply with effectively the same terms in TOP-002-2 Requirement R18. Furthermore, TSP and LSE exposure to penalties and sanctions associated with non-compliance of TOP-002-2 Requirement R18 would effectively be doubled if they were required to also comply with COM-003-1 Requirement R7.
 
 
 
 
 
 
 
 
 
Agree
The requirements of this standard as drafted should not be applicable to Transmission Owners (TO). This standard pertains to real-time operations, whereas the TO function does not have real-time operational responsibilities according to the currently effective and proposed NERC Reliability Functional Model, Versions 4 and 5, respectively.
Group
Florida Municipal Power Agency (FMPA) and some members
Frank Gaffney
Disagree
The definition of Communications Protocol can be improved as: Policies and procedures that govern how verbal and written communication is exchanged. The definition of Three-part Communication could be improved by simplifying the language as: A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly by the party receiving the communication to the initiating party, and the same information is verbally confirmed to be correct by the initiating party. The definition of Interoperability Communication can be improved by using NERC Glossary of Terms definitions, e.g., Element and Facility ought to be capitalized in the definition, and the use of both Element and Facility is redundant and only the term Facility needs to be used since a Facility is essentially defined as a BES Element.
Agree
The implementation plan does not specify that TOP 002 2, R18 will be retired. The disposition of the SAR explains this, but, it should be clear in the implementation plan.
Disagree
If one of the goals is consistent communications, why would the standard require each Entity to develop a separate CPOP? For consistency, shouldn’t the Reliability Coordinator develop the CPOP (with input from the other Entities) and all other Entities within the RC’s area adopt it?
Agree
 
Disagree
We believe that any time zone can be used as long as the parties come to a common understanding of time through communication. Also, if an Entity mistakenly starts off a conversation using a time other than Central Standard Time, but corrects themselves during the 3-part communication process, is that a violation? We believe not, that as long as the communicating entities come to a common understanding of time, there is no violation. More clarity on this is desired. We assume such opportunity to correct mistakes is present throughout the standard and the language of the standard ought to reflect that. A high VRF is not appropriate, especially if the parties involved in the communication have a common understanding of the time, who cares what time zone?
Agree
The word “directive” is ambiguous. The standard should either require the Reliability Coordinator to define a “directive” or the standard should make this a defined term so that there is clarity between what is and what is not a directive. In fact, the “disposition” does state that “Reliability Directive” definition is in the scope of the SDT’s effort. We do not think that this merits an increase from a “Medium” VRF in COM-002-2 R2 to a “High” VRF in this standard, especially if the actual action taken was in accordance with the direction given.
Disagree
How strict are the NATO pronunciations? E.g., “Uniform” is designated as pronouncing the “i” as a long “ee”, most people I know do not do that. Similarly, there are multiple pronunciations of “Quebec”, “Sierra”, “Victor”, “Three”, “Four”, “Five”, and “Nine” to name a few, yet one pronunciation is specified. We presume that if the wrong pronunciation is used in the current draft of the standard, there would be a violation, currently at a high risk factor and high severity level, which seems rather severe. FMPA suggests that the SDT revisit this with an eye towards at least not penalizing someone for saying “five” instead of “fife”, and possibly with an eye towards saying “’f’ as in ‘frank’” is OK, rather than being strict with NATO nomenclature.
Agree
For clarity, a NERC Glossary defined term is more appropriate than “line or equipment” identifiers, such as “Facility” or “Element” identifiers. A VRF of “High” is not appropriate. Note that TOP-002-2, R18, which this requirement retires, was “Medium”.
Agree
(FMPA assumes that commenting "agree" means "yes, we have suggestions for improvement") It seems that the first two tables on Physical and Cyber Emergency Alerts are nearly identical. Why not combine them? On the third table on IROLs, are IROLs the only emergencies, e.g., how about a capacity / energy emergency? Shouldn’t that be in a table as well?
Disagree
(FMPA assumes "disagree" means that we are not aware of any regional variances)
Disagree
(FMPA assumes that "Disagree" means that we are not aware of any conflicts)
Agree
(FMPA assumes that "Agree" means "Yes, we do have other comments) The Violation Risk Factor for R2 should be “Low”, not “High”. It is administrative in nature. The Measures make the types of evidence an “or” statement, e.g., “(e)vidence may include … voice recording, transcripts, operating logs, OR on site observations” (emphasis added). The Data Retention section seems to make evidence an “and” statement, e.g., “Each … (Responsible Entity) shall retain … dated operator logs for the most recent 12 months AND voice recordings or transcripts … for … 3 months” (emphasis added). These statements are inconsistent with each other and both ought to be “or” statements. Due to the variability of the length of a month, data retention ought to be expressed in days rather than months, e.g., 90 days instead of 3 months. Why is the Transmission Owner included in the applicability of the standard? What “Interoperability Communications” are they involved with? If the Transmission Owner is included, why isn’t the Generation Owner? Explain the inconsistent treatment of Transmission Owners and Generator Owners. R3 – what if an entity starts to communicate in a language other than English, but, as part of the 3 part communication process changes to English and completes all steps of 3-part communication in English, is that entity non-compliant or compliant? How should EOP-001-0, R4.1 coordinate with COM-003-1? Should EOP-001-0, R4.1 focus on internal Entity communications?
Individual
Darcy O'Connell
California Independent System Operator
Disagree
Three-Part Communications: There is no leeway given if the “intent” of the information is repeated back correctly. If the initiating party mispronounces a word and the receiver does not, is it a violation? Also there is a possibility of delaying actions due to multiple repeat backs while attempting to repeat back verbatim. The air traffic control /pilot communications could be held up as the current best practice standard in critical communications, and utilizing three-part techniques… and they do NOT use verbatim word-for-word repeat. Rather the messages are often truncated, but still indicate an understanding of the message. Interoperability Communication: The proposed definition does not distinguish between internal and external entities. A more specific term than entity is needed here for clarity. With no more guidance than provided, a Generation Dispatcher may be considered a separate entity than the Transmission Dispatcher in the same room. As proposed the definition opens the doors for wildly different interpretations. We think this term, in this usage, applies to communication between companies, but we are not sure. Interoperability Communication is a bit of an unconventional use of the word interoperability. The standard strives to ensure communication protocols ensure interoperability. Communication Interoperability normally in usage, refers to the ability of dissimilar systems to exchange data. Its use here is unnecessarily confusing. It’s a rather messy way of saying, inter-company communication.
Agree
 
Disagree
CAISO Comment; The requirement does not distinguish between intra and inter communications. Even though the proposed definition of “Interoperability Communications” is between two “entities”, how will an auditor interpret it? Will this be taken to the extreme and be required to address communications between two different functions within one organization? For example, between the generation desk and the scheduling desk? How important is this plan? This requirement has a low Violation Risk Factor while the individual requirements that makeup the plan have High Violation Risk Factors. Furthermore, the Violation Security Levels do not address failure to follow the protocol in the plan. Based on the VFR and VSL, it is easy to conclude this plan does little in supporting an adequate level of reliability.
Disagree
CAISO Comments; Regarding CEA; CIP-002 requires responsible entities to identify their cyber assets and critical cyber assets. This requirement does not address any identification and requires responsible entities to declare emergency conditions for non-critical assets. How does this provide an adequate level of reliability? What technical justification did the SDT use in determining an actual or imminent cyber or physical threat to any BES generating facility, substation, or transmission line constitute an emergency declaration? Regarding PSEA and CEA; This requirement does not provide an adequate level of reliability. As a general statement, receiving notification from the RC stating XXXX BA has identified (actual or imminent) physical or cyber threats affecting 1 or 999 control center(s), generating facility(ies), substation(s), or transmission line(s) close to your jurisdiction would provide an adequate level of reliability compared to XXXX BA has declared a PSEA or CEA condition ORANGE. Why is the SDT promoting requirements that reduce reliability and dumb-down communications? Is this the correct standard to add a requirement such as this? Physical and Cyber threats are addressed in the CIP standards and emergencies are addressed in the EOP standards. Both require notification so why include it in a COM standard? Is there a possibility of double jeopardy between this requirement and CIP requirements? If this requirement must be included, Per attachment 1 – COM-003-1 (PSEA and CEA section) the Reliability Coordinator is the only responsible entity with any defined actions. It is suggested the SDT remove the BA, TO, TOP, GO, TSP, LSE, and DP due to lack of applicability. The same entities should be removed from the measure (M2) also. Until “soft words” such as “threat” and “sabotage” are defined or clarity is provided the industry should not be proposing standards based upon them. Regarding TEA; What technical justification did the SDT use in determining that notifying all BA, DP, GOP, TOP, and TO in the RC area of a possible IROL violation provides an adequate level of reliability? There are no associated actions for the BA, DP, GOP, TO, and TOP to perform upon notification so what is the purpose of this requirement? The Alert Level Guide is still in the test phase; does not the Alert Level Guide need to be approved prior to any standard which references the guide be approved? Comments: Per attachment 1 – COM-003-1 the Reliability Coordinator is the only responsible entity with any actions. Suggest removing BA, TO, TOP, GO, TSP, LSE, and DP. Or assign them actions. The same entities should be removed from the measure (M2) also.
Disagree
CAISO Comments; Any standardization of time zones, in order to enhance reliability or reduce costs would use GMT as the reference zone in our opinion. The use of Central Standard Time is problematic because some months of the year other time zones would be at the same time as CST (Eastern Daylight Savings Time) and others not. Adopting systems that require system operators to sometimes operate in a time zone that is not their own local time and sometimes to operate in a time zone that is equivalent to their own local time is standardization that is not actually standard. How does using Central Standard Time for all verbal and written communication improve or support reliability? The SDT needs to explain how this requirement provides an adequate level of reliability for real-time operations for any entity operating outside the Central Standard Time Zone.
Disagree
CAISO Comments: Until “directive” is a defined term the industry should not accept requirements governing actions regarding directives. Directive is currently being defined in an interpretation. Subsequent interpretations may subvert the standards drafting process. Terms should be formally defined before inclusion in other standards to prevent future interpretation issues, including the changing of a standard outside of the accepted Standard Development process.
Disagree
This requirement is a best practice. Maybe the standardized alpha-numeric communication is something that companies should be required to train their personnel on, maybe it could even be a requirement of their CharliePapaOscarPapa. As this requirement is literally written a system operator who used the word ‘cat’ instead of the word ‘charlie’ when giving a directive would violate a sanctionable standard with a VRF of ‘High’ and a VSL of ‘Severe’.
Disagree
CAISO Comments; This Requirement is problematic as it doesn’t actually steer towards standardization. It mandates that companies have potentially scores of agreements agreeing on terms with each party it interacts with, all of which may be different. It ensures the system operator will spend more time ensuring terminology is correct for a given inter-company communication and once again, less time actually reliably operating the system. Standardization can only occur in a meaningful manner at very minimum, the interconnection level. Also the language in the VSL section uses “mutually understood”, which the CAISO supports as opposed to the requirement and measure use “mutually agreed upon”. Mutually agreed upon is overly prescriptive.
CAISO Comments; Information regarding the Alert Level Guide field test has not been widely circulated and unproductive as of late. Does not the Alert Level Guide need to be approved prior to any standard which references the guide be approved? What was the outcome of the field testing? Was reliability enhanced? Attachment 1 describes ‘normal, alert, and emergency operating conditions’, then goes on to never use those terms again in any meaningful manner. To further confuse it then mixes color coding of steps with levels. Which is it, Condition Red or Level 3? The attachment directs Reliability Coordinators to make vague notifications to the functional entities in its footprint. It directs Reliability Coordinators to make these vague notifications to entities that do not use, in our case the WECCNet. Is it really anticipated that the Reliability Coordinator calling on the telephone every DSP in its footprint with a vague notification will be an enhancement to reliability?
Agree
CAISO Comments; The proposed requirement R7 will cause regions operating in any time zone other than Central to draft regional standards to avoid this non-reliability supporting requirement.
Disagree
 
Agree
The Drafting team should take a hard look at the VRFs and VSLs established in this standard and contrast them against VRFs and VSLs for other adopted standards. We do not feel, as an example, that the use of Spanish in a normal communication between two companies, while improper, should carry a VRF of ‘high’ with a VSL of ‘severe’. The draft standard focuses too much attention on prescriptive remedy than ensuring understanding.
Individual
Brandy A. Dunn
Western Area Power Administration
Agree
 
Agree
 
Agree
 
Disagree
It’s very confusing to refer to each condition using a color and/or a level number. In other areas, we are accustomed to using Alert Levels (ie. EEA states). The color designation seems to throw in an unnecessary element that doesn’t add any value.
Disagree
This could be a potential problem since Operators will need to communicate with field personnel and local utilities in their local applicable time zone. It could be confusing to communicate by referring to a different time zone in other instances. It seems like it would make more sense to require that the time zone being used in a communication must be specifically and clearly referred to and identified. It doesn’t matter so much WHICH time zone is used, it just matters that everyone understands which one is being used.
Agree
 
Disagree
Not everyone is familiar with the NATO phonetic alphabet, so it would be another thing for operators to have to memorize, or to always have in front of them to refer to.
Agree
 
Agree
 
Disagree
 
Disagree
 
Disagree
 
Individual
Catherine Koch
Puget Sound Energy
Agree
 
Disagree
PSE agrees in the consolidation of communication type activities into one standards, however the blanket addition of the TSP and LSE across all requirements doesn't seem appropriate. Additional thought should be given in the potential for these two entities to participate in the communication activities contemplated by each requirement, rather than incorporating them wholesale. For example, a quick search on the term “directive” in the current set of standards indicated that neither Transmission Service Providers or Load Serving Entities (or even some of the other entities covered by the proposed standard) are likely to issue directives under the requirements of those standards, so is it appropriate to subject them to the requirements of Requirement 5?
Disagree
As discussed in Question 2, further consideration should be given to whether it is appropriate to include all the listed entities in this requirement. Additionally, the phrase “is not limited to” should be removed from the last sentence of the proposed requirement. The standard should specifically spell out what should be included in the CPOP. This phrase would lead to confusion about what an entity must include in the CPOP and is likely to result in inconsistent enforcement of the requirement. Also R1 appears to require a CPOP that will be used by personnel responsible for Real-time generation control and Real-time operation of the interconnected Bulk Electric System. It is unclear if this specifity in who has to follow this extends to R2-R7 as well(while as noted the CPOP has to include elements of R2-R7). Without that clarity, the aspects of R2-R7 could seeming extend to communication between non-critical personnel regarding non-critical information. In addition, it appears that each of these entities must develop their own CPOP with clarity how the protocol gets vetted so that it is effectively employeed across the entities. Finally, when reviewing the Functional Model document and it's discussion of tasks and relationships to other entities, it is unclear why the TO is included in the applicability as they perform no real-time functions and provide no real time information.
Disagree
This requirement, along with the associated M2, will be almost impossible to substantiate for audit purposes. For example, would an entity be required to present, and an auditor be required to listen to, voice recorder records for the data retention time? It is difficult to image another way to prove an entity complied with this requirement. Further the statement "as defined in Attachment 1" implies a set of definitions can be found and yet Attachment 1 is not structured in such that way. Is the system condition terminology just the terms "condition yellow", "condition orange", and "condition red". The procedural and time aspects described in this attachment creates confusion as to whether compliance is required under this standard or a different one. Suggest, more simplified presentation of definitions or glossary for clarity. Finally the inclusion of "written" communications creates a question relative to real-time information or whether this is extending beyond that timeframe. Most real time information sharing is verbal due to the urgency of it. Suggest removal of written.
Disagree
The requirement for common time zone should be at the descretion of the Reliability Coordinator in the respective region to determine. The conversion to CST has no apparent value. It would be much more reasonable to require communications related to time to include the time zone used in that communication. If common time zone across the nation is required it should only be imposed on the RCs as they would communicate with each other more readily than entities to other national entities. If an entity does not operate within the CST, the need to convert during periods of stress may increase the potential for error and reduce reliability.
Disagree
The requirement should use the NERC defined term “Reliability Directive,” instead of the general term “directive.”
Disagree
This requirement is too burdensome when compared to its benefits. The proposed requirement covers many different types of verbal communication and converts a useful communication protocol into mandatory requirement, which carries with it large potential penalties. Under this requirement, an operator’s use of the phrase “M as in Mary” instead of “M as in Mike” would be violation of NERC reliability standards. The requirement for Three-Part Communications covers most of this ground in a much more useful fashion and ensures parties understand the information. The use of this protocol is a matter that should be left for entities to consider for inclusion in their CPOPs, but should not be a mandatory requirement to use the protocol. Further it is again assumed that based on R1, this information is related to real time. As well further examples of what a real time issuing of a "notification" is and what "other realibiltiy relatied operation information would be needs to be specified.
Disagree
As discussed in Question 2, Requirement 18 should be removed from TOP-002-2 (or any successor standard) upon adoption of this standard if this requirement is included in this standard. Further the term mutually agreed implies that a discussion has occurred prior to the need to verbalize or write these types of communications. The additional specificity of "pre-determined" is duplicative or leads one to think there is formal guidance as to what the "identifier" should be. Remove "pre-determined". It also begs the question of timeframe which could bring interpretation issues during an audit.
Disagree
See discussion in Question 4. Also the attachment applies to Reliability Coordinators only, yet the requirement referencing the attachment applies to additional entities. Those entities should be removed from Requirement 2 or the attachment and Requirement 2 should be clarified to address what those additional entities’ responsibilities are under the attachment.
I might suggest one for R4 by each region that is not in the Central Standard Time zone.
 
 
Group
NERC Standards Review Subcommittee
Carol Gerou
Disagree
Concerning Three Part Communications: Please clarify by answering the following. Does the word “correctly” mean repeating back word for word or would paraphrasing the intent of the message received prove that the receiving party understands the intent and specific action of what they are required to accomplish? Please verify that Three Part Communications will be required when issuing directives related to emergency situations, and not every time communications is required between two parties. We believe the proposed definition for the term “Interoperability Communication” is too broad and ambiguous. We recommend the following instead: “Communication between two or more Functional Entities (not within the same organization) to exchange reliability-related information to be used by the entities to change the state or status of Facilities of the Bulk Electric System.” The inclusion of the terms “Functional Entities” and “Facilities” removes the ambiguity which we believe is contained in the proposed definition. (Both of these terms are defined in NERC’s Glossary) In addition, the inclusion of the phrase “not within the same organization” clarifies that the focus of definition is to address communication between different Functional Entities. The way the definition of Three-part Communication is worded applies only when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should rather reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it. We believe there should be a definition added for “Directive” as orders given in an emergency situation. Directive, as currently used in the industry, is understood to mean an emergency situation and the party issuing the “Directive” states as such, so everyone knows it is an emergency situation. In the “Disposition of Requirements identified in the SAR for Operations Communications Protocols as Possibly Needing either Modification or Movement” document included with the proposed standard, it is stated that COM-002-2, R2 is being modified in Project 2006-06 to include a new definition for “Reliability Directive” and that it is to be included in the NERC Glossary. It also states that when it is completed, it will be moved into COM-003-1 and COM-002-3 will be deleted. It is our opinion that the definition of Reliability Directive must be included in the review and approval of COM-003-1, as it is central to many of the actions to be taken. We understand that the SDT is working closely with the Drafting Team working on Project 2006-06 and believe that this team needs to use the term “Reliability Directive” as a replacement for the term “directive” which is in the current version of COM-003-1. The Drafting Team working on Project 2006-06 has defined Reliability Directive as: “A communication initiated by a Reliability Coordinator, Transmission Operator or Balancing Authority where action by the recipient is necessary to address an actual or expected Emergency.” The NSRS recommends use of this definition and the term “Reliability Directive” as opposed to “directive”.
Disagree
TOP-002 R18 states that BA, TOP, GOP TSP and LSE shall use uniform line identifiers when referring to transmission facilities of an interconnected network. COM-003 R7 states that each RC, BA, TO, TOP, GOP, TSP, LSE and DP shall use pre-determined, mutually agreed upon line and equipment identifiers for verbal and written Interoperability Communications. TOP-002 allowed the TOP to communicate what the line identifiers were via a list and use during communications. The new requirement implies that the parties must agree upon the line identifiers and that agreement must be documented. We believe the requirement should require the exchange of line identifies but not impose that they be mutually agreed upon. This requirement represents a “how” and not a “what”. In general, standards should be focused on “what” not how.
Disagree
We request that R1 be rewritten for real time operation of elements and facilities connected to the BES. Based upon the concerns that we have with Requirements R2-R7 we would not support this requirement. We would support requirement R1 if it stopped after the first sentence and then merely listed the minimum requirements that should be included in the Procedure such as; (1) time zone, (2) language spoken, (3) when phonetic alphabet will be used, etc.. This will allow the Entities to draft their own CPOP per the intent of the requirement and avoid the concerns that we have documented for the remainder of the requirements. Reliability Standards are supposed to describe “What” is required, not “How” compliance would be achieved. We believe this proposed Reliability Standard describes more the the “How”, and is contrary to the Results Based Standards Initiative being implemented by NERC. The NERC BOT has approved pursuing the Performance-based Reliability Standard Task Force’s recommendations to assess the existing standards, modify and develop standards that support reliability performance and risk management, and work on an overall plan to transition existing standards to a new set of standards. One goal of this effort is to eliminate administrative requirements. This proposal takes the opposite approach and incorporates a new administrative requirement. We – and the industry as a whole based on the response to the Task Force – do not support such an approach. We suggest deleting this Requirement from the Standard. The CPOP should only apply to verbal communications. It could be implied that written communications (switching order affecting the BES) must have a CPOP, which would essentially be a writing guide procedure for how to write a procedure. The CPOP would need to be developed for each entity on how to write a CPOP and all the requirements contained in this draft standard. Every entity has unique switching instruction templates that have been developed over time in negotiations with unions, third-parties, etc, which have detailed procedures for their use. Requiring the use of a CPOP on top of that is adding additional complexity that adds nothing to the reliability of the BES.
Disagree
The attachment only applies to the RC. We recommend R2 state that the RC shall use pre-determined system condition terminology and the BA, DP, GOP, TOP, and TO shall follow orders and directives unless such acts violate safety, etc. Either the attachment should be changed or the requirement should be changed for accurate accountabilities.
Disagree
We believe that requiring the use of Central Standard Time (CST) in the Operating Arena (Real-Time) would reduce the level of reliability on a real-time basis. We understand that one of the primary reasons for going to one time zone is to aid in Event Analysis. It is our belief that during the analysis of an event, there is adequate time to make the necessary adjustments for time zones. The Group performing the analysis could require all data being submitted be in one time zone as the basis. Requiring the use of CST is an added burden to the Operations Staff in real-time that does not help them.
Disagree
Without defining “directive” the SDT is leaving the industry in the same situation we are currently in. As discussed in the response to Question #1 above, it is our opinion that the definition of Reliability Directive must be developed and included in the discussion of this standard (COM-003-1), and should be as defined in Project 2006-06: “A communication initiated by a Reliability Coordinator, Transmission Operator or Balancing Authority where action by the recipient is necessary to address an actual or expected Emergency.”. Based on the definition of Interoperability Communications, R5 could imply that three-part communications is required to communicate routine operating instructions. We believe this Requirement contradicts the work that has been done and substantially progressed through two other SDTs and creates confusion within the industry. We believe this Requirement would, in fact, be adverse to reliability instead of enhancing reliability by reducing the amount of pre-action communications that may occur prior to taking action because operators may be more concerned with not repeating back during such pre-action, strategic calls and/or discussion. We support the work being done by the RC SDT and RTO SDT which would define a directive based on the determination of the person giving such an order. We believe, it should be left to the entity that needs the action to be taken to establish the need for three-part communications by stating in the communication that they are issuing a directive. This would be a clear trigger and auditable and measureable.
Disagree
The required use of the phonetic alphabet should be documented in the Entities CPOP per our comments to question #3. While this requirement may represent a good utility practice or even a best practice, it is not so necessary to be enforceable through enforceable requirements. All information passed by a NERC Certified System operator falls under the scope of Requirement 6: “directives, notifications, directions, instructions, orders or other reliability related operating information”. Based on that definition, all communication would fall under this Requirement. The NATO phonetic alphabet does not allow for the use of numbers ten and beyond. An entity WOULD be found non compliant for saying “open switch fourteen bravo”. We do not believe this is reasonable as it adds nothing to the reliability of the BES is too prescriptive and all encompassing and could potentially confuse or slow down the communication process. We recommend that use of the NATO phonetic alphabet be included in the NERC operator certification training program and removed from this standard. As we recommended above, the term “directive” should be replaced with “Reliability Directive”.
Disagree
Field personnel may not have access to the predetermined agreed to line and equipment identifiers. Requiring universal use of these identifiers could lead to confusion with field personnel within and between companies. This could lead to a decrease in the reliability and safety of the BES. As written R7 is expanding the requirement for agreed upon identifiers. We believe it is not necessary or required to have agreed upon equipment identifiers between companies as long as the line identifiers have been agreed upon. TOP-002 R18 states that BA, TOP, GOP TSP and LSE shall use uniform line identifiers when referring to transmission facilities of an interconnected network. COM-003-1, R7 states that each RC, BA, TO, TOP, GOP, TSP, LSE and DP shall use pre-determined, mutually agreed upon line and equipment identifiers for verbal and written Interoperability Communications. TOP-002 allowed the TOP to communicate what the line identifiers were via a list and use during communications. The new requirement implies that the parties must agree upon the line identifiers and that agreement must be documented. We believe the requirement should require the exchange of line identifiers but not impose that they be mutually agreed upon.
Agree
As Attachment 1 is written it only applies to the RC and is a one-way communications path. The BA, DP, GOP, TOP, and TO are to be notified by the RC but the attachment doesn’t state what they are to do with the information. COM-003-1, R1 states that the RC, BA, TO, TOP, GOP, TSP, LSE and DP are to have a CPOP with the elements in R2 through R7, which refer to Attachment 1. If Attachment 1 is applicable only to the RC, as we recommend, there is no reason to have the other Functions listed for Attachment 1. Requirement R2 and Measure M2 need to be revised to be applicable to the RC only. Attachment 1 makes reference to “Distribution Service Providers”. There is no definition of a Distribution Service Provider in the NERC Functional Model, and we believe this should either be revised to Distribution Provider, or deleted entirely from the list.
Agree
If the Central Standard time zone is required as noted in R4, we believe there should be a regional variance to allow the WECC to select the time zone to use as a standard.
Agree
Attachment 1, Physical Security is a basis for the SAR for Project 2009-02, Disturbance and Sabotage reporting SDT.
Agree
Without “Directive” being defined, this proposed standard still leaves a huge area that will cause problems and issues within the industry. We believe the SDT should replace “directive” with “Reliability Directive” and use the definition developed in Project 20006-06: “A communication initiated by a Reliability Coordinator, Transmission Operator or Balancing Authority where action by the recipient is necessary to address an actual or expected Emergency.” We believe Reliability Standard COM-003-1 is entirely too prescriptive, and is in actuality a procedure and not a standard. The Standard needs to focus on the “What” and not the “How”. If the industry is going to truly embrace the Results Based Standards Initiative, this standard must be significantly revised to reflect that philosophy. We believe that the existing standard COM-002 is actually better than this standard. This standard actually causes more confusion and ambiguity and creates unnecessary or overly cumbersome requirements that add little or no value to reliability.
Individual
Michael Gammon
Kansas City Power & Light
Disagree
The definition of Three-part Communication applies only when the communication is understood by the listener the first time. Because the definition requires the listener to repeat the information back correctly, failure of the listener to understand the information the first time could be construed as a violation or at least not fitting the definition. The definition should rather reflect that three-part communication is an iterative process that should be followed until the listener is confirmed by the speaker to get the information correct. We suggest the definition be revised as follows: “A Communications Protocol where information is verbally stated by a party initiating a communication, the information is repeated back correctly to the party that initiated the communication by the second party that received the communication, and the same information is verbally confirmed to be correct or corrected by the party who initiated the communication. The protocol should be followed until the party issuing the information is satisfied that a party receiving the information has understood the communication and confirmed it.” The definition for Interoperability Communication is too broad. Currently, this could mean any communication of information. This should be confined to emergency or unusual operating conditions.
Disagree
Including “equipment” is too broad. This could mean anything and should be limited to transmission devices that could affect the reliable operation of the bulk electric system.
Disagree
This proposed communication protocol is redundant to Requirements R2-R7 and should not be included in this Standard. This standard only needs to focus on requiring three-part communications during actual and anticipated emergency conditions and using agreed upon terminology for switching equipment for bulk electric system.
Disagree
Attachment 1 should be removed from this standard. This is a duplication of the alerts by the NERC Alerts system and the EISAC. In addition, these are reliability standards and should deal with real-time and expected future reliability issues. Alerts are an inappropriate for this standard.
Disagree
There is no reliability need to use a common time zone for communications. There is already a requirement to use hour ending for scheduling purposes, inadvertent accounting, CPS and other standards where needed. There is no additional reliability need to use a common time zone. The time zone should be identified in the communication. Use of CST will actually cause confusion and significant, unnecessary costs with no foreseeable reliability benefit. Some of the costs will arise to change systems such as RCIS, IDC, scheduling and E-Tag systems, etc.
Agree
 
Agree
 
Disagree
Including “equipment” is too broad. This could mean anything and should be limited to transmission devices that could affect the reliable operation of the bulk electric system.
Disagree
The attachment is inappropriate for this standard and should be removed. See response to question #4.
Disagree
 
Disagree
 
Disagree