ISN Node
Responsibilities and Procedures
Prepared By NERC Data Exchange Working Group
Version 2.3
July 14, 2011
Document Revision Log
Revision # / Revision Date / Revision DescriptionDraft 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 ID’s 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.
Version 2.2 / January 17,2011 / Version 2.2 changes DDF
Version 2.3 / July 14,2011 / Version 2.3 changes to DDF submissions
Table of Contents
Background......
Security Responsibilities......
Data Handling......
Responsibilities......
Procedures......
Balancing Authority/Reliability Coordinator Requests to Obtain Data as Host ISN......
Management of ISN Data Definition Files and ICCP Object IDs......
Data Source Considerations......
ISN Node Outages......
Notification Process......
Planned Outages......
Notification Responsibilities Planned ISN Node Outages......
Notification Responsibilities Unplanned ISN Node Outages......
Notification Responsibilities “Hosted” Balancing Authority Outages......
Notification Responsibilities – ISN Node Software upgrades......
Notification Responsibilities – ISN Node Data Item Changes......
Performance Requirements......
Background
The Interregional Security Network (ISN)[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 ISNusing 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 maybe established for other purposes.
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.”[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 ( other applicable standards, and industry accepted practices.
Data Handling
Responsibilities
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 ( 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 employthe use of reliable hardware, software, and database maintenance procedures and controls to ensure the accuracy, security, and availabilityof the information it is required toprovide. 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 requestfrom 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 ISNData 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:
- Six (6) months have elapsed since the last DDF posting.
- Upon request from the data owner’s Reliability Coordinator (RC)
All new Data Definition Files should be complete data definition files. That is, they should not be “incremental” DDFs that show only the changes from the previous DDF. All Data Definition Files must be validated prior to uploading them to the NERC https site. It is requiredthat 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 shallmaintain 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 Authoritiescomplieswith 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 primarysource 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 Outages
Notification 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 nodeshall 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 nodesshall provide sufficient hardware, software, telecommunications, and other resources necessary to ensure reliable, accurate, and timely data exchange as required by the NERC Reliability standards ( 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.
1
Version 2.3Page July 14, 2011
[1]The ISN is also referred to as “NERCnet”.
[2] The text of this agreement can be found at the following link: