This comment form is no longer interactive because the comment period is closed.

2009-02 Real-time Reliability Monitoring and Analysis Capabilities | IRO-018-1 & TOP-010-1

Description:

Start Date: 12/10/2015
End Date: 01/26/2016

Associated Ballots:

Ballot Name Project Standard Pool Open Pool Close Voting Start Voting End
2009-02 Real-time Monitoring and Analysis Capabilities IRO-018-1 AB 2 ST 2009-02 Real-time Monitoring and Analysis Capabilities IRO-018-1 09/24/2015 10/23/2015 01/15/2016 01/26/2016
2009-02 Real-time Monitoring and Analysis Capabilities IRO-018-1 Non-binding Poll AB 2 NB 2009-02 Real-time Monitoring and Analysis Capabilities IRO-018-1 Non-binding Poll 09/24/2015 10/23/2015 01/15/2016 01/26/2016
2009-02 Real-time Monitoring and Analysis Capabilities TOP-010-1 AB 2 ST 2009-02 Real-time Monitoring and Analysis Capabilities TOP-010-1 09/24/2015 10/23/2015 01/15/2016 01/26/2016
2009-02 Real-time Monitoring and Analysis Capabilities TOP-010-1 Non-binding Poll AB 2 NB 2009-02 Real-time Monitoring and Analysis Capabilities TOP-010-1 Non-binding Poll 09/24/2015 10/23/2015 01/15/2016 01/26/2016

Filter:

Hot Answers

Scott McGough, Georgia System Operations Corporation, 3, 1/26/2016

- 0 - 0

Comments: ERCOT continues to be concerned that the proposed standard is too prescriptive and goes beyond the associated FERC directive regarding a requirement addressing “capabilities.”  In particular, these standards were developed to address operator awareness of tool or other outages that could impact real-time monitoring. 

 

Further, several of the requirements involve many more entities beyond the Reliability Coordinators and, absent a requirement for coordination, participation, and action in response to the Reliability Coordinator’s identification of an issue, the proposed standard will not achieve its intended objective as written.  This is extremely challenging (R1.3) because the majority of issues related to poor data quality or invalid analysis tool solutions can only be resolved by parties outside of the Reliability Coordinator (e.g facility owners, telecom companies, etc.)

 

Additionally, real-time data and monitoring capabilities are critical to the certification of a Reliability Coordinator and are not “dynamic.”  Because such “capabilities” are complex, require coordination and inputs from other entities, and are key to the continued performance of a Reliability Coordinator’s duties, they are not subject to frequent change and therefore likely do not need continued monitoring and assessment. 

 

Finally, several other reliability standards and associated requirements are contingent upon the availability of real-time tools and data, and these other standards and requirements are subject to the compliance monitoring and enforcement program.  ERCOT would recommend that requirements addressing capabilities be utilized as part of certification review and not as a reliability standard subject to the compliance monitoring and enforcement program.

 

Should NERC continue this project, however, ERCOT recommends the following language adjustments to Requirement R1.3.  No matter what the SDT intends the language to mean, this requirement language may still be read to mean the RC’s Operating Process or Operating Procedure should be written to actively resolve data quality issues even though the ability to resolve data issues may lie with another party.  Accordingly, ERCOT recommends:

 

R1.3 current language: “Actions to resolve Real-time data quality issues with the entity(ies) responsible for proving the data when data quality affects Real-time Assessments.”

 

R1.3 ERCOT suggested language: “Actions to notify the entity(ies) responsible for providing data of any Real-time data quality issue affecting Real-time Assessments.”

 

This language aligns with the objective communicated by the SDT, aligns with what is in practice today, aligns with the SDT concept that IRO-010 and TOP-005/003 require data providers to address data quality issues, and is within the capability of the Reliability Coordinator to perform.   This language is also consistent with the numerous examples within the NERC Reliability Standards where an entity is required to notify other entities that are responsible for or have an obligation to take actions where the notifying entity cannot or does not perform the reliability task.  

Elizabeth Axson, 1/25/2016

Unofficial_Comment_Form_2009-02_121015_ERCOT draft_ssolis_eha_nb.docx

- 0 - 0

Other Answers

John Fontenot, 12/10/2015

- 0 - 0

John Fontenot, 12/10/2015

- 0 - 0

Daniel Mason, On Behalf of: Daniel Mason, , Segments 1, 5

- 0 - 0

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC, SPP RE - Segments 1, 3, 5, 6

- 0 - 0

MRO-NERC Standards Review Forum (NSRF), Segment(s) 3, 4, 5, 6, 1, 2, 1/6/2016

- 0 - 0

Don Schmit, 1/20/2016

- 0 - 0

Thomas Foltz, AEP, 5, 1/21/2016

- 0 - 0

Andrew Pusztai, 1/21/2016

- 0 - 0

RoLynda Shumpert, On Behalf of: SCANA - South Carolina Electric and Gas Co., SERC, Segments 1, 3, 5, 6

- 0 - 0

John Merrell, Tacoma Public Utilities (Tacoma, WA), 1, 1/22/2016

- 0 - 0

Southern believes that the criteria in R1.1 should be limited to the RC’s ability to monitor and assess the current/expected condition of its RC area within the capabilities of its monitoring tools.

Each RC has the inherent responsibility to protect the integrity of the system in its RC area and contribute to the overall integrity of Interconnection as required by other approved reliability standards.  The NERC approved IRO-002-4, IRO-010-2, TOP-003-3 and TOP-004 standards requires the RCs and TOPs to have monitoring tools and capabilities to assess system conditions in its area and to perform next day and real time reliability assessments to identify/mitigate potential issues that could have an adverse impact on reliability.  Moreover, Southern asserts that the capability to maintain an accurate model along with the required telemetry is already being assessed at the certification stage, and that maintenance of such capability does not need to be assessed on an ongoing basis as adequate data quality is required to perform the assessments required by the aforementioned standards.  

Since the RC is constantly evaluating the quality of data received to ensure it has an accurate state of system conditions to perform real time assessments, through the same processes demonstrated during certification.  Southern believes that the reliability goals of maintaining adequate data, tools and situational awareness are accomplished via the IRO-010 and TOP-003-3 NERC reliability standards and to impose this new standard focusing on data quality would only serve as administrative in nature and would not provide any substantial increases in reliability.

Given that Southern disagrees with the reliability need for this standard, Southern notes that the detailed requirements (R1.1.1, etc…)regarding assessing data quality, on a point by point basis, was moved to the technical background section of the purposed standard, which is helpful as long as the RSAWs developed doesn’t incorporate this “one size fits all” approach for assessing data quality.

 

Southern Company, Segment(s) 1, 6, 3, 5, 4/13/2015

- 0 - 0

We continue to disagree with the need to create Reliability Standards (this and TOP-010-1) to stipulate the requirements for having processes in place to ensure data quality and real-time analysis capability, and adequate alarming system to alert operators of suspicious data or analysis capability. These processes are fundamental to enabling the RC, TOP and BA perform their reliability tasks and meet applicable standard requirements. Data quality, real-time analysis capability and alarming system must be demonstrated during the certification process, and maintained at all times. We continue to urge NERC and the SDT to place these requirements in the Organization Certification Requirements, if they are not already explicitly stipulated.

Leonard Kula, Independent Electricity System Operator, 2, 1/22/2016

- 0 - 0

Michelle Amarantos, APS - Arizona Public Service Co., 5, 1/22/2016

- 0 - 0

Jared Shakespeare, 1/23/2016

- 0 - 0

PJM does not believe this standard is necessary.  RC, BA & TOP entities currently have adequate tools for real-time monitoring and analysis.  The existing Standards (i.e., IRO, TOP, & BAL) adequately define what needs to be monitored by each entity without defining the tools.   Creating new requirements will not increase the reliability of the BES.

Additionally, some of the new proposed requirements (IRO-018-1 Req. 1, TOP-010-1 Req. 1) state:

Each RC, BA & TOP shall implement an Operating Process to address the quality of the Real-time data… the term quality is ambiguous and subjective.   This term needs to be defined.  Similar to Requirement 2, the terms indications of quality needs to be defined. If not defined, it could result in varying interpretations throughout the industry.

Lastly, the NERC Operating Reliability Subcommittee (ORS) has drafted a Reliability Guideline, “Loss of Real-Time Reliability Tools Capability / Loss of Equipment Significantly Affecting ICCP Data.” This guideline will help ensure that tools are adequate and if they are degraded for any reason, the potentially impacted entities are aware and can take action if needed.

PJM supports the comments submitted by the ISO/RTO Council Standards Review Committee.

- 1 - 0

Duke Energy suggests changes to the language of the requirements and sub-requirements which would make the standard less vague, and more concise. We recommend the following revisions:

R1:

-Modify R1 to state: “Each Reliability Coordinator shall develop and implement an Operating Process or Operating Procedure to address…”

We feel that this closes a gap wherein the standard requires an entity to implement a Process or Procedure, but never requires an entity to develop one in the first place.

We believe that R1.1 and R1.2 are similar in nature, and would be better suited as one requirement. We recommend the same revision for R2.1 and R2.2. We suggest the following:

-Combine R1.1 and R1.2 to state: “Criteria for and display of quality of Real-time data to System Operator.”

R2:

-Modify R2 to state: “Each Reliability Coordinator shall develop and implement an Operating Process or Operating Procedure to address…”

We feel that this closes a gap wherein the standard requires an entity to implement a Process or Procedure, but never requires an entity to develop one in the first place.

We believe that R2.1 and R2.2 are similar in nature, and would be better suited as one requirement.  We suggest the following:

-Combine R2.1 and R2.2 to state: “Criteria for and display of quality of Real-time data to System Operator.”

Also, we recommend that the requirement be reworded to more closely resemble the rationale. The rationale points out that the RC shall have Processes or Procedures that address issues related to the quality of analysis results used for Real-time Assessments. The language of R2 states that an RC must have Processes or Procedures to address the quality of analysis used in its Real-time Assessments. We feel that adding the word “results” in the requirement decreases possible ambiguity that is currently present in this standard. It is the quality of the results that is paramount, and should be the focus, rather than the quality of the analysis itself. (See out language suggestion after the comment below.)

Next, Duke Energy recommends that R2 should include a provision that an RC should include in their procedure some specification as to what constitutes a “quality issue” (see R2.3) that an RC must take action to resolve. Without having those specifications, it would be difficult to determine what issues necessitate actions and which ones do not. We suggest the following revision to R2:

-Modify R2 to state: “Each Reliability Coordinator shall develop and implement an Operating Process or Operating Procedure to address the quality analysis results, and include criteria to define levels of material impact, used in its Real-time Assessments.”

Lastly, Duke Energy suggests that R3 should be revised to more closely align with the rationale. When reading the rationale, it is clear that the heart of this requirement is having an alarm process monitor capability, and not necessarily the alarm process monitor itself. We recommend using the language found in the rationale which more clearly state the intent of the requirement. We suggest the following:

-Modify R3 to state: “Each Reliability Coordinator shall have an alarm process monitoring capability that provides notification(s) to its System Operators…”

Duke Energy , Segment(s) 1, 5, 6, 4/10/2014

- 0 - 0

The SRC fails to see the reliability risk that this project is intending to address.  The August 14 Blackout as well as the 2011 Southwest Outage have been thoroughly and exhaustively investigated, reported upon, and the root causes mitigated appropriately.  Those investigations did not indicate a lack of continent-wide ability to address those root causes – which would be the basis upon a NERC continent-wide reliability standard is needed to address a reliability “gap”.  Therefore, pointing to the need for this project based on mitigated, historical events falls short of identifying the reliability risk that this is intended to “fix.”  If, for example, WECC continues to have a vested interest in further mitigating the 2011 Southwest Outage through standard development, we suggest this project be migrated into a regional standard for WECC.  Lastly, the SRC believes that, absent a Standard specific for tools, a RC, TOP, or BA would, in fact, have violations of existing operational Requirements if they do not provide adequate monitoring and tools to their operators (i.e. other “things” would happen).

 

Further, the Requirements as written, “…to address the quality of the Real-time data necessary…” are ambiguous, lack consensus about how to measure, and do not rise to the level of a NERC Standard.

 

This proposed project appears to be well-suited for a guideline document as opposed to a Standard as the proposed requirements address the quality and availability aspects of data and tools for system analysis rather than what’s needed to monitor and assess system performance (which are already covered by other standards).  As written, the standards appears to intend to stipulate “how” not “what” (i.e., they do not appear to be a results-based standards).  The SRC believes that the existing Standards (i.e., IRO, TOP and BAL) sufficiently define what needs to be monitored by each entity without defining the tools (i.e., without defining the “how”), which is appropriate.  In the alternative, this could be considered a process to be used for Certifying new entities, in line with a methodology developed by the ERO and registered entities for assessing adequacy of tools for addressing the “quality” of real-time data and tools, for assurance that RC, BA and TOPs have the ability to monitor and assess system performance appropriately in accordance with existing, performance-based Standards Requirements.

 

The SRC notes that the tools available to operators have progressed well beyond those available in 2003.  If defined tools would have been hardcoded in a standard at that time, it would have limited focus and investment to those things that were in the standard.  Further, expanding on our point above, the SRC believes that the “what” regarding tools is more appropriately captured in the certification expectations for BAs, RCs, and TOPs.  Additionally, it would be appropriate for Regions to evaluate tools as part of the Registered Entity’s Inherent Risk Assessment (IRA).  This would include the scope of tools, backups, etc. and would provide an adaptable approach that would encourage continuous improvement.   

 

Additionally, the SRC recommends that NERC coordinate with the NATF to encourage inclusion of an ongoing “care and feeding” of tools evaluation and information sharing in their efforts with the provision that they make information on good practices available to the wider NERC community so that non-members can learn from the innovation of others. 

 

Finally, to avoid these issues in the future and to support communicating to FERC when a Standard is not needed and another tool is more suitable, the SRC suggests that future SARs be voted on by industry to determine whether they should proceed as a Standards project or another means is a more appropriate method through which to achieve the SAR’s objective.

- 0 - 0

Jamison Cawley, Nebraska Public Power District, 1, 1/25/2016

- 0 - 0

- 0 - 0

We support the draft standard IRO-018-1.

R2 2.3 Instead of “Action to resolve analysis quality issues affecting its Real-time Assessments”, suggest change the language to “Action to resolve quality analysis issues affecting its Real-time Assessments.”

RSC no ISO-NE IESO Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 1/25/2016

- 0 - 0

Joshua Andersen, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

Not applicable to BPA.

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mark Kenny, 1/25/2016

- 0 - 0

The Rational for R3 mentions that the alarm process monitor must not fail with a simultaneous failure of the Real-time monitoring alarm processor.

What happens when all procedures and processes are followed properly and SCADA system fails because of an IT problem. In another words, RC must not be attributable when SCADA systems fail because of an IT problem. The standard should also consider accountability of the SCADA supplier.

Si Truc Phan, On Behalf of: Hydro-Qu?bec TransEnergie, NPCC, Segments 1

- 0 - 0

IRO-018-1 is not applicable to Hydro One.  However, Hydro One Networks Inc. would like to point out that R1.2 should specify, that the RC’s Operating Process or Operating Procedure which is to include actions to resolve Real-time data quality issues with the entity(ies) responsible for providing the data, should include a mutually agreed upon schedule and actions.

Oshani Pathirane, 1/25/2016

- 0 - 0

David Jendras, Ameren - Ameren Services, 3, 1/25/2016

- 0 - 0

(1)   We feel the language within Requirements R1 and R2 are vague and should not require criteria for evaluating data quality and analysis that could be too ambiguous and unenforceable.  These requirements need to identify what real-time data and analysis are necessary to perform monitoring and assessment functions, and identify the specifications necessary to maintain reliability.  The SDT should clarify the meaning of “quality,” and incorporate this explanation in the standard’s Guidelines and Technical Basis or Rationale sections.  Without a minimum criteria specified, we feel this does not provide enough information to make an objective determination for an auditor.  Furthermore, we suggest adding references to Part 1.3 and Part 2.3 that mitigation actions should be initiated within 30 minutes.  We feel these references align the failure to implement actions with other mitigation actions required.

(2)   Requirement R3 expects the RC to have evidence that it has an alarm process monitor that provides failure notifications to System Operators.  We feel this language is redundant with many requirements of Reliability Standard IRO-002-2.  For instance, Requirement R4 of IRO-002-2 states the RC “shall have detailed real-time monitoring capability of its Reliability Coordinator Area and sufficient monitoring capability of its surrounding Reliability Coordinator Areas.”  Moreover, Requirement R7 of IRO-002-2 states “Each Reliability Coordinator shall continuously monitor its Reliability Coordinator Area.”  While requirements R1 and R2 of the proposed standard, IRO-018-1, are concerned with quality expectations of data and analysis, respectively, Requirement R3 identifies a tool or application that the RC must own and operate.  In order to meet the various requirements of IRO-002-2, the RC would already be required to own and operate such applications.  Hence, we recommend the SDT remove requirement R3 of the proposed standard.

(3)   We continue to have concerns that these requirements only focus on System Operators.  We feel that an auditor may not interpret the standard to allow other employees, such as EMS Engineers, to mitigate data or analytical errors.  According to the NERC Glossary Term, a System Operator is one “who operates or directs the operation of the Bulk Electric System (BES) in Real-time.”  We recommend the SDT clarify that these requirements can apply to other employees.

ACES Standards Collaborators, Segment(s) 1, 3, 5, 6, 4, 1/25/2016

- 0 - 0

Meghan Ferguson, 1/25/2016

- 0 - 0

We suggest to the drafting team to mention more information in the rationale box pertaining to Requirement R1 and its sub-part 1.1 on the expectations for the criteria in reference to evaluating the quality of the real-time data. Additionally, our review group would suggest mentioning the criteria examples spoken of in the drafting team's webinar in this section of the rationale box. The review group’s opinion of this is….the criteria examples will give the industry a foundation on how to use various Real-time scenarios to structure their Operational Process and/or Operational Procedure.

In our opinion, Requirement R1 sub-part 1.3 rationale box information (last paragraph) doesn’t match the proposed language for that particular section of the Requirement. The Rationale information doesn’t clearly state what documentation contains the ‘scope of data point information’ this proposed language will help clarify. We would ask are you referring to the SAR, or the RTBPTF Report or could it be the FERC Directive? Our review group would also suggest mentioning the specific document(s) in the rationale section so there will be no misconception on what documentation contains the scope in reference to the data points and how those points should be addressed when providing evidence during an auditing process.

As for Requirement R2, we would suggest to the drafting team to include the examples provided in their presentation to the rationale section. We feel this information will help give some clarity on what the expectations are for the industry pertaining to Requirement R2.

For Requirement R3, we suggest that the drafting team include some proposed language that suggests including the ‘alarm process monitor that provide modification’ into their Operational Process or Operation Procedure. We feel the current language suggests that this process doesn’t need to be included in the previously mentioned documentation which could lead to interpretation issues from our perspective.

SPP Standards Review Group, Segment(s) , 1/25/2016

- 0 - 0

The Rational for R3 mentions that the alarm process monitor must not fail with a simultaneous failure of the Real-time monitoring alarm processor.

What happen when all procedures and processes are followed properly and SCADA system fails because of an IT problem? In another words, RC must not be attributable when SCADA systems fail because of an IT problem. The standard should also consider accountability of the SCADA supplier

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 1/25/2016

- 0 - 0

See comments for Q2.

John Brockhan, 1/25/2016

- 0 - 0

In general, Texas RE agrees with the changes made by the SDT to draft standard IRO-018-1. However, Texas RE provides the following comments or suggestions to the proposed standard: 

  • Texas RE suggests the SDT consider explicitly stating real-time monitoring in addition to real-time assessments in R1.3.  For example, “Actions to resolve Real-time data quality issues with the entity(ies) responsible for providing the data when data quality affects Real-time monitoring and Real-time Assessments.  In addition, Texas RE would like to highlight that Texas RE is concerned there is no definitive timeframe provided associated with the actions to resolve issues which may lead to a reliability gap due to a myriad of approaches taken by registered entities.  Texas RE supports the RTBPTF recommendations related to real-time monitoring.  Specifically, for telemetry data systems:

 

1) Increase the minimum update frequency for operational reliability data

from once every 10 minutes to once every 10 seconds.16

2) Standardize the procedures, processes, and rules governing key data

exchange issues.17

3) Institute a requirement for data availability from ICCP or other

equivalent systems, based on the ratio of “good” data received (as defined

by data quality codes) to total data received. The ratio must exceed 99

percent for 99 percent of the sampled periods during a calendar month. In

addition, the ratio must not be less than 99 percent for any 30 consecutive

minutes.

4) Establish minimum response times for restoration of data exchange

between control centers following the loss of a data link or other problems

within the source system. As part of this requirement, a trouble-resolution

process standard must be developed that requires all entities responsible

for management and maintenance of ICCP or equivalent systems to

identify, with data recipients that could be affected by a loss of data

exchange capability, a mutually agreeable restoration target time. The

standard process must also include service-restoration escalation

procedures and prioritization criteria.

 

  • Texas RE noticed an inconsistency in language between the standard requirement language and the rationale discussion for Requirement 1 and Requirement 2 which states, “The Operating Process or Operating Procedure must include provisions for indicating the quality of Real-time data to operating personnel.”  Unfortunately, “operating personnel”, is not a defined term and the Requirements specifically states “System Operator”.  Texas RE recommends that the rational language be changed to be consistent with the standard requirements.

     

  • Texas RE is concerned the data retention for R2 is a rolling 30 days while the retention period for R1 is the current calendar year and one previous calendar year with the exception of operator logs and voice recording which shall be retained or a minimum of 90 calendars days.  Texas RE inquires as to why there is a difference in the evidence retention period even though there is very little difference in the measures?  Texas RE recommends an evidence retention period of a year for both R1 and R2 because there is no basis to distinguish actions to address errors in data inputs (R1) and the analysis of the data inputs (R2) and the longer time frame of a year would give the entity more time to resolve data issues.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

Hot Answers

The language is too ambiguous. 

Scott McGough, Georgia System Operations Corporation, 3, 1/26/2016

- 0 - 0

Comments: For purposes of this comment, ERCOT incorporates all of its above comments regarding IRO-018-1.  As with R1.3 in IRO-018-1, ERCOT is concerned that certain language in TOP-010-1 could be read to suggest that the RC must resolve Real-time data quality issues, when in fact the ability to resolve data issues may lie with another party.  Consistent with its suggested revisions to R1.3 in IRO-018-1, ERCOT recommends the following changes to R1.3 and R2.3 in TOP-010-1:

 

R1.3 current language: “Actions to resolve Real-time data quality issues with the entity(ies) responsible for proving the data when data quality affects Real-time Assessments.”

 

R1.3 ERCOT suggested language: “Actions to notify the entity(ies) responsible for providing data of any Real-time data quality issue affecting Real-time Assessments.”

 

And

 

R2.3 current language: “Actions to resolve Real-time data quality issues with the entity(ies) responsible for providing the data when data quality affects its analysis functions.”

 

R2.3 ERCOT suggested language: “Actions to notify the entity(ies) responsible for providing data of any Real-time data quality issue affectings its analysis functions.”

 

Elizabeth Axson, 1/25/2016

- 0 - 0

Other Answers

John Fontenot, 12/10/2015

- 0 - 0

John Fontenot, 12/10/2015

- 0 - 0

The draft version of Requirement R4. reads as follows:

Each Transmission Operator and Balancing Authority shall have an alarm process monitor that provides notification(s) to its System Operators when a failure of its Real-time monitoring alarm processor has occurred.

We believe greater clarity could be brought to this requirement by modifying two awkward terms, "alarm process monitor" and "monitoring alarm processor", as follows:

Each Transmission Operator and Balancing Authority shall monitor its Real-time monitioring alarm system and provide notification(s) to its System Operators when a failure of its Real-time monitoring alarm system has occurred.

 

 

Daniel Mason, On Behalf of: Daniel Mason, , Segments 1, 5

- 0 - 0

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC, SPP RE - Segments 1, 3, 5, 6

- 0 - 0

MRO-NERC Standards Review Forum (NSRF), Segment(s) 3, 4, 5, 6, 1, 2, 1/6/2016

- 0 - 0

We do not believe the issues addressed by the FERC directive rise to the level of requiring a reliability standard.  The intent of the directive and the resulting actions to be taken by the various entities would be better served by an official Guideline rather than a generic standard.  Forcing this into a Standard result in varied interpretations and approachs to “quality” and “adequacy” that do not enhance reliability of the BES. We believe the requirements in general could be improved to be more results based.  As written, they largely will only result in identifying deficiencies after the fact when doing event analysis.  An entity may have a process or procedure as required, but they could miss a piece of data or fail to identify fully the impact a quality issue may have upon their situational awareness.  Simply having the process does not result in increased reliability.

Most entities already have a process in place to alarm or indicate data quality as needed to maintain reliability.  Entities are already required to operate reliably, within SOLs and IROLs, etc.  The creation of this standard as written would serve only to document that process and put it under auditable enforcement – with no discernible impact to maintaining reliability.  In order to make this standard truly results based, there needs to be some identification of the quality level, or data quality thresholds that must be maintained in order for reliability to be maintained.  Then that level (or quality of the data measurements) must be maintained per the standard. 

We suggest that there needs to be more direction given by the Standard in a few areas.  One is that the applicable entity should be determining a data range, time periods, number of manually entered values, etc. that can degrade analysis to the point reliability is threatened (R1.1.1-R1.1.4). 

We find it problematic when an entity may not “own” the data and is simply receiving a quality flag from a sender.  An entity may not receive an accurate quality flag or the quality flag is corrupted in translation over ICCP.  Also, there is no requirement that the measurement devices even be of a particular accuracy.  For example the quality threshold may be more narrow than the accuracy of the device. 

 

Don Schmit, 1/20/2016

- 0 - 0

While AEP agrees with the overall approach and intent of R1, we believe that sub-Requirement R1.3 goes beyond the scope of its parent Requirement. While R1 focuses on addressing the quality of Real-time data, R1.3 requires the Transmission Operator’s Operating Process or Procedure to include actions to “resolve” Real-time data quality issues when data quality affects Real-time Assessments. This is especially concerning when the “entity(ies) responsible for providing the data” are external. Neither the Transmission Operator, nor its Operating Procedure, is able to resolve data issues involving points over which they have no direct control. The entity would have control over their own analysis quality (R3), but again, not the quality of external data. In the webinar held on January 11, the drafting team inferred a different interpretation of R1.3 depending on whether or not the data is externally provided.  The drafting team seemed to be saying “no, you don’t need to resolve data issues for points you do not own, but you still need to document actions to resolve those data issues”, etc. That seems to infer that “actions to resolve” might, in some cases, simply be informing the data owner of the issue rather than remediating issues involving the external data. While the drafting team might interpret R1.3 in this manner, there is no assurance that an auditor would have that same viewpoint.  And if that is indeed the drafting team’s interpretation , R1.3 does not articulate that.  In this same webinar, a drafting team member eventually used the phrase “address the quality” in regards to externally provided data. AEP believes the word “address” is much more appropriate for R1.3 than “resolve”, and using it would allow R1.3 to align with R1 (which already uses the word “address”). As a result, we recommend that the word “resolve” in R1.3 be replaced by “address”, so that it states “Actions necessary to address Real-time data quality issues with the entity(ies) responsible for providing the data when data quality affects Real-time Assessments.”

Thomas Foltz, AEP, 5, 1/21/2016

- 0 - 0

Andrew Pusztai, 1/21/2016

- 0 - 0

RoLynda Shumpert, On Behalf of: SCANA - South Carolina Electric and Gas Co., SERC, Segments 1, 3, 5, 6

- 0 - 0

Requirements R1 and R2 apply to monitoring system conditions. Therefore Tacoma Power believes both requirements should be included in TOP-006-2. Additionally Tacoma Power believes Requirement R4 is unnecessarily redundant, providing no foreseeable improvement to reliable operation of the bulk electric system.

John Merrell, Tacoma Public Utilities (Tacoma, WA), 1, 1/22/2016

- 0 - 0

Southern believes that the criteria in R1.1 should be limited to the BA/TOP’s ability to monitor and assess the current/expected condition of its RC area within the capabilities of its monitoring tools.

Each BA/TOP has the inherent responsibility to protect the integrity of the system in its BA/TOP area and contribute to the overall integrity of Interconnection as required by other approved reliability standards.  The NERC approved TOP-003-3 and TOP-004 standards requires BAs/TOPs to have monitoring tools and capabilities to assess system conditions in its area and to perform next day and real time reliability assessments to identify/mitigate potential issues that could have an adverse impact on reliability.  Moreover, Southern asserts that the capability to maintain an accurate model along with the required telemetry is already being assessed at the certification stage, and that maintenance of such capability does not need to be assessed on an ongoing basis as adequate data quality is required to perform the assessments required by the aforementioned standards.  In addition, there are already NERC approved standards such as TOP-002-2 that currently require the BA/TOP to maintain accurate computer models for analyzing system operations.

Since the TOP is constantly evaluating the quality of data received to ensure it has an accurate state of system conditions to perform real time assessments, through the same processes demonstrated during certification, Southern believes that the reliability goals of maintaining adequate data, tools and situational awareness are accomplished via the IRO-010 and TOP-003-3 NERC reliability standards and to impose this new standard focusing on data quality would only serve as administrative in nature and would not provide any substantial increases in reliability.

Given that Southern disagrees with the reliability need for this standard, Southern notes that the detailed requirements (R1.1.1, etc…)regarding assessing data quality, on a point by point basis, was moved to the technical background section of the purposed standard, which is helpful as long as the RSAWs developed doesn’t incorporate reapply this “one size fits all” approach for assessing data quality.

Southern Company, Segment(s) 1, 6, 3, 5, 4/13/2015

- 0 - 0

Same comment as for IRO-018-1. Please see our comment under Q1, above.

Leonard Kula, Independent Electricity System Operator, 2, 1/22/2016

- 0 - 0

Michelle Amarantos, APS - Arizona Public Service Co., 5, 1/22/2016

AZPS-Comments_Question-2_Project-2009-02_Draft-2.docx

- 0 - 0

Jared Shakespeare, 1/23/2016

- 0 - 0

PJM does not believe this standard is necessary.  RC, BA & TOP entities currently have adequate tools for real-time monitoring and analysis.  The existing Standards (i.e., IRO, TOP, & BAL) adequately define what needs to be monitored by each entity without defining the tools.   Creating new requirements will not increase the reliability of the BES.

Additionally, some of the new proposed requirements (IRO-018-1 Req. 1, TOP-010-1 Req. 1) state:

Each RC, BA &TOP shall implement an Operating Process to address the quality of the Real-time data… the term quality is ambiguous and subjective.   This term needs to be defined.  Similar to Requirement 2, the terms indications of quality needs to be defined. If not defined, it could result in varying interpretations throughout the industry.

Lastly, the NERC Operating Reliability Subcommittee (ORS) has drafted a Reliability Guideline, “Loss of Real-Time Reliability Tools Capability / Loss of Equipment Significantly Affecting ICCP Data.” This guideline will help ensure that tools are adequate and if they are degraded for any reason, the potentially impacted entities are aware and can take action if needed.

PJM supports the comments submitted by the ISO/RTO Council Standards Review Committee.

- 1 - 0

Duke Energy recommends the same changes to the language in TOP-010-1 that it does for IRO-018-1.

Duke Energy , Segment(s) 1, 5, 6, 4/10/2014

- 0 - 0

same comments as under Q1 above.

- 0 - 0

We do not believe the issues addressed by the FERC directive rise to the level of requiring a reliability standard.  The intent of the directive and the resulting actions to be taken by the various entities would be better served by an official Guideline rather than a generic standard.  Forcing this into a Standard result in varied interpretations and approachs to “quality” and “adequacy” that do not enhance reliability of the BES.

We believe the requirements in general could be improved to be more results based.  As written, they largely will only result in identifying deficiencies after the fact when doing event analysis.  An entity may have a process or procedure as required, but they could miss a piece of data or fail to identify fully the impact a quality issue may have upon their situational awareness.  Simply having the process does not result in increased reliability.

Most entities already have a process in place to alarm or indicate data quality as needed to maintain reliability.  Entities are already required to operate reliably, within SOLs and IROLs, etc.  The creation of this standard as written would serve only to document that process and put it under auditable enforcement – with no discernible impact to maintaining reliability.  In order to make this standard truly results based, there needs to be some identification of the quality level, or data quality thresholds that must be maintained in order for reliability to be maintained.  Then that level (or quality of the data measurements) must be maintained per the standard. 

We suggest that there needs to be more direction given by the Standard in a few areas.  One is that the applicable entity should be determining a data range, time periods, number of manually entered values, etc. that can degrade analysis to the point reliability is threatened (R1.1.1-R1.1.4). 

We find it problematic when an entity may not “own” the data and is simply receiving a quality flag from a sender.  An entity may not receive an accurate quality flag or the quality flag is corrupted in translation over ICCP.  Also, there is no requirement that the measurement devices even be of a particular accuracy.  For example the quality threshold may be more narrow than the accuracy of the device. 

Jamison Cawley, Nebraska Public Power District, 1, 1/25/2016

- 0 - 0

- 0 - 0

We support the draft standard TOP-010-1.

RSC no ISO-NE IESO Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 1/25/2016

- 0 - 0

SRP believes the current draft of TOP-010-1 is a significant improvement on the former draft. SRP recommends that in R1 Part 1.3, R2 Part 2.3, and R3 Part3.3 the verbiage should be changed from “Actions to resolve” to “Actions to address”.  The TOP and BA may not be able to resolve all quality issues for all the data it receives but they can address all the data with quality issues.  This change would retain the responsibility for compliance with the TOP and BA. 

Joshua Andersen, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mark Kenny, 1/25/2016

- 0 - 0

See comments from question 1 but replacing RC for TOP and BA.

Si Truc Phan, On Behalf of: Hydro-Qu?bec TransEnergie, NPCC, Segments 1

- 0 - 0

Revisions to remove much of the very specific requirements is a good change and Hydro One Networks Inc. supports this.  In particular, Hydro One Networks Inc. supports the removal of the list of criteria previously stipulated in Draft 1’s R1.1 and R2.1 for evaluating the quality of Real-time data.

Oshani Pathirane, 1/25/2016

- 0 - 0

How is quality defined?  This is too ambiguous as written and internal discussions resulted in multiple opinions.  Quality needs to be better defined within the requirement.

David Jendras, Ameren - Ameren Services, 3, 1/25/2016

- 0 - 0

(1)   We feel the language within Requirements R1 and R3 are vague and should not require criteria for evaluating data quality and analysis that could be too ambiguous and unenforceable.  These requirements need to identify what real-time data and analysis are necessary to perform monitoring and assessment functions, and identify the specifications necessary to maintain reliability.  The SDT should clarify the meaning of “quality,” and incorporate this explanation in the standard’s Guidelines and Technical Basis or Rationale sections.  Without a minimum criteria specified, we feel this does not provide enough information to make an objective determination for an auditor.  Furthermore, we suggest adding references to Part 1.3 and Part 3.3 that mitigation actions should be initiated within 30 minutes.  We feel these references align the failure to implement actions with other mitigation actions required in other reliability standards.

(2)   We understand the SDT interprets the intent of requirement R4 of the industry-approved standard, BAL-005-1, to pertain to only the data necessary to calculate Reportable ACE.  Moreover, the SDT feels that the proposed Requirement R2 does not create double jeopardy with BAL-005-1, and that Requirement R2 is necessary to account for other data monitored by a BA.  We disagree and feel the SDT should remove this redundant requirement or identify this other data in the rationale of this requirement.

(3)   The intent of Requirement R4 requires a TOP or BA to monitor the availability of its real-time monitoring alarm processor.  We feel this requirement is unnecessary, as similar actions are accomplished in order to maintain compliance with other reliability requirements.  For instance, Requirement R5 of TOP-006-3 states “each Reliability Coordinator, Transmission Operator, and Balancing Authority shall use monitoring equipment to bring to the attention of operating personnel important deviations in operating conditions...”  In order to maintain compliance with this requirement, a registered entity is obligated to notify its own personnel when they are unable to use such monitoring equipment.  We recommend the SDT remove Requirement R4 from the proposed standard.

(4)   We continue to have concerns that these requirements only focus on System Operators.  We feel that an auditor may not interpret the standard to allow other employees, such as EMS Engineers, to mitigate data or analytical errors.  According to the NERC Glossary Term, a System Operator is one “who operates or directs the operation of the Bulk Electric System (BES) in Real-time.”  We recommend the SDT clarify that these requirements can apply to other employees.

ACES Standards Collaborators, Segment(s) 1, 3, 5, 6, 4, 1/25/2016

- 0 - 0

The changes made to R1 are helpful in clarifying the scope of data included in this requirement however the term “quality of the Real-time data necessary to perform its Real-time monitoring and Real-time Assessments” would still imply all data specified per TOP-003 as all data specified will be the data used in Real time Assessment and therefore will require TOP to take action on any failed data point. Also the term real time monitoring is not a defined term and should be removed.

 

In addition to the above comments, ITC Holdings agrees with the comments submitted by the SPP Standards Review Group. A copy of SPP’s comments are provided below.

 

We suggest to the drafting team to mention more information in the rationale box pertaining to Requirement R1 and its sub-part 1.1 on the expectations for the criteria in reference to evaluating the quality of the real-time data. Additionally, our review group would suggest mentioning the criteria examples spoken of in the drafting team's webinar in the rationale box of this section. The review group’s opinion of this is….the criteria examples will give the industry a foundation on how to use various Real-time scenarios to structure their Operational Process or Operational Procedure.

 

In our opinion, Requirement R1 sub-part 1.3 rationale box information (last paragraph) doesn’t match the proposed language for that particular section of the Requirement. The Rationale information doesn’t clearly state what documentation contains the ‘scope of data point information’ this proposed language will help clarify. We would ask are you referring to the SAR, or the RTBPTF Report or could it be the FERC Directive. Our review group would suggest mentioning the specific document(s) in the Rationale Section so there will be no miss conception on what documentation contains the scope in reference to the data points and how those points should be addressed when providing evidence during an auditing process.

 

As for Requirement R2, we would suggest to the drafting team to include the examples provide in their presentation to the Rationale Section. We feel this information will help give some clarity on what the expectations are for the industry pertaining to Requirement R2.

 

For Requirement R4, we would suggest they drafting team would include some proposed language that suggests including the ‘alarm process monitor that provide modification’ into their Operational Process or Operation Procedure. We feel the current language suggests that this process doesn’t need to be included in the previously mentioned documentation which could lead to interpretation issues from our perspective.

Meghan Ferguson, 1/25/2016

- 0 - 0

We suggest to the drafting team to mention more information in the rationale box pertaining to Requirement R1 and its sub-part 1.1 on the expectations for the criteria in reference to evaluating the quality of the real-time data. Additionally, our review group would suggest mentioning the criteria examples spoken of in the drafting team's webinar in the rationale box of this section. The review group’s opinion of this is….the criteria examples will give the industry a foundation on how to use various Real-time scenarios to structure their Operational Process or Operational Procedure.

In our opinion, Requirement R1 sub-part 1.3 rationale box information (last paragraph) doesn’t match the proposed language for that particular section of the Requirement. The Rationale information doesn’t clearly state what documentation contains the ‘scope of data point information’ this proposed language will help clarify. We would ask are you referring to the SAR, or the RTBPTF Report or could it be the FERC Directive. Our review group would suggest mentioning the specific document(s) in the Rationale Section so there will be no misconception on what documentation contains the scope in reference to the data points and how those points should be addressed when providing evidence during an auditing process.

As for Requirement R2, we would suggest to the drafting team to include the examples provided in their presentation to the Rationale Section. We feel this information will help give some clarity on what the expectations are for the industry pertaining to Requirement R2.

For Requirement R4, we suggest they drafting team include some proposed language that suggests including the ‘alarm process monitor that provide modification’ into their Operational Process or Operation Procedure. We feel the current language suggests that this process doesn’t need to be included in the previously mentioned documentation which could lead to interpretation issues from our perspective.

SPP Standards Review Group, Segment(s) , 1/25/2016

- 0 - 0

What happen when all procedures and processes are followed properly and SCADA system fails because of an IT problem? In another words, BA or TOP must not be attributable when SCADA systems fail because of an IT problem. The standard should also consider accountability of the SCADA supplier

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 1/25/2016

- 0 - 0

CenterPoint Energy understands recommendations for the scope of this project originated from the 2011 Southwest Outage Report as well as FERC directives in Order 693, however with the vast improvement in technologies involved with monitoring and analysis capabilities over the last 10 years, these recommendations as well as the scope of this project is potentially outdated. CenterPoint Energy is concerned that compliance with Requirements in TOP-010-1 could represent a documentation burden without providing a measureable benefit to reliability.     The main focus of the directives and recommendations referenced above appear to be more related to real-time analysis tools rather than quality of data. CenterPoint Energy believes and feels the industry would benefit more from, reducing the scope of the Standard to those data quality issues that negatively impact real-time analysis and assessments. CenterPoint Energy recommends the SDT delete Parts 1.1, 1.2, 2.1, and 2.2.

John Brockhan, 1/25/2016

- 0 - 0

In general, Texas RE agrees with the changes made by the SDT to draft standard TOP-010-1. However, Texas RE provides the following comments or suggestions to the proposed standard:   

 

  • Texas RE recommends adding the Balancing Authority to the applicability of R3.  Some BA tools can be considered a Real-time monitoring tool, for example, the use of SCED in this region.

  • Texas RE suggests the SDT consider explicitly stating real-time monitoring in addition to real-time assessments in R1.3.  For example, “Actions to resolve Real-time data quality issues with the entity(ies) responsible for providing the data when data quality affects Real-time monitoring and Real-time Assessments.  In addition, Texas RE would like to highlight that Texas RE is concerned there is no definitive timeframe provided associated with the actions to resolve issues which may lead to a reliability gap due to a myriad of approaches taken by registered entities.  Texas RE supports the RTBPTF recommendations related to real-time monitoring.  Specifically, for telemetry data systems:

 

1) Increase the minimum update frequency for operational reliability data

from once every 10 minutes to once every 10 seconds.16

2) Standardize the procedures, processes, and rules governing key data

exchange issues.17

3) Institute a requirement for data availability from ICCP or other

equivalent systems, based on the ratio of “good” data received (as defined

by data quality codes) to total data received. The ratio must exceed 99

percent for 99 percent of the sampled periods during a calendar month. In

addition, the ratio must not be less than 99 percent for any 30 consecutive

minutes.

4) Establish minimum response times for restoration of data exchange

between control centers following the loss of a data link or other problems

within the source system. As part of this requirement, a trouble-resolution

process standard must be developed that requires all entities responsible

for management and maintenance of ICCP or equivalent systems to

identify, with data recipients that could be affected by a loss of data

exchange capability, a mutually agreeable restoration target time. The

standard process must also include service-restoration escalation

procedures and prioritization criteria.

 

  • Texas RE noticed an inconsistency in language between the standard requirement language and the rationale discussion for Requirement 1 and Requirement 2 which states, “The Operating Process or Operating Procedure must include provisions for indicating the quality of Real-time data to operating personnel.”  Unfortunately, “operating personnel”, is not a defined term and the Requirements specifically states “System Operator”.  Texas RE recommends that the rational language be changed to be consistent with the standard requirements.

 

  • Texas RE is concerned the data retention for R2 is a rolling 30 days while the retention period for R1 is the current calendar year and one previous calendar year with the exception of operator logs and voice recording which shall be retained or a minimum of 90 calendars days.  Texas RE inquires as to why there is a difference in the evidence retention period even though there is very little difference in the measures?  Texas RE recommends an evidence retention period of a year for both R1 and R2 because there is no basis to distinguish actions to address errors in data inputs (R1) and the analysis of the data inputs (R2) and the longer time frame of a year would give the entity more time to resolve data issues.

 

 

  • In the Guidelines and Technical Basis documentation there is a statement: “The Operating Process or Operating Procedure must include provisions for indicating the quality of Real-time data to operating personnel”.  Texas RE recommends adding: “including the System Operator” or something to that affect.  The standard is applicable to the System Operators; the term “operating personnel” is undefined.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

Hot Answers

Scott McGough, Georgia System Operations Corporation, 3, 1/26/2016

- 0 - 0

Except for those concerns raised in ERCOT’s comments above, the proposed Implementation Plan appears reasonable.

Elizabeth Axson, 1/25/2016

- 0 - 0

Other Answers

John Fontenot, 12/10/2015

- 0 - 0

John Fontenot, 12/10/2015

- 0 - 0

Daniel Mason, On Behalf of: Daniel Mason, , Segments 1, 5

- 0 - 0

Xcel Energy appreciates the fact that the SDT added some additional time to the Implementation Plan for these standards, however we still feel that the implementation timeline is too short.  We continue to propose a 60 month implementation timeline as suggested previously by the MRO Standards Review Forum which states:

The implementation plan is too short if entities need to specify, order and deploy new or modified Energy Management Systems (EMS) that can monitor, track, and report real-time data quality and availability in accordance with IRO-018 and TOP-010.  Entities should be given an implementation plan with up to 60 months for new EMS software and systems.

The key is to allow entities the proper time to assess their tools and complete the right upgrades once.  While prompt actions are good, forcing entities to assess, order, and deploy equipment in 12 or 18 months will lead to errors and possibly more risk of serious outages and problems in the short term.

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC, SPP RE - Segments 1, 3, 5, 6

- 0 - 0

MRO-NERC Standards Review Forum (NSRF), Segment(s) 3, 4, 5, 6, 1, 2, 1/6/2016

- 0 - 0

18 month implementation is better than the previous 12 month implementation. thank you.

Don Schmit, 1/20/2016

- 0 - 0

As the draft standard is currently written, AEP cannot determine the adequacy of the proposed implementation plan. However, if the drafting team were to replace “resolve” with “address” in R1.3 as suggested above, AEP believes the implementation plan would be sufficient.

Thomas Foltz, AEP, 5, 1/21/2016

- 0 - 0

ATC is in agreement with the Implementation plan for TOP-010-1.   IRO-18-1 is not applicable to ATC.

Andrew Pusztai, 1/21/2016

- 0 - 0

RoLynda Shumpert, On Behalf of: SCANA - South Carolina Electric and Gas Co., SERC, Segments 1, 3, 5, 6

- 0 - 0

John Merrell, Tacoma Public Utilities (Tacoma, WA), 1, 1/22/2016

- 0 - 0

Southern believes that the implementation date should be pushed back to at least 24 months following regulatory approval to allow time for the industry to determine the appropriate technology that is sufficient for each entity’s operations.  We also believe that in order to fully comply with the proposed standard, enough time should be allowed for the industry to update their current procedures and/or to create acceptable procedures, provide training to the appropriate System Operators and allow sufficient time for the entities to determine the technology available that is available and appropriate to support their operations, along with the required functionality.

Southern Company, Segment(s) 1, 6, 3, 5, 4/13/2015

- 0 - 0

Since we do not agree with the need for these standards, we do not support the proposed implementation plan.

Leonard Kula, Independent Electricity System Operator, 2, 1/22/2016

- 0 - 0

AZPS agrees with the standardization (and extension of 12 month requirements) such that all requirements become effective on the first day of the first calendar quarter that is 18 months after the date these standards are approved. 

Michelle Amarantos, APS - Arizona Public Service Co., 5, 1/22/2016

- 0 - 0

Jared Shakespeare, 1/23/2016

- 0 - 0

PJM does not support the proposed standards for the reasons noted in 1 and 2 above.

- 1 - 0

Duke Energy , Segment(s) 1, 5, 6, 4/10/2014

- 0 - 0

We do not agree with the need for the two standards, and therefore do not agree with any implementation plans.

- 0 - 0

Jamison Cawley, Nebraska Public Power District, 1, 1/25/2016

- 0 - 0

- 0 - 0

RSC no ISO-NE IESO Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 1/25/2016

- 0 - 0

Joshua Andersen, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mark Kenny, 1/25/2016

- 0 - 0

Si Truc Phan, On Behalf of: Hydro-Qu?bec TransEnergie, NPCC, Segments 1

- 0 - 0

Hydro One Networks Inc. proposes that a period of at least 18 months be provided for entities to implement Operating Processes or Operating Processes.  Such an effort is onerous and multiple business units and entities would have to align their practices with one another.

Oshani Pathirane, 1/25/2016

- 0 - 0

David Jendras, Ameren - Ameren Services, 3, 1/25/2016

- 0 - 0

We feel the SDT has made a general assumption that each applicable entity already has the processes, procedures, and infrastructure in place to comply with these requirements.  However, we believe entities should have up to 60 months to deploy a new or modified Energy Management System that can monitor, track, and report real-time data quality and availability in accordance with IRO-018 and TOP-010.  The key is to allow entities adequate time to assess their tools and complete the right enhancements once.  While prompt actions are good practices, forcing entities to assess, order, and deploy equipment within 18 months may lead to unintended consequences.

ACES Standards Collaborators, Segment(s) 1, 3, 5, 6, 4, 1/25/2016

- 0 - 0

Meghan Ferguson, 1/25/2016

- 0 - 0

SPP Standards Review Group, Segment(s) , 1/25/2016

- 0 - 0

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 1/25/2016

- 0 - 0

John Brockhan, 1/25/2016

- 0 - 0

Texas RE does not agree with the revised Implementation Plan for the proposed standards.  Alternatively, Texas RE recommends one year which should be sufficient time to implement the new standards since entities are currently responsible for certain real-time monitoring processes and procedures.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

Hot Answers

Scott McGough, Georgia System Operations Corporation, 3, 1/26/2016

- 0 - 0

Elizabeth Axson, 1/25/2016

- 0 - 0

Other Answers

John Fontenot, 12/10/2015

- 0 - 0

John Fontenot, 12/10/2015

- 0 - 0

Daniel Mason, On Behalf of: Daniel Mason, , Segments 1, 5

- 0 - 0

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC, SPP RE - Segments 1, 3, 5, 6

- 0 - 0

MRO-NERC Standards Review Forum (NSRF), Segment(s) 3, 4, 5, 6, 1, 2, 1/6/2016

- 0 - 0

Don Schmit, 1/20/2016

- 0 - 0

Thomas Foltz, AEP, 5, 1/21/2016

- 0 - 0

ATC is in agreement with the VRFs/VSLs for TOP-010-1.   IRO-18-1 is not applicable to ATC.

Andrew Pusztai, 1/21/2016

- 0 - 0

The VRFs and VSLs forTOP-010-1 should be no greater or less than those of TOP-003-3, TOP-004.

RoLynda Shumpert, On Behalf of: SCANA - South Carolina Electric and Gas Co., SERC, Segments 1, 3, 5, 6

- 0 - 0

The VSL for TOP-010-1 Requirement R4 requires the entity to prove the negative for compliance. It is unknown how an entity would prove the alarm process monitor did not fail unless a tertiary monitor was implemented. Tacoma Power does not believe that this is the intent of the standard.

John Merrell, Tacoma Public Utilities (Tacoma, WA), 1, 1/22/2016

- 0 - 0

Although Southern is encouraged that the SDT has now added some low VRFs/VSLs to the proposed standards, we still maintain that the VRFs and VSLs are too high and should be modified additionally.

Southern Company, Segment(s) 1, 6, 3, 5, 4/13/2015

- 0 - 0

Since we do not agree with the need for these standards, we do not support the proposed VRFs and VSLs.

Leonard Kula, Independent Electricity System Operator, 2, 1/22/2016

- 0 - 0

Michelle Amarantos, APS - Arizona Public Service Co., 5, 1/22/2016

- 0 - 0

Jared Shakespeare, 1/23/2016

- 0 - 0

PJM does not support the proposed standards for the reasons noted in 1 and 2 above.

- 1 - 0

Duke Energy , Segment(s) 1, 5, 6, 4/10/2014

- 0 - 0

We do not agree with the need for the two standards, and therefore do not agree with any proposed VRFs and VSLs.

- 0 - 0

Jamison Cawley, Nebraska Public Power District, 1, 1/25/2016

- 0 - 0

- 0 - 0

RSC no ISO-NE IESO Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 1/25/2016

- 0 - 0

Joshua Andersen, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mark Kenny, 1/25/2016

- 0 - 0

Si Truc Phan, On Behalf of: Hydro-Qu?bec TransEnergie, NPCC, Segments 1

- 0 - 0

Hydro One Networks Inc. does not support the VSLs, as they are not consistent with the changes made to Draft 2 of the standard.  For example, the VSL for R1 assumes that entities would implement one or more of the criteria for evaluating Real-time data quality that have now been removed in Draft 2.

Oshani Pathirane, 1/25/2016

- 0 - 0

David Jendras, Ameren - Ameren Services, 3, 1/25/2016

- 0 - 0

We believe that not having good data quality and analysis are a medium risk to BES reliability.  However, we disagree that the VRFs for these requirements should be classified as Medium, as the Operating Process or Operating Procedure that support both more falls in-line with the criteria of a low risk violation.   Our recommendation is further supported with the definition of a Low VRF, as defined within the NERC Violation Risk Factor and Violation Severity Level Justifications document, which states “administrative in nature and a requirement that, if violated, would not be expected to adversely affect the electrical state or capability of the Bulk Electric System.”  The nonexistence of a related Operating Process or Procedure will have no impact on the state or BES capability.

ACES Standards Collaborators, Segment(s) 1, 3, 5, 6, 4, 1/25/2016

- 0 - 0

Meghan Ferguson, 1/25/2016

- 0 - 0

SPP Standards Review Group, Segment(s) , 1/25/2016

- 0 - 0

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 1/25/2016

- 0 - 0

John Brockhan, 1/25/2016

- 0 - 0

Rachel Coyne, Texas Reliability Entity, Inc., 10, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

John Fontenot, 1/25/2016

- 0 - 0

Hot Answers

Scott McGough, Georgia System Operations Corporation, 3, 1/26/2016

- 0 - 0

Elizabeth Axson, 1/25/2016

- 0 - 0

Other Answers

na

John Fontenot, 12/10/2015

- 0 - 0

na

John Fontenot, 12/10/2015

- 0 - 0

Daniel Mason, On Behalf of: Daniel Mason, , Segments 1, 5

- 0 - 0

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC, SPP RE - Segments 1, 3, 5, 6

- 0 - 0

None.

MRO-NERC Standards Review Forum (NSRF), Segment(s) 3, 4, 5, 6, 1, 2, 1/6/2016

- 0 - 0

Don Schmit, 1/20/2016

- 0 - 0

AEP has chosen to vote negative on TOP-010-1, driven by our concerns regarding R1.3, as expressed in our response to Q2.

Thomas Foltz, AEP, 5, 1/21/2016

- 0 - 0

ATC requests a clarification by the SDT in TOP-010-1 on the phrase “affects Real-time Assessments” which is used in sections R1.1.3 and R2.2.3 and the phrase “affecting its Real-time Assessments” in section R3.3.3.  Should “affects” be replaced with “effects” or is this correct as written?

 

Definitions of “affecting”

·        Merriam Webster - causing a feeling of sadness or sympathy - evoking a strong emotional response

·        Cambridge - causing a ​strongemotion, ​especiallysadness

·        Dictionary.com - moving or exciting the feelings or emotions.

·        TheFreeDictionary.com - Inspiring or capable of inspiring strong emotion - moving or stirring the feelings or emotions. - evoking feelings of pity, sympathy, or pathos

 

Definitions of Effect and Effecting

·        Merriam Webster (effect) -  change that results when something is done or happens : an event, condition, or state of affairs that is produced by a cause

·        Dictionary.com (effect) - something that is produced by an agency or cause; result; consequence - power to produce results; efficacy; force; validity; influence

·        Cambridge (effect) - the ​result of a ​particularinfluence; something that ​happens because of something ​else:

Andrew Pusztai, 1/21/2016

- 0 - 0

RoLynda Shumpert, On Behalf of: SCANA - South Carolina Electric and Gas Co., SERC, Segments 1, 3, 5, 6

- 0 - 0

John Merrell, Tacoma Public Utilities (Tacoma, WA), 1, 1/22/2016

- 0 - 0

Southern Company, Segment(s) 1, 6, 3, 5, 4/13/2015

- 0 - 0

Leonard Kula, Independent Electricity System Operator, 2, 1/22/2016

- 0 - 0

On p.12 of the “Guidelines and Technical Basis” document, paragraph 1 defines what is included “Real-time monitoring.” Paragraph 2 goes on to state that there are “functional requirements to perform [Real-time] monitoring… in other standards.” If this is the case, APS recommends the SDT define “Monitoring” as a term in the NERC Glossary as preferable to defining this term in the “Guidelines and Technical Basis” document that is part of the supplemental material in TOP-010.

Michelle Amarantos, APS - Arizona Public Service Co., 5, 1/22/2016

- 0 - 0

Jared Shakespeare, 1/23/2016

- 0 - 0

- 0 - 0

Duke Energy , Segment(s) 1, 5, 6, 4/10/2014

- 0 - 0

- 0 - 0

Jamison Cawley, Nebraska Public Power District, 1, 1/25/2016

- 0 - 0

- 0 - 0

RSC no ISO-NE IESO Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 1/25/2016

- 0 - 0

The rational for TOP-010-1 R1 and R2 indicates that the data of concern for those requirements is the same data that was determined in TOP-003-3.  The TOP-003-3 standard basically specifies what data is necessary for the Real-time Assessments and TOP-010-1 specifies the quality of that data.  SRP recommends combining the two standards so that there is one that addresses what data is necessary and also specifies the quality of that data. Combining the two standards would clarify that the data referred to in TOP-010-1 is the same as the data referred to in TOP-003-1.

Joshua Andersen, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mark Kenny, 1/25/2016

- 0 - 0

Si Truc Phan, On Behalf of: Hydro-Qu?bec TransEnergie, NPCC, Segments 1

- 0 - 0

Overall, the second draft has simplified the requirements to an extent.  Hydro One Networks Inc. believes that some form of oversight or standardization is required to ensure there is a continuous focus on real time monitoring tools.  Data quality measures are appropriate; however, decisions to the degree and method of verification should be left to the discretion of each entity as this will, to an extent, depend on the level of system complexity.   A simple system can be tuned to a small error (or convergence) while a complicated system may require a larger allowance.

R1 and R2 – Since the functional requirements, VRFs, and Time Horizons are identical, these two requirements could be combined into one requirement and made applicable to both the Transmission Owner and Balancing Authority.

R2.2 - The wording in R2.2 could be modified to align with that of R1.3, and read, “Actions to resolve Real-time data quality issues with the entity(ies) responsible for providing the data when data quality affects Real-time Assessments.

R4 - The wording could be improved as follows: “Each Transmission Operator and Balancing Authority shall have alarm process monitoring that provides notification(s) to its System Operators when a failure of its Real-time monitoring alarm processor has occurred”

Oshani Pathirane, 1/25/2016

- 0 - 0

David Jendras, Ameren - Ameren Services, 3, 1/25/2016

- 0 - 0

(1)   We request the SDT provide additional rationale on the need to develop new reliability standards, when we feel many current and approved future standards could be enhanced to support the intent of the SAR.  Other documentation, such as Reliability Guidelines, could be used to elaborate on specific details and concerns regarding data and analytical qualities.

(2)   We thank the SDT for this opportunity to comments on these standards.

ACES Standards Collaborators, Segment(s) 1, 3, 5, 6, 4, 1/25/2016

- 0 - 0

Meghan Ferguson, 1/25/2016

- 0 - 0

SPP Standards Review Group, Segment(s) , 1/25/2016

- 0 - 0

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 1/25/2016

- 0 - 0

John Brockhan, 1/25/2016

- 0 - 0

Rachel Coyne, Texas Reliability Entity, Inc., 10, 1/25/2016

- 0 - 0

na

John Fontenot, 1/25/2016

- 0 - 0

na

John Fontenot, 1/25/2016

- 0 - 0

na

John Fontenot, 1/25/2016

- 0 - 0

na

John Fontenot, 1/25/2016

- 0 - 0