Attachment 6
ISN Node
Responsibilities and Procedures
Prepared By NERC Data Exchange Working Group
Version 2.2
January 17,2011
Version 2.2
Page 1
January 17,2011
Document Revision Log
Revision #
Draft 1.0
Draft 1.1
Draft 1.2
Draft 1.3
Draft 1.4
Version 1.0
Version 1.1
Version 1.2
Version 1.3
Version 1.4
Version 2.0
Version 2.1
Version 2.2
Version 2.2
Revision Date
March 6, 1998
May 19, 1998
Revision Description
Original Document Draft
Clarified some original draft wording prior to DEWG
review.
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.
July 9, 1998
Revised section on Management of ICCP Object ID’s
per DEWG input.
Sept 15, 1998
Wording revisions.
May 5, 2000
Draft 1.4 plus two additional node outage notification
items and notification process clarification.
July 11, 2002
Added text regarding “Data source considerations”
and “Deletion/replacement of data items”.
September 24,
 Fix the « and “problem introduced in version 1.1 by
2002
a French version of MS Word.
 Fix the section problem by removing all sections
except the main one.
January 24, 2003 Rework to Notification Responsibilities – Node Data
Item Changes to clarify intended action and remove
procedural specifics from document.
August 4, 2005
Revise the section Notification Responsibilities – Node
Data Item Changes to amend the notification period
from 2 to 4 weeks.
July 15, 2010
Version 2 is a major rewrite of version 1.4.
October 21, 2010 Version 2.1 addresses connection to both primary and
backup NERCnet options.
January 17,2011 Version 2.2 changes DDF
Page 2
January 17,2011
Table of Contents
BACKGROUND ........................................................................................................................................... 4
SECURITY RESPONSIBILITIES ............................................................................................................. 4
DATA HANDLING ...................................................................................................................................... 4
RESPONSIBILITIES ....................................................................................................................................... 4
PROCEDURES .............................................................................................................................................. 5
BALANCING AUTHORITY/RELIABILITY COORDINATOR REQUESTS TO OBTAIN DATA AS HOST ISN ........... 5
MANAGEMENT OF ISN DATA DEFINITION FILES AND ICCP OBJECT IDS ................................................... 5
DATA SOURCE CONSIDERATIONS ............................................................................................................... 6
ISN NODE OUTAGES ................................................................................................................................. 6
NOTIFICATION PROCESS ............................................................................................................................. 6
PLANNED OUTAGES .................................................................................................................................... 6
NOTIFICATION RESPONSIBILITIES  PLANNED ISN NODE OUTAGES........................................................... 7
NOTIFICATION RESPONSIBILITIES  UNPLANNED ISN NODE OUTAGES ...................................................... 7
NOTIFICATION RESPONSIBILITIES  “HOSTED” BALANCING AUTHORITY OUTAGESERROR! BOOKMARK NOT
DEFINED.
NOTIFICATION RESPONSIBILITIES – ISN NODE SOFTWARE UPGRADES ERROR! BOOKMARK NOT DEFINED.
NOTIFICATION RESPONSIBILITIES – ISN NODE DATA ITEM CHANGES ........................................................ 7
PERFORMANCE REQUIREMENTS ....................................................................................................... 7
Version 2.2
Page 3
January 17,2011
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 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.
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 (http://www.nerc.com/page.php?cid=2|20),
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
(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
1
2
The ISN is also referred to as “NERCnet”.
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
Version 2.2
Page 4
January 17,2011
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:
 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 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
Version 2.2
Page 5
January 17,2011
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 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
Version 2.2
Page 6
January 17,2011
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.
Version 2.2
Page 7
January 17,2011