ISN Node responsibilities and procedures

ISN Node

Responsibilities and Procedures

Prepared By NERC Data Exchange Working GroupVersion 2.1October 21, 2010

Document Revision Log

Revision #

Revision Date

Revision Description

Draft 1.0

March 6, 1998

Original Document Draft

Draft 1.1

May 19, 1998

Clarified some original draft wording prior to DEWG review.

Draft 1.2

June 1, 1998

Included comments from May DEWG review, filled in Background information, removed reference to Appendix A and added notification description for Control Area outages. Sent to DEWG for review.

Draft 1.3

July 9, 1998

Revised section on Management of ICCP Object IDs per DEWG input.

Draft 1.4

Sept 15, 1998

Wording revisions.

Version 1.0

May 5, 2000

Draft 1.4 plus two additional node outage notification items and notification process clarification.

Version 1.1

July 11, 2002

Added text regarding Data source considerations

and Deletion/replacement of data items.

Version 1.2

September 24, 2002

Fix the and problem introduced in version 1.1 by a French version of MS Word.

Fix the section problem by removing all sections except the main one.

Version 1.3

January 24, 2003

Rework to Notification Responsibilities Node Data Item Changes to clarify intended action and remove procedural specifics from document.

Version 1.4

August 4, 2005

Revise the section Notification Responsibilities Node Data Item Changes to amend the notification period from 2 to 4 weeks.

Version 2.0

July 15, 2010

Version 2 is a major rewrite of version 1.4.

Version 2.1

October 21, 2010

Version 2.1 addresses connection to both primary and backup NERCnet options.

Table of Contents

Background4

Security Responsibilities4

Data Handling4

Responsibilities4

Procedures5

Balancing Authority/Reliability Coordinator Requests to Obtain Data as Host ISN5

Management of ISN Data Definition Files and ICCP Object IDs5

Data Source Considerations6

ISN Node Outages6

Notification Process6

Planned Outages7

Notification Responsibilities Planned ISN Node Outages7

Notification Responsibilities Unplanned ISN Node Outages7

Notification Responsibilities Hosted Balancing Authority Outages

Notification Responsibilities ISN Node Software upgrades

Notification Responsibilities ISN Node Data Item Changes7

Performance Requirements7

Background

The Interregional Security Network (ISN)[footnoteRef:1] was established to facilitate the exchange of operational data between Reliability Coordinators (RCs), Transmission Operators (TOs), and Balancing Authorities (BAs) for the purpose of power system security analysis. This network is a collection of nodes which communicate over the ISN using the ICCP protocol to exchange power system related data. The bulk of this data is analog values (e.g., bus voltages, line flows, generator outputs, etc.) and status information (e.g., circuit breaker statuses, switch statuses, etc.). Each ISN node represents an assigned set of Reliability Coordinators, Transmission Operators, and Balancing Areas residing on the ISN in a hierarchical scheme. Balancing Authorities should normally communicate only with their assigned host ISN node and not directly with other ISN nodes and Reliability Coordinators/Transmission Operators/Balancing Authorities, on the ISN. However, separate direct links between entities outside of the ISN may be established for other purposes. [1: The ISN is also referred to as NERCnet.]

Reference Documents

Procedure to Request Data within the RC Region.pdf

Procedure to Delete Data by Provider.pdf

Procedure to Request Data outside the RC Region.pdf

Security Responsibilities

All ISN node operators shall be signatories to the current North American Electric Reliability Corporation Confidentiality Agreement for Electric System Reliability Data.[footnoteRef:2] All locations operating an ISN node shall employ all applicable standards and due diligence to protect the ISN telecommunications infrastructure from unauthorized use or access. This includes the use of all applicable NERC standards (http://www.nerc.com/page.php?cid=2|20), other applicable standards, and industry accepted practices. [2: The text of this agreement can be found at the following link: http://www.nerc.com/files/NERC-ORD-Version-3-BOT-approved-050609.doc

]

Data HandlingResponsibilities

The primary responsibility of an ISN node is to provide Reliability Coordinators, Transmission Operators and Balancing Authorities, for which it is serving as a host ISN node, a mechanism to acquire the operational data they need to perform the activities and meet the requirements described in the NERC reliability standards (http://www.nerc.com/page.php?cid=2|20). An ISN node also serves as a source of data for all other ISN nodes (and their associated Reliability Coordinators/Transmission Operators/Balancing Authorities) for the Balancing Authorities for which it acts as host ISN node.

Procedures

All ISN nodes shall employ the use of reliable hardware, software, and database maintenance procedures and controls to ensure the accuracy, security, and availability of the information it is required to provide. These procedures and controls shall also provide a mechanism to insure that all entities receiving data directly from the ISN are signatories of the NERC Confidentiality Agreement for Electric System Security Data.

Balancing Authority/Reliability Coordinator Requests to Obtain Data as Host ISN

Since an ISN node serves as a host for Balancing Areas and/or Reliability Coordinators, the ISN node administrator is expected to provide timely responses to all data related requests. When an ISN node receives a data request from another ISN node, the ISN node receiving the request shall provide a target date for when the data will be available within ten (10) business days of the request.

If there is a dispute between the requesting ISN node and the ISN node that owns the data (e.g., over issues such as the need for the data, resource requirements, etc.), the ISN node that owns the data shall promptly notify the requesting entity of this dispute citing the reasons for denying the request within ten (10) business days of the request. If the two parties cannot come to an agreement, the dispute should be communicated to the NERC Operating Reliability Subcommittee (ORS).

Management of ISN Data Definition Files and ICCP Object IDs

Balancing Authorities (Data Providers) shall create and maintain ISN Data Definition Files (DDFs). These files should show all analog points, status points and other data that can be exchanged on the ISN with other entities. The only exceptions should be market sensitive data, analog and status quantities that can be computed from other quantities by simple calculations (e.g., MVAs), and other analog and status points that are unrelated to power system operations.

Data Definition Files should be updated when one or more of the following conditions are met:

One (1) year has elapsed since the last DDF update and changes have occurred on the data owners system.

A major/significant change is made to the data owners available SCADA data (e.g., points germane to transmission operations are added, modified, and/or deleted in the data owners SCADA system due to changes on the transmission grid and for other reasons.)

Upon request from the data owners Reliability Coordinator (RC)

All new Data Definition Files should be validated prior to uploading them to the NERC https site. It is recommended that the latest version of the Data Definition File Validator program be used to do the validation.

Data Definition File(s) shall be submitted by the ISN Administrator for each data owner(s). NERC shall maintain the Data Definition File directory on the secure NERC https site so that all data definition file(s) subfolders reside under their respective Reliability Coordinator folders.

Data providers shall make all defined data value objects available upon request. In addition, Reliability Coordinators shall verify that the syntax of the ICCP Object IDs provided by its Transmission Operators/Balancing Authorities complies with valid naming conventions.

Data Source Considerations

It is very likely that a data item can be acquired from more than one ISN node. The Transmission Operator/Balancing Authority is considered to be the Data Provider for those points that it has published in the Data Definition File maintained on the NERC site and is considered to be the primary data source for those data items. Therefore, on the ISN, the designated host ISN node for a given Balancing Authority is considered to be the primary source for all data items coming from that Balancing Authority. All ISN nodes wishing to acquire data items via the ISN for their Reliability Coordinator and/or assigned Transmission Operators or Balancing Authorities should acquire the data from the primary ISN data source node. Other ISN nodes that have obtained the same data from the primary ISN node are considered to be secondary data sources for those items. The acquisition of data by ISN nodes from secondary data sources increases the potential for the daisy chaining of data paths. The use of secondary data sources is highly discouraged and should be avoided, to minimize time skew issues and to simplify trouble shooting.

There may be special circumstances where the use of a secondary source is required (e.g., an ICCP association with a primary ISN data source node is not yet active). In such cases all participants should be notified that a secondary source is being used and a primary source should be established as soon as is practical.

The concept of primary data sources should also be used in cases where data exchange participants have established data links outside of the ISN between themselves and other entities.

ISN Node OutagesNotification Process

The primary mechanism for the notification of planned and unplanned outages/restorations, and software/database changes shall be via an email message which uses a distribution list maintained by NERC. This distribution list will contain the email addresses of all individuals and entities that the Reliability Coordinators have designated. However, at a minimum, all entities that are receiving data from the ISN node performing the activity shall be notified.

Planned Outages

Each ISN Node Administrator shall, to the extent possible, consider power system conditions when scheduling and performing planned outages. Consideration should be given to transmission system loading, abnormal weather conditions, abnormal interchange activity, system alerts/emergencies, other ISN node outages, etc. Requests by any Reliability Coordinator, Transmission Operator, or Balancing Authority to delay or reschedule a planned outage of an ISN node should be accommodated to the fullest extent possible. The outage timeframe is defined as the duration in which good quality data is not being served to all sites.

Notification Responsibilities Planned ISN Node Outages

The ISN Node Administrator that wishes to have a planned data outage of their ISN node that is expected to last three (3) minutes or longer shall provide a preliminary outage schedule a minimum of one (1) business day, or as soon as practical, prior to the node outage.

Notification Responsibilities Unplanned ISN Node Outages

The personnel at an ISN node shall immediately notify all of the other ISN nodes when an unplanned outage occurs. For an extended outage exceeding thirty minutes, periodic status updates and the expected up time estimates should be provided to all of the ISN nodes via the notification process. Such notification shall occur as soon as practical after the outage condition has been discovered and the situation has been evaluated.

Notification Responsibilities ISN Node Data Item Changes

The ISN Node Administrator is responsible for notifying the other ISN nodes in advance regarding changes to existing data items including:

The deletion of data items

Changes in ICCP Object IDs for existing data items

Changes in the data items associated with a given ICCP Object IDs

The notification for such changes should occur twenty (20) business days prior to implementing the change(s) to allow time for those affected to update their systems. The notification should include the affected ICCP Object IDs and the date that the data item(s) should be considered as deleted.

Performance Requirements

ISN nodes shall provide sufficient hardware, software, telecommunications, and other resources necessary to ensure reliable, accurate, and timely data exchange as required by the NERC Reliability standards (http://www.nerc.com/page.php?cid=2|20). This includes connection to both primary and backup NERCnet options.

Data update frequencies and/or quantities, which exceed reasonable, defensible practices and/or which place the EMS or other related real-time systems at risk of failure or extreme performance degradation, are not required to be unconditionally accommodated. In such an event, the ISN node administrator experiencing the problem may request a review of the situation by the NERC Data Exchange Working Group.

6

Version 2.1Page October 21, 2010