EE Recommended Practice for Implementing an IEC 61850 Based Substation Communications Protection Monitoring and Control System

IEEE Std 2030.100-2017 IEEE Recommended Practice for Implementing an IEC 61850-Based Substation Communications, Protection, Monitoring, and Control System

SAT

site acceptance test

SBO

select before operate

SCADA

supervisory control and data acquisition

SCD

system conguration description

SCL

Substation Conguration Language

SED

system exchange description

SFTP

Secure Shell le transfer protocol

SICS

SCL implementation conformance statement

SIPS

system integrity protection schemes

SNMP

simple network management protocol

SNTP

simple network time protocol

SSD

system specication description

SV

sample values

TCP/IP

transmission control protocol/Internet protocol

TICS

TISSUES Conformance Statement

TISSUES

technical issues

TLS

transport layer security

VLAN

virtual local area network

WAMPAC

wide area monitoring, protection, and control

XML

Extensible Markup Language

3. What IEC 61850 oers Unlike IEEE Std 1815™ [B63], the IEC 61850 standard is more than just a protocol specication. As a standard, it oers several protocols, project management, conformance testing, object models, conguration language, and environmental requirements, all composing a rich set of tools that could be used by substation design, protection, communications, and supervisory control and data acquisition (SCADA) engineers for the following: —

Implementing substation protection, automation, and control systems

— Conguring intelligent electronic devices (IEDs) —

Documenting asset management

—

Providing a common language to communicate between the various engineering groups

IEC 61850 currently has two editions representing a progression of the standard. Edition 1 is divided into ten major parts issued between 2003 and 2012. Since 2011, many of the parts are now in Edition 2, incorporating corrections for technical issues (TISSUES), additional logical nodes, and added functionality. Edition 2 expands IEC 61850 beyond the substation boundaries, expanding some parts, introducing new functionality through technical reports (those documents in the IEC 61850-90 series ([B40] through [B45]) in particular), and creating links with other standards. IEC plans to continue this development. Figure 1 shows some of the major functional areas in IEC 61850 and related standards, including a few areas that are currently being worked on.

13 Copyright © 2017 IEEE. All rights reserved. Authorized licensed use limited to: AALTO UNIVERSITY. Downloaded on March 02,2018 at 12:08:25 UTC from IEEE Xplore. Restrictions apply.


Reprinted with permission from POWER Engineers Inc., The Digital Power Grid Presentation, 2015.

Figure 1—IEC 61850 functional areas IEC 61850 covers many functional areas within the power grid. With many optional and mandatory requirements, the user must determine which parts will work best within their system and corporate structure and policies. This process is not addressed in IEC 61850. Essentially, the IEC 61850 standard addresses the following areas in order to achieve full interoperability and integration of the IEDs: —

Basics required for implementing the standard in IEDs

— Conguration of the devices/systems in use —

Communication protocols/standards used

—

File formats and data structure standards for information exchange

—

Conformity testing to establish successful implementation

The following services or functions are incorporated into the IEC 61850 standard: — SV multicast on the common local area network (LAN) (where Edition 2 provides a prole for a gigabit LAN physical interface) to transmit voltage and current measurements from the instrument transformers to the IEDs (typically process bus) — Transmission of trip/control/blocking and other critical signals to equipment through the common Ethernet LAN (typically station and process bus) — Buered/unbuered report client-server messaging for data exchange (typically station bus) — Time synchronization of the IEDs using simple network time protocol (SNTP), IEEE 1588 Precision Time Protocol (PTP) (Edition 2) [B58]



— Ethernet Link redundancy via rapid spanning tree protocol (RSTP), high-availability and seamless redundancy (HSR), and parallel redundancy protocol (PRP) for the LAN (the latter two by adopting IEC 62439-3 [B52]) —

Cybersecurity via normative and other references to the IEC 62351 [B47] standards

—

General requirements for hardware design, electromagnatic compatibility, operating temperature range, and shock and vibration withstand capability

— Standardized Extensible Markup Language (XML) le schema and well dened logical name sets enabling oine conguring IEDs and a standardized means to communicate between functional engineering groups — Manufacturing message specication (MMS) messaging with substation-wide direct polls or congured data sets in a client-server arrangement enabling easy conguration of general purpose human machine interfaces (HMIs) and data gateways data exchange — GOOSE messaging between IEDs enabling de-centralized implementation of substation inter-locking schemes, distributed synch-check for breaker closing, implementation of auto-reclose, and other highspeed schemes (protection or otherwise) —

Implementation of additional protection functionality such as busbar protection using simpler IEDs

Successful implementation of the IEC 61850 standard, other referenced standards, and additional mainstream features has shown the possibility of extending this standard to other areas such as distribution, renewable energy, power plants, and communication beyond the substation. With this in focus, the IEC 61850 standard is expanding to areas outside of the substation to achieve interoperability and integration of the entire power grid. The following lists a few of these areas contained within IEC 61850 and referenced by other standards: —

IEC 61850-7-410 [B29], [B30] provides data models for hydropower plant monitoring and control.

—

IEC 61850-7-420 (2009) [B31] provides additional data models required for incorporating distributed energy resources (DER) such as conventional devices, fuel cells, photovoltaics (PV), combined heat and power (CHP), and energy storage systems.

—

IEC 61850-7-510 [B32] uses already dened logical nodes (IEC 61850-7-410 [B29], [B30]), as well as other documents, in complex control functions installed in power plants, variable speed pumped storage power plants, etc.

— IEC 61850-80-1 uses the dened common data classes (CDC) in applications between substation(s) and control center(s) using the services of IEC 60870-5-104 [B6] or IEC 60870-5-101 [B5] standards. —

IEC 61850-90-1 [B40] provides a comprehensive overview of the dierent aspects that need to be considered for using IEC 61850 for applications between substations. In particular this denes the required information exchange, communication services/architecture, and enhancements of the conguration language, SCL.

—

IEC 61850-90-5 [B43] provides for the exchange of synchrophasor data (as dened in IEEE Std C37.118™ [B68]) within a WAMPAC (wide area monitoring, protection, and control) sytem for desired applications. This also provides routable proles for IEC 61850-8-1 GOOSE and IEC 61850-9-2 SV packets to enable applications between control centers.

—

IEC 61850-90-7 [B44] denes object models for power converters used in DER systems, including PV systems, battery storage systems, electric vehicle (EV) charging systems, etc. Focus has been on the information model to be used between the energy service provider (ESP) for supporting frequency and voltage control (P/Q control) through grid-connected DER systems.

—

IEC 62271-3 [B46] denes digital interfaces to the high-voltage switchgear and controlgear to be based on IEC 61850.

—

IEC 61400-25 [B8] provides communication between wind power plant components such as wind turbines, SCADA, etc. as per the client-server model dened and implemented via IEC 61850. 15 Copyright © 2017 IEEE. All rights reserved.

Authorized licensed use limited to: AALTO UNIVERSITY. Downloaded on March 02,2018 at 12:08:25 UTC from IEEE Xplore. Restrictions apply.


The IEC 61850 standard covers material that may not concern an end user tasked with implementing an IEC 61850 system using various vendor equipment and software. This guide will explore general concepts within the IEC 61850 standard that is focused on the end user. Some of the key focus areas are as follows: — Identies key elements of the standard that impact end user implementations —

Provides a general introduction to the concepts

— Oers some tips and suggestions These overviews are not intended to replace the standard. If a user requires a deeper understanding or access to denitions or data structure, they must reference the IEC 61850 standard directly.

3.1 IEC 61850 object model The IEC 61850 standard provides models for the substation protection, automation, and control system. These models are stored in an XML format that enables the exchange of information with other systems and devices. The standard denes a Substation Conguration Language (SCL) schema that allows any vendor conguration tool to read the IEC 61850 les created in a dierent vendor’s tool. An end user will generally not be concerned with the details of the XML schema called out in the standard but should be aware of the object modeling and naming part of the standard. Most engineers exposed to IEC 61850 have heard of the logical nodes and their dened data objects and attributes, but this is only part of the system model. The system object model has three basic parts: —

Substation

—

Product

—

Communications

A user conguring their IEC 61850 system using a SCL conguration tool will nd themselves exposed to dierent concepts than they may be accustomed to for modeling their substation. Using this standard model creates the links between the substation’s electrical circuit conguration, the equipment and the physical devices, logical devices, and logical nodes. In addition, a link is also created from the communications network back to the logical node. If a user does not use this model they will require some other means of documenting these links. The following diagram in Figure 2 gives a general view on how all the various pieces of information from the SCL model are linked and how the information is transmitted to other devices. The diagram also shows how the three parts of the SCL models are linked together in such a way that information from one part is associated with information from another part.




Figure 2—IEC 61850 SCL model

Figure 3, Figure 4, and Figure 5 show the three dierent sections of the SCL model as individual views. Each of the substation, IED, and communications sections has links between the others. The substation model is in hierarchical order as shown in Figure 3. It contains the following substation objects: —

Substation

—

Voltage Level

—

Bay

—

Equipment

—

Sub-Equipment

—

Connectivity Node

—

Terminal

—

Function

—

Sub-Function




Figure 3—IEC 61850 SCL model: substation

The product model is in hierarchical order as shown in Figure 4. It contains the following product objects: —

IED

—

Server

—

Logical Device

—

Logical Node

—

Data Object



Figure 4 also shows the components that make up a data object and some of the various means of exchanging real-time information.


Figure 4—IEC 61850 SCL model: IED

The communications model shown in Figure 5 is not a hierarchical model. It contains the following communications objects: — Sub-network —

Access Point

—

Router

— Clock




Figure 5—IEC 61850 SCL model: communications

The IEC 61850 standard does not require a user to use this complete model. The user could choose to implement only the parts of the model that support their needs. The user should determine the vendor IED and tool support for the various models to determine if they will support the planned implementation.

3.1.1 Substation part The substation part of the model is an electrical single line circuit linking substation equipment, such as breakers, switches, transformers, and buses, to show the electrical connection between them. The user will quickly nd out that there are hierarchical rules and naming conventions on how objects are named and how they relate to each other. This modeling and naming convention follows both the IEC 81346-1 [B53] and IEC 81346-2 [B54] standards, referenced in the IEC 61850 standard. The user rst starts at the highest level objects modeling the substation, voltage levels, and bays; and then within the bays the single line objects can reside. The lowest linked object is the logical node that provides the linking between the substation part of the model and the product part of the model. With the objects arranged in hierarchical order, the naming convention for an object’s name will include the higher order object names. If Bay Q2 is within the voltage levels of 132 kV, which is E1 in the standard, then the proper name for the Bay is E1Q2. This same naming convention follows down to the lowest element so that it can be associated to the highest object. Understanding this model is similar to learning a dierent language; exact voltage levels are not called out, only the coded name for the range. Bay names do not identify the bus, feeder, or transformer by a descriptive name. So, in general, the substation part of the model links the electrical topology of the substation and its components with the logical nodes.



3.1.2 Product part The product section of the model is linked to the other parts of the model and shows the details of the IEDs used and their logical node implementations. An IEC 61850 IED is the physical device that will have a server within it to allow for IEC 61850 type communications. Within the server the vendor will create one or more logical devices whose names are generally xed by the vendor. Under the logical devices are the logical nodes that represent a set function per the standard, with the standard also allowing for custom logical node creation. Contained within the logical nodes are the data objects and the data attributes. So, by using the SCL model, a single data point is linked to the highest object using the substation section relationship if viewed by a SCL software tool.

3.1.3 Communications part The communications section is also linked to the other parts of the model, having communication related objects such as sub-networks, server, router, and access points linked to the IED. Unlike the previous two SCL parts, this part is not a hierarchical model. It is also not a physical connection model but a logical one. A subnetwork is a connection between access points, not a means of describing the physical Ethernet network setup. An access point is a communication gateway to a logical device and does not represent a physical network card on the device. A router in the model does not represent a normal network router but is an object within an IED that shows a link between two dierent IEC 61850 sub-networks. As an example, a logical node within an IED’s server and logical device may exchange data between other logical nodes whose access points are on the station bus sub-network and the process bus sub-network. The router object shows that the device logical nodes are getting or providing data to other logical nodes on both sub-networks. The communication section also shows the user how the master clock is connected to the various devices to synchronize time. If the user uses the SCL model they rst must identify the software they wish to use to start their IEC 61850 conguration. Then there are steps to read the IED capabilities description (ICD) les from the devices and complete some vendor specic conguration using the vendor tools, which create a congured IED description (CID) le on the device. If a user wishes to subscribe to other devices’ published GOOSE messages or SV messages, the vendor’s conguration software will ask you for that device’s IEC 61850 conguration le, which has all the setup information for the published messages. The user then builds the substation structure linking equipment to logical nodes and the communications structure linking logical devices to sub-networks. Completing these tasks will provide a complete information path to understand which part of the substation has a communications link. After the various exchanges of information and user’s conguration, all of the system information described under the SCL model will be stored in a standard XML scheme, which is viewed and changed by any compliant IEC 61850 tool.

3.1.4 SCL information exchange les The user will nd a number of dierent named les dened in the IEC 61850 standard that all contain specic information using standard IEC 61850-dened XML schemas. Depending on the level at which the user implements the SCL model, the user may not see a number of these le types. Table 1 includes a description of their intended use and the IEC 61850 edition with which they are associated.

Table 1—XML le descriptions File

Description

Edition 1

Edition 2

ICD

This is an IED Capabilities Description (ICD) le provided from the vendor as a template to show the user all the IEC 61850 capabilities of the device.

Yes

Yes

IID

This is an Instantiated IED Description (IID) le that provides information about a congured IEC 61850 device to an IEC 6 1850 System Conguration Tool.

No

Yes

CID

This is a Congured IED Description (CID) le that exchanges conguration information between the device and the vendor IED conguration tool.

Yes

Yes Table continues



Table 1—XML le descriptions (continued) File

Description

Edition 1

Edition 2

SSD

This is a System Specication Description (SSD) le that exchanges information between the System Specication Tool and the System Conguration Tool.

Yes

Yes

SCD

This is a System Conguration Description (SCD) le that exchanges information between the System Conguration Tool and the Vendor IED Congurator Tool.

Yes

Yes

SED

This is a System Exchange Description (SED) le that exchanges information between the System Conguration Tool and other IEC 61850 projects.

No

Yes

Figure 6 provides a general overview on how the dierent le types are used in a complete IEC 61850 system.


Figure 6—SCL model le transfer

The standard does not layout a conguration procedure that must be followed. The standard oers a set of les with a suggested use, where the user determines the tools based on their specication to the vendor. An IEC 61850 conguration could be as simple as using each vendor’s conguration software for each device, loading the individual CID les into that conguration in order to subscribe to new messages.

3.1.5 Logical nodes Logical nodes are the functional objects in the SCL model that contain the data. They are grouped under functional areas that are represented by the rst letter in their main four letter name. For example: —

Pccc is in the Protection Functional Group

—

Xccc is in Switchgear

—

Tccc is in Instrument Transformer and Sensors



The remaining three letters represent a specic function within the group such as: —

PTOC is Protection Time Overcurrent

— XCBR is a Circuit Breaker —

TVTR is a Voltage Transformer

The four letter logical node name is xed by the standard and has an index number at the end of the four letter name to separate dierent data denitions within the specic function such as PTOC01, PTOC02, … PTOC99. There is also an optional prex that could be applied to the four letter LN name to give the LN name additional meaning such as adding a “pha” prex to “PTOC01”. This prex would indicate that the PTOC (Protection Time Overcurrent) LN is for the phase A part of the circuit. Having a prex for the LN is optional in the IEC 61850 standard and there are no guidelines for their naming or use. If there is a prex, in most cases the vendor will supply the IED with a xed prex name for the logical node and not allow the user to change it. Within the logical node are the data objects and, if viewed by an IEC 61850 browser, the user sees the hierarchical structure of the logical node. Data objects are grouped under Functional Constraint which indicates the type of services that are used, such as ST for Status Information, CF for Conguration, etc. The data object name follows semantics, which are dened in IEC 61850-7-4 [B27], [B28], giving the user the denition of the name. Also assigned to the data object under the logical node is the Common Data Class, which denes the structure of the data object, such as INS is Integer Status or MV is Measured Value. Under the data object are the data attributes, which also follow semantics, and gives the user additional information on what the data is. The data attribute is the lowest part of the logical node data structure and is the place where real-time information is accessed. There is nothing in the standard forcing a vendor to implement a set of logical nodes in an IED. Generally, the vendor will create xed logical devices that have the logical nodes the vendor chooses to implement within them. There is nothing in the standard that forces a vendor to oer a logical node that denes a function supported by the IED. For Edition 1 IEDs, in place of using the IEC 61850 dened logical node the vendor could use generic input/output (GGIO), which is a generic logical node. Edition 2 corrected this by requiring the vendor to use the logical node dened in the standard rather than implementing the same function in GGIO. Figure 7 shows the structure of the logical node and the connection in the SCL model to the device. The diagram also calls out the levels that are mandatory or optional and allows for creating custom elements not found in the standard.




Figure 7—Logical node SCL structure

The following list contains a few things the user should be aware of when using the logical nodes: — Logical node denitions only describe a high level function and do not specify the exact meaning of the data objects for each index of the logical nodes. This means that the same index of a logical node between vendors may have dierent data object meanings. — IEC 61850 denes the structure and format for the logical nodes and allows users of the standard to create their own logical nodes. Vendors can create a logical node that is not dened in the standard but follows all the rules laid out in the standard. In this case, the user will require the vendor’s documentation to understand what information is contained within this logical node. This situation also makes it dicult in a multi-vendor enviroment when the end user is trying to harmonize the logical nodes between the various vendor IEDs. Edition 2 has placed a number of restrictions on creating logical nodes not dened in Edition 1. — Vendors may x the internal device-tag/data-point association to the logical node data object or allow the end user to select from various internal data points to assign them to a logical node data object. The user should ask if the vendor’s conguration software allows for user mapping of data objects to internal device points. Examples are: — Which internal point drives local/remote functions or the blocking functions? — Are these points xed by the vendor or programmable by the user?



— The standard allows for a prex to be attached to the four letter logical node name, which is followed by an index number. Only the prex part of the name can be modied. A vendor may x this prex part to something they determine or allow the end user to modify it to something they want. —

The user should use an IEC 61850 browser to see what logical nodes and data objects within the logical node are available, but will only have a general idea of what the data objects represent within the device. Vendors will provide documentation to cross reference the logical node name and data objects with internal data points within their device. This documentation may or may not provide the additional IEC 61850 data attribute information that the user will require to understand the format of the data and the meaning of the various states. In the latter case, the user will need to have a copy of the IEC 61850 standard section that covers this information. In addition, the user should check the vendor’s equipment and software documentation to determine if all the information is supplied to understand the exact function of the logical nodes data object.

— The standard identies most of the data objects within a logical node as optional, with a few listed as mandatory. During the vendor selection process, determine which data objects are avaliable and how a required function would be implemented where the data object is not available — Local/Remote—Is the data attribute link to the internal device point that drives this function xed by the vendor or is it user selectable? —

The user should be aware of additional logical nodes and changes to data within pre-existing logical nodes introduced when the IEC 61850 Edition 2 was released.

— The logical node naming rules are dierent between Edition 1 and Edition 2. This, among other issues, will cause problems between Edition 1 clients and Edition 2 servers, but should not be a problem with Edition 2 clients and Edition 1 servers.

3.1.6 General considerations The user may not have to be concerned with the object modeling part of the standard and may choose not to use it. Other IEC 61850 parts could be used following the vendor’s congurations directions without creating a complete system model. The following is a list of things to consider: —

Modeling a substation using the complete SCL model is only necessary if there is a desire to be fully compliant with the IEC 61850 standard. It is not required to make other parts of the standard work.

— For Edition 1, most IEC 61850 vendor device conguration tools only require the other IED’s ICD, IID, or CID le to subscribe to GOOSE and SV messages, not the complete system model les. Therefore, a user is not required, in most cases, to complete a full IEC 61850 system model using an IEC 61850 system conguration tool. In this case, the user rst uses a vendor tool to congure the GOOSE/SV publisher and then the ICD/IID/CID le is imported into the vendor tool of the subscriber. —

If it is desired to use the complete SCL model: •

Determine how a vendor’s SCL conguration tool handles custom logical nodes, data objects, and data attributes.

•

Investigate how the vendor’s product presents the XML through a visual interface rather than just creating the correct schema with a le output. Having a good visual view of the connections and associations will provide a clearer understanding of how the system works. Details on what a vendor has to provide within the system tool is limited in the standard to only having the proper XML schema. How the information is presented to the user is not covered.

•

The SCL model you create will not replace your traditional single line diagrams, which provide a level of detail not covered in the standard. If a vendor or integrator is providing a complete IEC 61850 system using an SCL tool, make sure the license for its use is included in your deliverable along with all the system les.



•

It is not required to follow the IEC 61850 naming convention for higher level objects, such as the substation or voltage level or IED name. Most vendors allow the users to input their own names even though it does not follow the standard. Most system tools will rst default to the standard naming convention but allow the name to be changed. As discussed in 3.1.5, the four letter logical node name is xed by the standard and only the prex to this name can be modied if allowed by the vendor’s IED conguration software.

3.2 Ethernet network Use of IEC 61850 requires an Ethernet network in the substation for communications between devices, and to the control center, as covered in IEC 61850-90-2 [B41]. The IEC 61850 standard also covers Ethernet network communications between substations based upon IEC 61850-90-1 [B40]. This section only addresses the Ethernet network communication within the local substation. Here, the network conguration can be as simple or complex as required to meet the requirements of the functions implemented. IEC 61850-90-4 [B42] provides guidance on LANs supporting IEC 61850. Ethernet LANs can be designed and built with varying degrees of performance and reliability depending on the requirements of the supported applications. The Ethernet LAN can be segmented to satisfy the various requirements within dierent sections of the LAN. Dierent sections of the LAN can also be built with dierent speeds and often with dierent types of media; either copper or optical ber cable. Some examples of applications with varying LAN requirements are as follows: —

If only using IEC 61850 for general SCADA information, a non-redundant, simple Ethernet LAN may be all that is required.

— If the system supports GOOSE messaging carrying protection trip and blocking signals as per IEC 61850-8-1 [B33], [B34], a more reliable Ethernet LAN design may be required that reduces latency and provides network redundancy. One factor that should impact this analysis is whether there is a completely redundant protection, automation, and control system or not. Transmission substations typically have a “protection A” and “protection B,” sometimes completely separated and redundant so that no common failure mode will cause both systems to fail. In distribution substations, simpler protection, automation, and control systems are more common, resulting in limited to no redundancy in the event of a network failure causing communications failure. —

If the system supports SV per IEC 61850-9-2 [B35], [B36], the physical instrument transformer connections to the protection relays that digitize the waveform signals are now digital messages transmitted over a LAN connection. Merging units, which digitize the analog waveforms, can be built into the instrument transformer or other substation equipment. For this level of implementation, the protection and control systems may not function properly if there is a LAN failure or the LAN does not provide the data when it is required. For this type of application, a network design may be required that is redundant, with high throughput and low latency, along with precision time synchronization via PTP (to avoid a separate timing wire from the control house or additional satellite clocks installed in the substation equipment).

3.2.1 Network design The IEC 61850 standard introduces the following two separate bus types in the substation LAN: — The Station Bus provides the network connectivity for messages between bays and bays to gateways or station level IEDs, such as an HMI, protection relays, meters, and data concentrator. — The Process Bus provides network connectivity between the IEDs within the bays. The merging units provide the hardwired interface to the station equipment.



There can be a number of physically separated LANs at the process level, which in some cases are conned to bays. The LAN conguration specied in IEC 61850 uses the IEEE 802.1Q Virtual LAN (VLAN) and IEEE 802.1p priority tagged message.

3.2.1.1 Physical layer design IEC 61850 species the physical layer connection options as ber and copper. The dierences and possible use cases are described in IEC 61850-90-4 [B42], but there are no requirements for the cables actually being used. IEEE Std 525™ [B55] provides some guidance as to communication cable types, with a new revision that may provide even more guidance. Fiber optic cables may also require patch panels when running to equipment out in the eld, which introduces additional failure points for the ber optic cable (additional losses are also introduced, but in a substation should be negligible compared to the available optical budget). IEC 61850-904 [B42] advises that copper cable is for shorter distances of less than 100 m and, due to its susceptibility to electromagnetic interference (EMI), it should only be used in the substation when galvanic separation is not required. Similar guidance can also be found in IEEE Std 1615™ [B61]. In addition to no cable specication, there is also no specication for cable pathways such as cable tray, cable trough, and conduit. IEEE Std 525 [B55] may provide some guidance on these issues.

3.2.1.2 Network speed design While IEC 61850 species network speeds (Edition 2 of IEC 61850 does include an option for a gigabit ber interface, but the availability of this in devices has been slow to date), it does not specify what network speed or bandwidth is required for dierent applications. IEC 61850-90-4 [B42] describes scenarios when a 100 Mbps Ethernet versus a gigabit network could be used. GOOSE and SV use layer 2 multicast messaging and to reduce network trac, ltering needs to be done at the Ethernet switches such that the multicast trac reaches only those links where subscribing IEDs are located to meet the performance requirements specied. Gigabit ports for process bus on bus protection relays may also be required to reduce the latency and trac congestion.

3.2.1.3 Network topology design Another issue with network design is what type of network topology is best implemented. Ultimately, this will depend upon the performance requirements for the applications running over the network. Care must be taken to reduce the network switch hops that may increase response time, making it impossible for the network to meet the performance requirements. This issue is somewhat addressed in IEC 61850-90-4 [B42], but it only considers packet queuing as the source of packet delay. Packet queuing due to network congestion can cause delays and dropped packets. Another source of packet delay that occurs on a network is the time it takes for a packet to traverse through the Ethernet switch due to the “store and forward” nature of these device. Network “size,” or number of hops, should be limited to the number of hops required to meet the network performance requirements. In addition, connections between Ethernet switches may be problematic at 100 Mbps because they may be passing trac from many network edge devices. For this reason the connections between Ethernet switches (uplinks) or network backbone may need to be upgraded to at least 1 Gbps to increase the available bandwidth and avoid any issues. As gigabit Ethernet becomes more common in IEDs, the network backbone may require an upgrade to 10 Gb Ethernet depending on the anticipated trac.

3.2.1.4 Network environmental design IEC 61850-3 [B13], [B14] includes environmental requirements that Ethernet switches should be required to meet. The network is only as strong as its weakest link. This also includes the cables, connectors, and patch panels. IEC 61850-3 Edition 1 [B13] species operation in extreme temperature and EMI conditions. Edition 2 [B14], however, expands these requirements signicantly, including the error free requirements from



IEEE Std 1613™ [B59]. This error-free operation during transient events is recommended when using GOOSE and SV messages. The error free operation can only be covered in Edition 1 by specifying IEEE Std 1613 [B59] class 2 performance in the network infrastructure, which will also meet IEC 61850-3 requirements. Error free operation is possible with Edition 2 of IEC 61850-3 [B14] because it incorporates the performance tests from IEEE Std 1613 [B59].

3.2.1.5 Network LAN redundancy Another important LAN consideration is redundancy. Originally, IEC 61850 included no specic mechanism for link redundancy, so any implementation of link redundancy via spanning tree protocol, RSTP, IEEE Std 802.1w [B56], or any other protocol was not implementing IEC 61850. This changed in 2011, when IEC 61850-8-1:2011 [B34] added the following link redundancy protocols as optional: — IEC 62439-1 RSTP. RSTP supports relatively fast network topology re-convergence, allowing a network to have redundant links between network elements, one link as blocking (not forwarding messages) and the other link forwarding. When these redundant links use alternate paths, they are not subject to many common failure modes. Therefore, when a cable or switch fails, the network elements use the protocol to quickly reconverge on a new topology. RSTP is the most common protocol supported in almost all network switches and allows for ring, mesh, or tree type architectures. An RSTP network allows for redundant network paths with automatic failover that is very fast (typically less than 5 ms per hop), but it does have a recovery time and it is possible to drop packets during this time. —

IEC 62439-3:2016 Clause 4 Parallel Redundancy Protocol (PRP). PRP is two independent LANs that have the IEDs connected to both through specialized PRP-enabled network interface controllers (NICs). PRP provides the highest level of performance with zero recovery time from a single point of failure, but it is also the most costly to deploy.

—

IEC 62439-3:2016 Clause 5 High availability Seamless Redundancy (HSR). The HSR is mostly used as a ber ring where each device has two HSR aware congured ber ports. HSR also provides zero recovery time from a single point of failure, but it does not have the same scalability or bandwidth as RSTP or PRP.

Both PRP and HSR solutions require IEDs, such as a protection relay, to support these protocol stacks. If the IEDs do not natively support PRP or HSR, then the user must provide a front end box known as a redundancy box (Redbox) with the PRP/HSR protocol stack interface on the PRP and HSR LAN side, and normal single port connection for the IED. It is possible to construct a LAN that supports both PRP and HSR. Proper application of any redundancy mechanism should be considered in the network design prior to the rst implementation. It may be acceptable to use RSTP when only using IEC 61850 for SCADA data reporting. For GOOSE and SV, use of RSTP is a minimum requirement and may require the use of proprietary enhancements from vendors to improve failover time to acceptable performance levels. Use of PRP and HSR may become the de facto approach for systems using GOOSE and/or SV.

3.2.1.6 General considerations When performing the network design, the following should be considered before the rst implementation: — Optical ber is required to obtain the performance of GOOSE and process bus under the demanding substation environment dened by IEC 61850-3 (Edition 1 [B13] or Edition 2 [B14]) and/or IEEE Std 1613 [B59]. Conformance means IEDs are purpose-built for substation transients and environmental conditions and can provide the required communication performance during transients for critical communications such as GOOSE and SV messaging.



— Given that the network is now in the critial path of the protection, automation, and control system, choosing the right network hardware, cables, and connectors is essential for the application to function properly under the expected environmental conditions under which the IEDs are conformance tested. Everything connected to the LAN, hardware, cables, and connectors should all meet the same environmental requirements. The coldest or hottest day in years is not the day to realize that the common mode of failure for your network is in the cabling. Proper selection during design will prevent this situation from ever developing. — The network design and conguration should go through the same review procedures as applied to protection settings, because network design and conguration can adversely impact the response time of the protection and control functions. It is likely that the design and conguration will change as the network is tested to see if it meets the performance requirements. — Network redundancy protocols aect how the network behaves under failure modes, such as cable or switch failure, and the available protocols provide dierent levels of performance. It is important during the design phase to select the right level of redundancy protection for the application and section of the network. Testing of the failure modes to the desired performance is essential prior to the rst implementation. — Vendors oer many products that have dual Ethernet connection points but how these connections can be used will dier. It is important to review that the IED implementation is compatible with the network switches and overall architecture. It is essential this occurs prior to the rst implementation. — Precision Timing – If the network will include PTP time synchronization, the Ethernet switches need to support packet hardware time-stamping and transparent clock mode, depending upon the application requirements. Testing that the network timing system will perform as expected under all conditions, including failure modes, is essential prior to the rst implementation.

3.3 Protocols This section discusses many of the protocols contained within IEC 61850. Not all protocols are supported by all IEDs. For example, some IEDs may not support GOOSE but support others, and other IEDs may only support GOOSE.

3.3.1 GOOSE GOOSE messages are layer 2 messages dened in IEC 61850-8-1 [B33], [B34], using a multicast media access control (MAC) address over the Ethernet and are published by and subscribed to by IEDs. The messages use VLAN and priority tagging and have a retransmission scheme. GOOSE messages use data sets to publish information congured by the user. The data set information contained within an IEC 61850 GOOSE message can have any type of IEC 61850 data, including status and analog values. This message type is mainly used to transfer small amounts of time sensitive data from one IED to one or more IEDs. While typically associated with protection applications, GOOSE messages can be used for any application exhibiting time sensitivity. Figure 8 gives a general overview of the process involved in publishing and subscribing a GOOSE message. The diagram covers the message transmission functions and shows the MMS optional interface to the GOOSE control block parameters.




Figure 8—GOOSE message process

The following is a list of things to consider when implementing GOOSE messaging: — Check each IED’s limits on the number of allowed published and subscribed messages to determine if the selected IEDs meet your systems requirements. — Check the number of GOOSE control and input variables available for use within your device logic applications. Edition 2 provides two mandatory logical nodes for GOOSE monitoring. — Obtain the certication test results conrming that an IED is able to process a GOOSE message within a response time that will meet your requirements. —

Determine how a vendor is using the functions, such as the test bit in Edition 1 or the simulation bit in Edition 2, for their GOOSE implementation.

— Look into how a vendor maps data into a GOOSE data set. Are intermediate GGIO points used or can data be directly mapped from the data sources? —

Obtain documentation from the vendor that describes how time stamps are applied to both the GOOSE message and the internal points that are used to transfer the information to the IED for use.

3.3.2 Sampled values (SV) Similar to a GOOSE message, a SV message is published and subscribed using a multicast or broadcast MAC address over the Ethernet LAN. The SV diers from the GOOSE in that the SV uses periodic messages with a specied periodicity that never changes. These messages also use the VLAN and priority tagging, which must be properly congured in the network to help with a reliable delivery of the message. Using SV is a challenging design shift from traditional hardware connections. Before a protection relay can issue a trip it must have a good waveform to analyze. The IEC 61850 concept for using SV converts the traditional protection relay into a computer with only a redundant Ethernet port to exchange information with the substation. These messages have data sets that are dened in the standard with various ranges open to vendors, such as sample



rate and content. This does not always provide interoperability with another vendor’s equipment. As covered in the network section, SV messages are typically used on the process level LAN and are mostly segmented into separate bay level process LANs to ensure bandwidth and quality delivery of this message type. This ultimately depends upon the substation conguration and corresponding network design. Figure 9 gives a general overview of the process involved in publishing and subscribing a SV message. The diagram covers the message transmission functions and shows the MMS interface to the SV control block parameters. This message diers from the GOOSE message in how it transmits the information. It is a continuous stream of synchronized sampled values.


Figure 9—SV message process

The following is a list of things to consider when implementing SV messaging: —

Given the importance of the sampled values properly getting to each protection relay, redundancy in instrument transformers and/or merging units may be a consideration.

— It is very important to have the correct network design when using SV messages. They can use a good portion of network bandwidth, not only based upon the number of merging units publishing data and where the subscribers are located on the network, but also if the number of published messages is not limited or the network design does not account for loading. — Data set content and sample rates for the waveform data is not xed in the standard, so subscribers must be compatible with publishers and vice versa. —

Traditional protection secondary testing tools cannot be used because there are no longer any instrument transformers and no low voltage injection is possible at the IED. Testing equipment must be updated to include IEC 61850 SV output modules. Again, these devices must be able to mimic the installed publishers.

—

Handling of failure modes, such as a short loss in communications or a loss of time synchronization, is not covered in IEC 61850. It is important to understand how each IED deals with all failure modes resulting in the loss of SV messages and corresponding values.



3.3.3 MMS (manufacturing message specication) MMS existed well before IEC 61850 and was chosen as the application protocol for logical node data, control commands, control block data, reports, les, and logs. Under normal conditions, understanding the structures or mechanisms used by MMS to transfer information is not necessary. Network sniers that understand and decode MMS can be used to display MMS messages. Under failure modes or communication troubles, a more developed understanding may be required. IEC 61850 has two methods for clients to retrieve data from an IEC 61850 server. One is direct data polling where the client connects to the logical device and then issues individual get data commands to a specic data address. The second is a client-server connection to a report within a logical device that contains a data set that can be xed by the vendor or generally user congurable. There are two types of reports, buered and unbuered. Buered reports contain all transitions of the changed data since the last report, which is somewhat similar to IEEE 1815 (DNP3) report by exception and/or event reporting. Unbuered reports will only have a current value of the data during the read, similar to IEEE 1815 (DNP3) class 0 polls. A report control block may be congurable in each IED, setting the event handling characteristics of the report. Logs are used in an IEC 61850 device to store all events into virtual storage that is retrieved or accessed by a client application. Unlike reports, no other actions are taken to alert a client to a change. Figure 10 shows an overview of the data ow and control for both the report and log MMS functions.


Figure 10—MMS report and log data ow

3.3.3.1 Direct data access Direct data polling using IEC 61850 MMS is not the preferred method for retrieving data and is generally used only if the data object cannot be found in a report or the user is accessing control block data. Using this method typically creates a large round robin poll where each point is individually polled for its current value.



A control message is a direct MMS message type that performs control actions from the client to the server. Control messages can be delivered using one of four types, direct with normal security, select before operate (SBO) with normal security, SBO with enhanced security, and direct with enhanced security.

3.3.3.2 Reports The IEC 61850 MMS report is a very eective means to pass information from the IED (server) to a client, such as a data gateway or HMI. The report control block allows for dierent methods of retrieving data such as an integrity poll, data change, quality change, etc. A data set may be congured by the user and assigned to the report that allows for grouping the information and only providing what is required by the client. Some vendors only support pre-congured reports that cannot be changed, similar to vendors who provide one IEEE 1815 (DNP3) server point map that cannot be changed.

3.3.3.3 Logs IEC 61850 species logs, which are similar to reports, but do not provide all the trigger options that report changed data. The logs are used to allow the user to access log type data such as event logs, device access logs, etc.

3.3.3.4 File transfer IEC 61850 species MMS le services as a method to transfer les from the IEC 61850 device. Additionally, many devices support optional le transfer protocol (FTP) and Secure Shell le transfer protocol (SFTP) services for le transfer.

3.3.3.5 General considerations The following is a list of things to consider when implementing MMS messaging: —

An IEC 61850 browser is recommended so the user can poll devices directly using MMS and retrieve the device data structure. This allows the user to become more familiar with MMS and the device models that may be dicult to visualize in vendors’ tools or documentation.

—

IEC 61850 browsers generally also allow for write commands. Always determine if an IED client can write data points in an IED versus what can only be changed through the vendor specic conguration software.

— IEDs will have dierent restrictions on how many report client connections can simutaniously be connected. —

Some IEDs may allow report names to be changed, adding new reports, changing data sets, and assigning data sets to reports; others do not.

— A buered report will only allow for single client connections. An un-buered report can allow for multiple client connections to the same report. —

Some IEC 61850 clients use direct data polling, reports, or both methods to extract information from servers. Some IEC 61850 clients are very simple and support only reports, which may not be congurable and not include the required data that is otherwise available in a supported logical node.

— Some IED server’s MMS report conguration requires special control ag settings to be accomplished before a report connection is made. — Determine if the IED supports 61850 le transfer mechanism. For example, if a client needs a le and only supports MMS le transfer, while the server only supports FTP or SFTP le transfer, no les will be transferred.



3.3.4 Control blocks Each of the IEC 61850 protocol functions – MMS Reports, MMS Logs, GOOSE, Settings Groups, and SV – has an associated control block. The data attributes in the control block can be accessed and, in some cases, controlled using MMS direct read/write messages. Information in these control blocks are used to establish how the connection is congured and, if allowed by the vendor, change the control block parameters using MMS. The IEC 61850 standard also denes a setting group control block that will allow the user to change various setting parameters within a logical node or nodes using MMS commands. This is an optional function; the user should check with their vendor for functional information or include it in their specication.

3.4 Time synchronization There are four time synchronization methods listed in Edition 2 of the IEC 61850 standard: 1 pulse per second (PPS), inter-range instrumentation group (IRIG)-B, SNTP, and PTP. Clause 6.4.2 of IEC 61850-8-1:2011 [B34] mandates the use of SNTP (refer to Table 9 in IEC 61850-8-1:2011). The standard does not provide a guide for its design and implementation in an IEC 61850 system. Other time synchronization mechanisms might additionally be needed to meet high-accuracy requirements. When implementing time synchronization, the user should understand that: — Using an Ethernet-based time protocol may require network equipment that supports it with proper network design and conguration. —

Identifying how all IEDs handle time synchronization is critical in a successful design, leading to a successful implementation.

— Understanding how all IEDs report their time synchronization status is also key to successful implementation, so the timing quality is known. —

Some IEDs support one or more methods of time synchronization, others much fewer, and still others only one.

— The selection of a satellite clock that can provide adequate outputs may be another key part of the design process when multiple time synchronization methods are required.

3.5 Data transfer performance measures IEC 61850-5 [B17], [B18] goes into great detail in dening seven message types, PICOM (piece of information for communication), and corresponding transfer time requirements. Edition 2 introduces transfer time classes and makes some changes to Edition 1 as shown in Table 2.

Table 2—Message performance requirements Message Description

Trip and perhaps interlocking, intertrips and logic discrimination between protection functions.

Edition 1

Edition 2

Type

Performance Class

Transmission Time

Type

Transmission Time

Performance Class

1A

P1

10 ms

1A

5 ms for 50 Hz P1 4 ms for 60 Hz

TT6, ≤ 3 ms

P2/3

3 ms

10 ms for 50 Hz 8 ms for 60 Hz

TT5, ≤ 10 ms

P2

Transfer Time

Table continues



Table 2—Message performance requirements (continued) Message Description

Edition 1

Edition 2

Type

Performance Class

Transmission Time

All other fast messages are important for the interaction of the automation system with the process but have less demanding requirements compared to the “trip.”

1B

P1

≤ 100 ms

P2/P3

≤ 20 ms

Automatics, where the time at which the message originated is important but where the transmission time is less critical.

2

≤ 100 ms

2

Operator messages for slow speed autocontrol functions, transmission of event records, reading or changing set-point values, and general presentation of system data.

3

≤ 500 ms

3

half the operator response time of ≥ 1 s regarding event and response (bidirectional)

3

in line with the P6 operator response time of ≥ 1 s regarding unidirectional event

TT1, ≤ 1000 ms

Raw data messages, samples where the data is from digitizing transducers and digital instrument transformers.

4

4

Delay acceptable for other functions using these samples

P8 = P2

TT5, ≤ 10 ms

Delay acceptable for protection functions using these samples

P7 = P1

TT6, ≤ 3 ms

P1: applies typically to a distribution bay or to bays where low requirements otherwise can be accepted

10.0 ms

P2: applies typically to a transmission bay or if not otherwise specied by the customer

3.0 ms

P3: applies typically to a transmission bay with top performance synchronizing feature and breaker dierential

3.0 ms

Type

1B

Transmission Time

Performance Class

Transfer Time

20 ms for 50 Hz 17 ms for 60 Hz

P3

TT4, ≤ 20 ms

P4

TT3, ≤ 100 ms

P5

TT2, ≤ 500 ms

Table continues



Table 2—Message performance requirements (continued) Message Description

Edition 1 Type

File transfer, such as transfer large les of data from disturbance recording, for information purpose, settings for IEDs, etc.

5

Command messages and le transfer with access control, used to transfer control orders, issued from local or remote HMI functions, where a higher degree of security is required.

7

Time synchronization messages

6

Performance Class

Edition 2 Transmission Time

≥ 10 000 ms

Does not apply

Does not apply

Type

Transmission Time

Performance Class

Transfer Time

5

10, 000 ms t very well the le transfer requirements

P9

TT0, ≤ 10 000 ms

6

half the operator response time of ≥ 1 s regarding event and response (bidirectional)

P10 = P5

TT2, ≤ 500 ms

in line with the operator response time of ≥ 1 s regarding unidirectional event

P11 = P6

TT1, ≤ 1000 ms

the time requirements are in the order of the operator response time (≥ 1 s) or of archives for post-mortem analysis (> > 1 s).

P12 = P9

TT0, ≤ 10 000 ms

Type 6 messages in Edition 2 are command messages and le transfer with access control.

Despite the dierences in the editions, these performance classes allow separation of the various messages into groups with dierent requirements. But when messages with dierent performance classes are transmitted over the same network segment, that network segment must be designed and congured to meet the most sensitive performance requirement. The user must consider all of these factors and determine the best means to logically segregate the physical LAN using VLANs and to prioritize the VLANs with the appropriate settings to meet the performance requirements. Of course, it is always possible for the user to specify dierent performance classes than those given in the standard. The issue with dening the performance classes is that there is no mechanism in IEC 61850 to actually measure the transfer time as required in the dierent performance classes in the standard. Edition 2 of IEC 61850-5 [B18] provides several pages of text explaining the transfer time, but some of this addresses transfer time between substations. Subclause 8.2.3 in IEC 61850-10 [B38] formalizes the ping-pong test to determine if a particular IED meets the GOOSE message performance class requirements; however, this test is not extended to other message types and no performance tests exist. In addition, there are no performance test requirements for an actual system implementation although Clause 18 in IEC 61850-90-4 [B42] discusses the following test



scenarios and requirements for network performance. The following lists some additional tests that are not covered under the IEC 61850 standard: — Simple VLAN handling, which veries the handling of VLANs using GOOSE messages with dierent VIDs — Simple priority tagging, which veries that higher priority messages prevail over lower priority messages. In a network with mixed priority packages, no high priority packages should be dropped. — Simple multicast handling, which veries that the specic multicast (SV or GOOSE) messages are received on the congured ports and not received on other ports — Simple RSTP recovery, which veries the recovery of a single communication failure and measures the recovery time as well as the number of packet drops — Simple HSR, which veries that on connection failure, no packets are dropped or delayed — Simple PRP, which veries that on connection failure, no packets are dropped or delayed — Simple PTP, which veries PTP performance, master clock switchover, start-up convergence time, and oest compared to a one pulse per second reference When considering data transfer requirements, the user should understand the following: —

The standard lists a number of performance measures that may not align with the user’s requirements. In this case, the user should have their own standard based on their system/design requirements and make them known in the appropriate specications.

— It is very dicult, if not impossible, to determine today the exact time a message is received within an IED. Users may need to develop their own standards based upon their requirements that involve end to end results rather than the parts that make up the message. — Given the various IEDs, networks, and software involved in the transmission of a message, it can be dicult to determine exactly where a problem may be when a performance requirement is not being met. —

Performance includes normal operating conditions, but also all failure modes that could occur. Investigation of the impact of each network failure on each performance measure must be undertaken in order for the system to behave as expected under all “normal” and “abnormal” conditions.

3.6 Environmental standards Because communications in an IEC 61850 substation are based on Ethernet, the environmental performance of the IEDs communicating the messages and the communications equipment is as important as protection relays. Consequently, all devices (networking, IEDs, converters, etc.), equipment, and cabling must meet the same reliability, immunity, and performance requirements. With Edition 1, IEC 61850-3 [B13] contains only the following three main sections: —

Quality requirements

—

Guidelines for environmental conditions

—

Auxiliary services covering the power supply

These sections are the IEC descriptions that cover the electrical, mechanical, and behavioral characteristics of devices for reliability, immunity, and performance. IEC 61850 generally references a number of existing IEEE and IEC standards to provide the detailed specications.



This approach changed with Edition 2, which includes a brief summary of the changes in the following list: —

Requirements are in line with those of other equipment used in the same environment (e.g., protection relays)

—

Product safety added based on IEC 60255-27 [B3]

—

EMC requirements completed and in line with the IEC 60255 series [B2] and IEC 61000-6-5 [B7]

This summary does not address the complexity of the revisions, as follows: —

A clause on ratings has been added. This new clause provides rated voltage and operating ranges, input and output ratings, power supply ratings, and specic temperatures. Of importance here is understanding that the stated preferred temperature range is –10 °C to +55 °C. NOTE— The user should be aware of dierences in the specied Operational Temperature Ranges between IEC 61850-3 [B13], [B14], section 4.1.1 of IEEE C37.90™ [B67], and section 4.2 of IEEE 1613.1™ [B60] to verify suitability to the required environment. 3

—

A clause on design and construction has been added. This is where the safety related information from IEC 60255-27 [B3] is included, but also includes all of the environmental requirements.

—

A clause on tests has been added. Instead of referencing other standards for requirements and test, the new standard includes many of the tests to be performed. Communications underway during tests is new, looking a lot like IEEE 1613 with performance classes, with a normative reference to IEEE Std 1613™-2009 [B59].

— New clauses have been added to address marking: rules for transport, storage, installation, operation and maintenance, and documentation. Frequently, vendors will advertise their compliance with IEC 61850-3 [B13], [B14] more than any other part of the standard. Testing companies will perform tests to certify that vendor products are compliant. When considering environmental requirements, the user should understand the following: — Edition 2 and Edition 1 are signicantly dierent and vendors should be consulted on which edition is actually being certied and what conditions. —

Compliance with IEC 61850-3 [B13], [B14] is typically to the IED. A substation automation system is comprised of many IEDs whose overall compliance to IEC 61850-3 [B13], [B14] is typically not tested to IEC 61850-3 [B13], [B14]. The user should understand whether these dierences in compliance levels adversely impact the desired performance of the overall system. For example, the tested operating temperature range of some IEDs may be dierent and still compliant; however, some operate at a higher temperature range than others. If an IED is operated at a higher temperature than is certied, it may fail. If all of the functions the IED performs are non-essential, the user could accept its use despite the dierence in temperature ratings. If the functions are critical, the user may choose to add in redundancy or other compensating architectural elements to mitigate the impact of a failure.

—

For an overall system to meet IEC 61850-3 [B13], [B14] requirements, all components in the system must perform satisfactorily under those same environmental conditions. This includes IEDs, cables, connectors, computers, servers, and dedicated networking devices such as those included in IEEE Std C37.2™ Device 16.

3

Notes in text, tables, and gures of a standard are given for information only and do not contain requirements needed to implement this standard.



3.7 Conguration tools A vendor’s IEC 61850 conguration software tool may not allow the user to fully congure a multi-vendor system. Vendors typically oer IEDs compliant with IEC 61850 while still oering equipment and software features that set them apart. Some vendors may one day oer conguration tools that will work with IEDs from every vendor. Issues typically arise with multi-vendor systems using custom logical nodes. When considering conguration tools, the user should understand the following: — Each vendor oers a conguration software tool that is a small part of a whole IEC 61850 system conguration. — A single third party tool will not likely be able to do everything that a vendor’s tool will perform. — An IEC 61850 SCL conguration tool does not replace the vendor’s IED IEC 61850 conguration tool. —

IEC 61850-6-2010 [B20] added Annex G, SCL Implementation Conformance Statement (SICS), which vendors of system conguration tools and IED conguration tools should provide to show what mandatory and optional features are included.

3.8 Communications between substations Communications between substations is covered in IEC 61850-90-1 [B40], which expands the use of IEC 61850 between substations and addresses specic use cases for the following: —

Distance line protection with permissive overreach tele-protection scheme

— Distance line protection with blocking tele-protection scheme —

Directional comparison protection

—

Transfer/direct tripping

— Interlocking —

Multi-phase auto-reclosing application for parallel line systems

— Current dierential line protection —

Phase comparison protection

—

Fault locator system

—

System integrity protection schemes (SIPS)

—

Real time predictive generator shedding

—

Out-of-step detection

—

Synchrophasors

—

Remedial action schemes (RAS)

So while the title of IEC 61850-90-1 [B40] references the general use of IEC 61850 between substations, the use cases discuss the application of high speed messaging such as GOOSE more than any other message type. When implementing communications between substations, the user should understand that IEC 61850-90-1 [B40] contains the following:



— Describes that not all interfaces dened in IEC 61850 (Interfaces 1 through 10 as rst dened in Edition 1 of IEC 61850-1 [B10] and IEC 61850-5 [B17]) apply to substation-to-substation communications (primarily Interface 2 for protection), where some message types are considered not appropriate for substation to substation communications, such as le transfer and command messages with access control. —

Creates a new Interface 11 for automatics.

— Denes use cases and functions for each interface and develops transfer time requirements as performance classes to each function. —

Presents general requirements for data integrity and reliability (security and dependability).

— Discusses cyber security techniques that restrict access to the network: VLANs and authentication. — Provides summary recommendations for Ethernet networks between substations. —

Evaluates two communication mechanisms: tunneling and using a gateway.

—

Creates two logical nodes for substation to substation communications: ITPC (teleprotection communication interfaces) that represents the communication channel and the LNs providing the data being exchanged between substations; and PSCH (protection scheme) that models state comparison protection schemes (such as distance line protection with permissive overreach, distance line protection with blocking, and directional comparison protection) and direct trip signals.

— Proposes a change in the RXML (dierential measurements) logical node in Edition 2 [changed from MDIF (dierential measurements) in Edition 1]. — Discusses the conguration aspects of IEDs in multiple substations; in particular, using the SED SCL le for exchanging information, which is new in Edition 2. The practical implications of the last three items in the list above are a requirement for Edition 2 when implementing substation to substation communications.

3.9 SCADA master communications Communications using IEC 61850 to a SCADA master is dened as Interface 10 and covered by IEC 6185090-2 [B41] (not included in this recommended practice). Implementing IEC 61850 to the SCADA master increases the potential for improved mapping between the common information model (CIM) in the control center to IEC 61850. Because implementing IEC 61850 back to the SCADA master has been uncommon, another protocol is required for communications between the SCADA master and a substation automation system implementing IEC 61850. The SCADA master protocol must be mapped to IEC 61850. This mapping is not a simple task given the complexity of IEC 61850. This mapping has been accomplished for IEC 60870-5 [B4] with IEC 61850-80-1 [B39]. Work is completed to map IEEE 1815 (DNP3) to IEC 61850 using IEEE 1815.1™ [B64]. Other mappings are currently being worked on. When considering implementing SCADA master communications associated with IEC 61850, the user should understand the following: —

IEC 61850-80-1 [B39] provides guidance on the mapping between IEC 61850 and IEC 60870.

— Work in the IEEE has created the IEEE Std 1815.1 [B64] standard for mapping between IEC 61850 and IEEE 1815 (DNP3).



—

IEC 61850-90-2 [B41] provides guidance on using IEC 61850 with SCADA masters (not included in this recommended practice).

— Using IEC 61850 to the SCADA master will likely increase bandwidth requirements and should be accounted for because many times the communication channel is not Ethernet-based and may not possess the required bandwidth. —

The user must select their gateway IEC 61850 client-server equipment to ensure the server side can create the SCL model required by the user ’s specication.

3.10 Interoperability The adoption rate of IEC 61850 around the world is inconsistent, with the United States lagging in adoption as documented by various industry reports. One reason for this lag in the United States may be the increased likelihood of multi-vendor systems, as American utilities focus more on the best in class devices rather than overall best in class solution from one vendor. With single-vendor systems, the vendor typically coordinates features across product lines, ensuring that all produced IEDs will work together well. With multi-vendor systems, each vendor can interpret the standard in dierent ways, resulting in incompatibilities between logical nodes, GOOSE communications, reporting features, and IED congurability. Since the creation of the UCA IEC 61850 Users Group Interoperability workshops, vendor interoperability has greatly improved and continues to improve. Interoperability issues can occur at any of the following stages of the IEC 61850 lifecycle: — User specication —

Procurement

— Design and conguration —

System commissioning

—

Operation

—

Maintenance

3.10.1 User specication At the user specication stage, interoperability can be problematic when the user tries to dene the substation system using the SSD le according to IEC 61850-6 [B19], [B20]. The SSD le includes XML descriptions of the system one-line diagram and the required logical nodes associated with the primary equipment. A tool is required to do this work, where the SCL implementation conformance statement (SICS) for the tool is dened in Annex G of Edition 2 of IEC 61850-6:2009 [B20] and the UCAIug provides a tool Conformance Testing and respective certication for the SICS. Vendors must be able to import the SSD le into their conguration tools. It is not yet commonplace for a user specication to include the SSD le, because few tools are able to create the le and many vendor tools typically are unable to import the le and use it. The le could be manually created, but this would likely increase interoperability issues. Many times a user specication will be written using dierent approaches to the written specication and bill of material. On the lower end are general specications that only include a general requirement to build a substation that is “IEC 61850 compliant.” These specications may include dierent levels of a bill of material: from none, to approved vendors, to a partial or complete bill of material. On the other end of the spectrum are written specications that provide extensive written requirements with dierent levels of bill of materials. But this approach can also have problems.



When developing a user specication, interoperability issues can be avoided by performing the following: —

Clearly specifying what roles and relationships will exist between the purchaser, vendors, and bidders (such as engineering only) and what level of support and involvement the purchaser and vendors will have during each stage of the project. Examples are: the purchaser providing conguration templates to the bidder prior to design beginning; the bidder providing sample conguration templates prior to the start of detailed engineering; or the purchaser recommending (or requiring) that bidders work with vendors to ensure that IEDs are not misapplied by the bidder during design so they function as required after commissioning; and where the generation of nal IED conguration les is split between the multiple parties developing them, one should be responsible as the lead to provide overall control of the IED conguration les so that a single cohesive le is generated.

—

Stating how the project will proceed with design reviews, what documentation is required for each design review, and how testing is coordinated with design and commissioning (see 4.4).

—

Not generally referencing IEC 61850 as a requirement unless receiving bids implementing a variety of devices or single vendor solution with a wide variety of approaches is actually desired.

— Including specic environmental requirements so the whole system performs under the same environmental conditions. — Including specic logical node requirements in lieu of general requirements of “Edition 1” or “Edition 2.” —

Listing what applications are required and how they are supported by protocols (what applications use GOOSE, whether process bus is required, what methods of time synchronization are required, what network redundacy requirements, etc.).

— Understanding from hands-on experience whether the devices being specied have any known interoperability issues. —

Requiring bidders to submit Protocol Implementation Conformance Statement (PICS), Model Implementation Conformance Statement (MICS), Protocol Implementation Extra information (PIXIT), and TISSUES Conformance Statement (TICS) documents along with conformance testing certication.

—

Requiring interoperability testing from the bidders, including at least a factory acceptance test (FAT) early enough in the project so that there is time for correcting issues without negatively impacting the schedule (see 4.4).

—

Requiring a performance level that the proposed architecture must meet and that all devices required by the specication can meet those performance requirements, or require testing by the bidders to prove the requirements are met by the proposed architecture.

— Providing the bidders with the SSD le, which will require that the owner already has a tool that will work will all vendors required by the specication.

3.10.2 Procurement Once the specication is issued to the bidders, proposals will be submitted and evaluated. Depending upon the project approach, quality of the specication, and quality of bidder responses, the evaluation can be dicult. Several bidders may be invited to present their proposal, perhaps even demonstrating their solution. Upon nal evaluation, the contract is awarded and the project begins based upon the specication’s requirements. If this is the rst implementation, then the procurement of a test or laboratory system is highly recommended. Ideally, the test system should already exist so that a quality specication can be created. In some cases, this is not possible, sometimes because the project is for a single substation whose budget cannot aord the procurement of a test system. Other times, the test system can be included in the procurement and provided by



the bidder. In this case, the test system should be provided early enough in the project for interoperability to be proven long before design and conguration takes place.

3.10.3 Design and conguration Most interoperability issues occur during the design and conguration stage, as the implementation begins and devices are congured. The magnitude of the issues can vary in relationship with the quality of the original specication and the diering roles for the project. If no test system is specied and few design reviews are required, the user may nd little opportunity to become aware of the problems being encountered in implementation when the vendor is only providing a nal, congured system. The design and conguration process may need to account for performance testing, the testing process (such as how system testing will be performed using the test bit in Edition 1 or the simulation bit in Edition 2), the operational processes (for example, how tagging will be accomplished), and the maintenance processes (how devices can be taken out of service with an acceptable impact on system performance). During the design and conguration process, it may be critical to provide sucient consistent documentation to describe the intended conguration and operation of the system and to highlight any issues or considerations that may be encountered when integrating products with dissimilar platform.

3.10.4 System commissioning System commissioning can start as early as a FAT, or even earlier with simple laboratory testing that precedes the FAT. It is not recommended that testing is rst performed during the site acceptance test (SAT), because interoperability issues will likely be discovered too late to allow for preferred approaches to be implemented, resulting in workarounds and other solutions that may impact the system’s ability to meet the original specication. System commissioning should address how all functionality can be tested and when it will be tested, to limit the number of interoperability problems that will be discovered during operation and maintenance.

3.10.5 Operation Identifying interoperability issues during system operation is a likely indication that the system design and commissioning processes were not adequate. However, testing every single condition is rather dicult, so it is possible that interoperability issues may surface during operation, such as improper scaling for values or all possible combinations of interlocking that for some reason could not be veried during testing.

3.10.6 Maintenance Interoperability issues can arise during maintenance activities, but these should be limited to vendors updating rmware and conguration software that changes how the devices interoperate. This is when a laboratory or test system is crucial, so such changes can be tested in a laboratory environment before being deployed in the eld.

3.11 Backward compatibility IEC 61850 does not cover backward compatibility between Edition 1, Edition 2, or any future editions to the standard. Approaching compatibility between editions requires a fundamental understanding of the detailed specications of editions and their dierences. As already noted in previous sections, some parts of IEC 61850, such as part 3, have undergone signicant transformation and great improvement. Each part in Edition 2 provides a dierent level of detail regarding the changes. This is complicated by there being no redlined versions available and, as already noted, some revisions are so extensive any redline may prove rather useless because there are so many changes.



Some argue that specifying IEC 61850 should be more than just specifying “Edition 1” or “Edition 2.” Many vendors do not dierentiate between editions within their published documentation. This clause addresses the following issues: — Dierences between editions —

Interoperability between Edition 1 and Edition 2 IEDs

—

Implementing Edition 2 on Edition 1 IEDs

—

Migrating from Edition 1 to Edition 2

—

Addressing TISSUES regardless of edition

3.11.1 Dierences between editions The dierences between editions are not well documented with Edition 1 and 2. Edition 2 is a signicant improvement on Edition 1, for too many reasons to list herein, but at a high level, the following are some signicant reasons: —

More object models mean less reliance on GGIO

— Gigabit Ethernet means process bus should work for almost all applications —

HSR and PRP provide a bumpless transfer that is critical for process bus and could be critical for GOOSE

—

Edition 1 test bit was replaced in Edition 2 with a simulation bit

Even with these advantages, Edition 2 still has TISSUES.

3.11.2 Interoperability of Edition 1 and Edition 2 IEDs Review of both editions indicates that substantial interoperability hurdles can be encountered without planning. Even with planning, some new functionality will be lost. Some guidance is provided in the following list: —

Avoid using Edition 1 client to get data from Edition 2 server.

— Use care when using GOOSE between dierent editions because Edition 1 and Edition 2 GOOSE are compatible except for the test/simulation bit(s). — Make sure system tools are Edition 2. — When using PRP or HSR with mixed editions, proper network design is required to integrate the Edition 1 devices.

3.11.3 Implementing Edition 2 on Edition 1 IEDs Whether a vendor can implement Edition 2 on an Edition 1 IED platform depends upon many variables with endless combinations, making a simple answer impossible. Vendors should always be consulted for their recommendation. Some considerations are as follows: —

Vendors moving ahead with Edition 2 may not support both editions for very long on the same hardware platform. It is possible that vendors may require a complete hardware and rmware upgrade, not just a rmware upgrade.



— Support of HSR and PRP will likely cause a hardware and rmware change, which depends upon the IED architecture as to whether this can be accomplished in the eld, requires the vendor to implement the change at the factory or the purchase of new equipment. —

Support for gigabit Ethernet requires new Ethernet cards that may be compatible with existing hardware, but rmware may need upgrading.

3.11.4 Migrating from Edition 1 to Edition 2 The process of migrating technologies in a substation automation system can be a signicant undertaking. The ease at which this migration happens could depend highly upon any organization’s ability to withstand the pains encountered by migration. Some vendors may never implement Edition 2 or may take years to perform the development. As previously stated, Edition 2 is compatible with Edition 1, but good planning is required.

3.11.5 Addressing TISSUES regardless of edition In addition to the backward compatibility of editions, the user must also understand the backward compatibility with TISSUES. Edition 2 addresses approximately 700 to 800 TISSUES identied in Edition 1. There are also TISSUES for Edition 2. Edition 2 provides new requirements regarding TISSUES that are not required in Edition 1, as follows: —

IEC 61850-1 [B11] claries that TISSUES are technical issues that vendors must transparently state in their documentation that they have implemented xes.

—

IEC 61850-10 [B38] states that the TICS is a statement with IED-specic information regarding the implemented TISSUES detected after publication of the standard and is not subject to standardization. In other words, the TICS indicates the supported TISSUES.

3.12 User processes Adopting IEC 61850 may have signicant impacts on the user’s processes, even with “simple implementations.” Grouping user processes into engineering or design, construction, and operation and maintenance is one way to address the impacts; however, each discipline (protection, control, automation, metering, security, networking, asset management, operations, etc.) will likely have their own impact on engineering/design, construction, and operation and maintenance unless that discipline is only related to operation and maintenance. However, the operation and maintenance departments must have input into the design and construction process; otherwise, signicant hurdles can develop that can derail implementations. For example, Table 3 shows the potential impacts on substation, network, and ber expertise when implementing IEC 61850 with MMS, GOOSE, and process bus.

Table 3—Process impacts for implementation Expertise

Experience levels

Engineering/ Design L

Substation

M

No experience with ber

H

L

M

X

Some experience with ber Deployed ber

Construction

X

H

L

X

X

X

X

Operation and maintenance M

H

X

X

X

No experience with networks and DNP3 TCP/IP

X

X

X

Some experience with networks and DNP3 TCP/IP

X

X

X

Deployed networks and DNP3 TCP/IP

X

X

X Table continues



Table 3—Process impacts for implementation (continued) Expertise

Experience levels

Engineering/ Design L

Network

Fiber

M

Construction H

L

M

H

Operation and maintenance L

M

H

No experience with substations. No experience with substation LANs and DNP3 TCP/IP

X

X

X

Some experience with substation LANs and DNP3 TCP/IP

X

X

X

Deployed substation LANs and DNP3 TCP/IP

X

X

X

No experience with substation ber

X

X

Some experience with substation ber Deployed substation ber

X X

X X

X X X

The reasons for selecting the impacts as low (L), medium (M), or high (H) are based upon at least the following: —

Documenting the communications design may require a new approach or an evaluation of whether the existing approach can be maintained, must be improved, or be retired for a new process.

—

Identifying the impacts on all drawings, from single line diagrams, three line diagrams, and schematics of all types such that these drawings properly document the implementation of IEC 61850.

—

Deploying GOOSE and process bus are dissimilar to deploying DNP3 transfer control protocil/Internet protocol (TCP/IP), requiring dierent types of networks and performance.

—

The remote terminal unit (RTU) still exist, requiring a device that collects data from the substation, but it likely needs to map those protocols to the SCADA master protocol and a process needs to be developed to update the old point list process.

—

Some serial connections to IEDs may still exist, meaning portions of previous approaches may still be required and IEC 61850 provides no guidance on any system integration issues; these are more likely addressed by IEEE Std C37.1™-2007 [B65].

— The performance of GOOSE and process bus requires the installation of optical ber cables, patch panels, and connectors (refer to 3.2.1.6). Unfamiliarity with optical ber cable specications, design requirements, installation, splicing, connectors, termination in patch panels, pathways (tray and conduit), and testing may represent a signicant challenge to the organization that has never installed optical ber cables anywhere in the enterprise. Skills, experience, installation procedures, testing programs, and designs from other types of optical ber cable installation could be applied to substations so that the cable installation meets the same requirements as IEC 61850-3 [B13], [B14] conformance tested IEDs. Refer to IEEE Std 525™ [B55]. —

The deployment of GOOSE means that the design process must address logical contacts and how they can acceptably replace hard-wired contacts on system drawings, including the required monitoring, failure modes, and testing modes.

— Redundancy is likely required in order to obtain the performance required for GOOSE and process bus, using protocols and methods unfamiliar to the sta tasked with the design and maintenance of the network. —

Availability of process bus equipment may be limited and cause interoperability issues for a critical function, requiring ber optic cables to the yard and routes that may not traditionally be supported by outdoor substation conduit design.

— Any documentation can be signicantly impacted by how SCL is incorporated into that documentation or leveraged to reduce or even remove the documentation. 46 Copyright © 2017 IEEE. All rights reserved. Authorized licensed use limited to: AALTO UNIVERSITY. Downloaded on March 02,2018 at 12:08:25 UTC from IEEE Xplore. Restrictions apply.


4. User considerations Success at implementing IEC 61850 depends upon the denition of success, using the following dierent approaches: — Internal implementation with limited outside support, pilots may or may not be included using dierent approaches (such as implementing only MMS, only GOOSE, MMS plus GOOSE, MMS plus GOOSE and hardwired inputs and outputs, SV, etc.). —

Internal implementation with some level of outside support from a system integrator or consultant with experience in implementations.

—

Limited internal implementation with mostly outside support from a contractor experienced in implementing IEC 61850.

There are many user considerations when planning to implement IEC 61850 in substations. This clause discusses the following considerations: —

The basic components of the business case

—

Considerations for adoption

—

Moving ahead with implementation

—

Testing, troubleshooting, and maintenance

—

Cybersecurity

4.1 Business case Adopting IEC 61850 for substation automation can be a fundamental step change in technology for many users, so the implementation will only be successful if a user engages the whole enterprise and establishes a distinct and quantiable business case, or cost benet (return on investment (ROI)). Developing a business case for any substation automation implementation is a very complex and company-specic exercise, regardless of implementing IEC 61850 or not. The business case must be generated using input from across the enterprise in order to gain support from the business units that will be tasked with the implementations. The business case must address both new substations and retrots and provide a migration plan from older technologies to newer technologies. To optimize the long-term business case, a cross-departmental strategy is required that includes a technical road map so that each department impacted (protection, control, automation, operations, maintenance, planning, technicians, substation design, distribution/transmission design, metering, communications, networking/IT, security, asset management, etc.) can more easily transfer existing independent and/or integrated designs, procedures, and policies to those that are completely integrated and supported by IEC 61850. This disciplined approach to adopting IEC 61850 results in most users not expecting a positive ROI until after the rst, second, or even third implementation. The business case needs to consider all costs and considerations that can be expected over the life cycle of the installation, such as the following: —

Cost and considerations

—

Scheme redesigns

—

Functions being implemented

—

Future applications

—

Technical and implementation issues



—

Schedule

—

Technology refresh

4.1.1 Cost and considerations The business case must include the expected reductions in costs for new and retrot implementations. Implementing IEC 61850 can reduce costs depending upon what functions are being implemented, such as the following: —

MMS only

—

GOOSE only

—

MMS and GOOSE

—

MMS, GOOSE, and SV

—

Additional 61850 features as needed

For example, by using GOOSE to eliminate point-to-point hardwiring of IEDs or SV to eliminate instrument transformer circuits, the cable, installation, termination, and testing costs will be oset by the additional costs associated with substation network, construction, testing, and relay technicians being able to eectively work together to test and troubleshoot Ethernet networks that support the implemented functions. Some potential cost reductions and benets are as follows: —

Reduction in substation wiring, where internal panel, panel to panel, control house, and panel to substation yard can all be impacted

—

Reduction in panel hardware

—

Reduction in substation wiring design time

—

Reduction in operations and maintenance due to improved reliability

—

Reduction in engineering design time

—

Improved system performance due to new functionality that was previously cost prohibitive or technically unfeasible

—

Reduction in operations and maintenance due to improved reliability and observability—system can be more fully monitored

These cost reductions will be oset by increases in some of the following costs: —

Training costs for all personnel involved in the design, implementation, testing, and maintenance of the system, such as engineers, relay technicians, substation design engineers, network engineers, and eld technicians. This training is also typically ongoing.

— IED costs will likely increase over previously used technology, plus the additional networking equipment that may not otherwise be required. —

Scheme redesigns, which will represent an early cost increase.

4.1.2 Scheme redesigns The business case must address the costs for redesigning and/or migrating existing schemes to new schemes. Adopting IEC 61850 may require redesign of operating/safety/testing procedures. Using Ethernet network commands to open and close breakers may mean that a visible disconnect for control tag-out can no longer be



accomplished without losing all visibility to the IED (if the user decides to disconnect the Ethernet cable from the IED as part of the isolation process). Adopting IEC 61850 may require redesign of protection and control scheme standards. Certain functionality in use may impact the business case because that functionality has the following limitations: —

Not available in the vendor’s implementations of IEC 61850. In Edition 1, the reclosing logical node (RREC) has no mandatory control function and in Edition 2 the optional control function has been completely removed from RREC. So when not available for these reasons, it is not possible to enable/ disable reclosing through IEC 61850 commands without other compensating methods. One solution to this control problem requires additional programming and the use of GGIO logical nodes, which should be considered when using Edition 2 where use of GGIO has been redened.

—

Not available in IEC 61850. While Edition 2 adds many logical nodes, as well as other IEC 61850-90 series reports, to Edition 1 logical nodes, not everything a user needs may be modeled by IEC 61850. While IEC 61850 allows for extensions, these extensions may not be well-supported by vendors.

4.1.3 Functions being implemented The business case must consider which functions are being implemented. While IEC 61850 does include optional and mandatory requirements, it does not dictate that all features must be adopted. Installations around the world vary from a simple use of GGIO to complete elimination of all copper wiring from the equipment in the substation yard to the control house. There are a wide variety of hybrid approaches in use. A user may choose to perform a breaker open command through either the process bus or the station bus, but hardwire the trip circuit from the IED to the apparatus. IEC 61850 does not specify whether such an approach is permitted or not. IEC 61850 is a very large toolbox, and it is up to the user to determine which tools to implement.

4.1.4 Future applications The business case cannot consider all of the added benets that come later with implementing a new standard. This is because it is dicult to anticipate benets derived from applications that are not yet conceived. This is somewhat a “build it and they will come” benet of deploying the technology, a result of the toolbox in IEC 61850 that allows engineers to develop new applications to solve problems more eectively than ever before.

4.1.5 Technical and implementation issues The business case should also consider that the IEC 61850 standard itself is constantly changing through technical issues. While not specically identied in Edition 1, the technical issue resolution process is described within Edition 2. These TISSUES can cover many dierent areas and vendors are required to make available to users what TISSUES are addressed in their products. In addition to TISSUES, the user must also consider issues that may arise from vendor implementations that can limit interoperability and cause some applications to be abandoned because there are no good solutions for the user to implement. These may become so severe that the implementation may be postponed or signicantly scaled back until a future time when the IEC 61850 standard and or vendors improve implementation. These situations increase risk to implementation success that the business case should address through the allocation of costs to risks.

4.1.6 Schedule The business case must address the planning and implementation schedule. It is likely that a user’s rst few IEC 61850 implementations will take longer from planning to in-service date. Therefore, it is recommended that implementations with time critical in service dates not be considered for a user’s initial attempts at implementing IEC 61850.



4.1.7 Technology refresh The business case may address when substations implemented with IEC 61850 are updated or refreshed with newer technology. The update can be as simple as planned rmware upgrades to all or some IEDs to a complete substation retrot. This may also address issues of moving from Edition 1 to Edition 2, or from Edition 2 to future editions.

4.2 Adoption With all change, it is dicult to identify all the impacts and prepare for implementation. But a change such as adopting IEC 61850, that involves critical systems in electrical power delivery, requires that additional planning must be done. This clause provides some insight into adopting IEC 61850.

4.2.1 Enterprise buy-in and involvement Some users may choose an adoption path that is top-down, meaning that the adoption is not in question and enterprise buy-in and involvement is required by management. Whether this is the case or not, essential to the successful adoption is that all operational aspects of a substation owner/operator are actively involved long before the implementation begins. Depending on the nature and extent of IEC 61850 deployments, there are a wide range of personnel and departments that will be impacted by adopting IEC 61850, as follows: —

Engineers, designers, and drafters will need training in order to design substation functions and automation that is based upon IEC 61850.

—

Procurement departments will need to revise substation bills of material, potentially change standard terms and conditions, and possibly negotiate terms for corporate licensing of IEC 61850 software tools.

— Standards departments will require training so they can eectively revise all existing standards impacted by the implementation. — Network/IT personnel may have jurisdiction/interest in substation network equipment that will become a critical infrastructure supporting the implementation. When the personnel only have traditional IT experience, training is required to become familiar with the operational environment of the electrical power system as well as with the networking concepts within IEC 61850. —

Construction personnel will need additional tools and techniques for new installations processes, such as network termination tools and/or optical ber installation and termination systems, and be trained on them.

— Testing/Commissioning teams will need to develop new test procedures, be trained on network analysis/troubleshooting tools, and be trained on the IED conguration tools. —

Operations personnel will need training so they can develop a new set of operating instructions for IEC 61850 modied procedures such as reclosing lockout and control tag-out.

—

Maintenance personnel will need complete training and provisioning to deal with the new features of the IEDs and how to maintain an integrated system.

— Asset management personnel should also be trained so they can take advantage of the structured, datarich environment oered by IEC 61850. —

Metering departments should be trained so they understand how their function is impacted by the implementation.

Depending upon the user’s organization, the departments listed above may be dierent and could include even more departments not listed. In general, a complete automation program adopting IEC 61850 can involve almost all departments across the enterprise.



Each department needs to review all existing standards, procedures, and policies for evaluating how they can be converted to IEC 61850. By not doing this, the user may encounter limitations in their implementation due to weaknesses in the vendor’s product(s), or develop a weaker business case. For example, it is common that protection engineers will not allow a protection relay to be evaluated based upon its ability to support IEC 61850. This can vary from minimal consideration that has little impact on overall selection to no consideration. It is also common that network engineers coming from traditional IT backgrounds will not allow the corporate standard networking equipment to be evaluated for its ability to support IEC 61850 and may even force the network design into compensating architectures.

4.2.2 Centralized conguration/change management When evaluating a vendor’s IEC 61850 oering, part of that evaluation should include evaluating their IED conguration tools and system conguration tools. IEC 61850 structures the information and data into a standard machine-readable format, allowing for many uses. In a multi-vendor approach, it becomes critical that all tools work with other vendor ’s tools. This is a key critical factor for a successful multi-vendor implementation that includes no workarounds. For example, one vendor’s tool may not read another vendor’s conguration le without manually editing the le to make it compatible. Adopting IEC 61850 may require frequent le changes for both congurations and rmware, as follows: —

New programmable logic may be required to match new IED functionality to substation standard practices. This logic may need to be developed and debugged in the eld, resulting in new rmware being released late in the project. This could impact all other implementations already in service and already planned.

—

Creating multi-vendor IEC 61850 implementations requires interoperability that may require conguration changes during testing and commissioning. In any case, interoperability issues can range in impact from small (simple rmware changes) to signicant (moving to a new product). Identifying interoperability issues early only reduces their impact on implementation, it does not necessarily prevent changes from occurring.

— The IEC 61850 standard has conguration-change safeguards built in that require new conguration downloads to each subscribing IED if a change is made to the publisher IED. This feature can be implemented, but the impacts must be completely understood as it may disable functionality if not adequately understood. —

Edition 2 of IEC 61850 is relatively recent, and IED vendors are still in the process of converting from Edition 1 to Edition 2. Future editions may always be anticipated, which may provide new logical nodes, new data attibutes within existing logical nodes, and new features and functions. How vendors address the conversion between editions will reect their choices in hardware and software architecture. For example, conversion from one edition to another can be anything from a simple rmware upgrade, to a module change that requires the IED to be sent to the factory (not eld replaceable), to a completely new hardware platform under the same product family, or to a completely new product with a completely dierent form factor than the old model.

Many of these le changes can be reduced by performing adequate testing early in the adoption, prior to implementation, such as factory acceptance testing. Even if this is the case, the loading of new conguration and rmware les can be a complicated process; it is strongly recommended that a centralized conguration management system be developed and employed. A conguration management system may be required anyway because of other regulatory issues (such as North American Electric Reliability Corporation (NERC) compliance) or other existing policies and procedures.



4.2.3 User/Vendor/System integrator partnership For the sake of expediency in “getting started” with IEC 61850, some users approach their rst few IEC 61850 implementations as turn-key projects awarded to a single vendor and/or system integrator. A user-led approach can mimic this approach when one department acts as if it were the vendor/integrator. This approach can have a negative or positive impact to the eventual success of adoption. Negative results may be observed when this: —

Circumvents the buy-in from the various departments mentioned previously.

—

“Parachutes” the technology into an operating environment without any proper preparation.

— Develops conicts with the user’s operating and safety procedures because the vendor/system integrator does not have a working knowledge of the user ’s working environment. —

Uses some functionality that is not immediately apparent to the user. The discovery of such functionality (or lack thereof) during testing may cause expensive rework/eld modications.

— Avoids training, which is more than just showing up for a one or two week class during/after the installation. Positive results may be observed when this: —

Involves an internal team from the initial IEC 61850 implementation planning through to the project completion stages.

— Involves all stakeholders in all decisions regarding automation, protection, and control philosophy. — Develops a knowledgeable resource in IEC 61850 who is on the team to develop the implementation plan that provides a jump start into getting a working IEC 61850 system. — Develops a specication that implements the parts of IEC 61850 that meets the identied needs of the business case. — Uses a dedicated team of engineers to work hand and hand with the vendor/integrator to allow for the proper knowledge transfer. — Trains all internal stakeholders throughout the planning and implementation process. —

Uses shadowing during testing/commissioning in order to gain important hands-on experience.

— Provides all congurations, conguration tools, IED documentation, and test records. It is likely that some combination of the above will result in any implementation.

4.3 Implementation plan Every user who designs, constructs, and operates electric substations has a time-proven implementation plan for building substations, which may or may not address the peculiarities of specic technologies. When adopting IEC 61850, there are specic modications and elements to those developed plans that must be considered. The implementation plan becomes a series of plans that will look at the user’s approach to IEC 61850 from an organizational view, polices/procedures, procurement, technical implementation, design, vendor/integrator selection, and others. A decision point will also arise as to what edition of IEC 61850 is to be used. Edition 1 represents the majority of equipment installed today. Edition 2 was released a few years ago and, depending upon implementation, may not be completely backward compatible with Edition 1. Future editions will follow. This section addresses several aspects of the implementation plan.



The implementation plan also addresses whether any IEDs that do not support IEC 61850 will be implemented in the architecture. While more vendors are implementing IEC 61850, it is still possible that some devices may not support IEC 61850 and need to be addressed in the proposed architecture. The implementation plan includes the following plans, addressing: —

Protection, automation, and control

—

Training

— Network design — Conguration —

Documentation

—

Simulator

—

Migration

4.3.1 Protection, automation, and control The automation plan for IEC 61850 addresses what functionality will be employed and what IEC 61850 technique(s) will be used for protection, automation, and control. While IEC 61850 provides optional and mandatory requirements, it does not specify what schemes will be used and does not even specify which logical nodes must be implemented for those schemes, or in general. So planning what IEC 61850 functions will be used (versus hardwiring or other protocols) is an essential undertaking early in the implementation plan. Most IEC 61850 installations to date tend to focus on using MMS to transfer information to/from IEDs and local HMIs, SCADA gateways, and other IEDs. This approach is similar to the selection and implementation of IEEE 1815 (DNP3). A smaller percentage use GOOSE to eliminate hardwiring of signa ls between IEDs, for example, trip circuits for bus dierential, breaker failure, and transfer trip. The GOOSE messaging may even be the only IEC 61850 protocol being used. A smaller percentage use SV to eliminate instrument transformer copper wiring from apparatus to control house IEDs. An even smaller percentage of users use the full suite of IEC 61850 system integration tools. Often, a hybrid approach is employed when a user is unsure of the technology and wants to develop additional experience. For example, the primary protection package may implement SV, but the secondary protection uses hardwired instrument transformer circuits; or breaker close commands may be accomplished by GOOSE, but the trip commands may be hardwired. Because these decisions will present varying levels of technical, economic, and safety risks, representatives from all involved departments should develop the automation plan cooperatively and be trained. Of particular note is the fact that when hardwired control points are eliminated in favor of networked communications, issues with existing safety and operations procedures can arise for such things like tag out, visible break, and test links. These issues need to be discussed and resolved with all departments during the automation planning stage, or very costly modications may occur later on.

4.3.2 Training All departments associated with implementing IEC 61850 must be trained in IEC 61850. General training is always a good start and may be all that is needed by some departments, including training as oered by consultants and vendors on their products. Advanced, specialized training may be required by other departments. Training is required because of the following issues: — Terminology in IEC 61850 is dierent from IEEE Std C37.2 [B66], which means that familiar terms such as 21 (distance protection), 50 (overcurrent protection), and 52 (AC circuit breaker) may need to be correlated on drawings and manuals to the IEC versions of these terms (logical nodes: PDIS, PTOC, and XCBR respectively).



—

Documentation techniques may change from the ac and dc elementaries of traditional substation design to address the incorporation of the nomenclature of logical nodes, data ows, and programmable logic. An approach to documentation will need to be developed, which rst requires training.

—

Understanding the logical nodes is required before selecting those that will be employed, where those available could vary depending on each IED vendor’s implementation.

—

IEC 61850 also impacts system testing, maintenance, and operating personnel, so these departments require training to have an understanding of how the system works and how to implement new documentation standards and tools.

4.3.3 Network design Any implementation of IEC 61850 requires an Ethernet network (based upon IEEE Std 802.3™ [B57]). Depending on the substation size, layout, and what IEC 61850 functionality is implemented, the network can be very simple or very complex. For critical protection functions carried by GOOSE and SV, the network must provide the necessary quality of service to reliably deliver these messages during periods of high network trac and possible failure modes. The IEC 61850-90 series ([B40] through [B45]) provides some guidance on how a user could congure their networks, but the networks still need to be designed to meet the worst case scenarios laid out in the users’ specication. A network design plan includes addressing both the physical network and logical network. The physical network design is typically represented on a communications block diagram, showing all communication connections, regardless of whether they involve IEC 61850 protocols or not. The implementation plan addresses what networking equipment is used, where optical ber cable must be used and where copper cable is acceptable, what terminations will be used, how communications cable will be routed, redundancy and failover, and the physical security of the equipment supporting the Ethernet network. Some of these issues may be addressed in IEEE Std 525 [B55] and IEEE Std 1615 [B61]. The design plan may need to address the creation of new standards around these design issues. The logical network design involves cyber security concepts, plus other items such as IP address schemes involving how subnets and VLANs will be used. The design plan may need to address the creation of new standards around these design issues. Both the physical and logical plans must also address any other devices that use other protocols besides those specied by IEC 61850, such as SCADA protocols like IEEE 1815 (DNP3) and Modbus or network protocols such as simple network management protocol (SNMP). All of the data ows should be documented as part of the logical design in a data ow diagram. This diagram shows all data ows being used on the network. The network design plan should also consider testing that the proposed network architecture meets the desired performance requirements for all of the protocols being used on the network. Examples are speed, latency, jitter, bandwidth, and failure modes.

4.3.4 Conguration One common misperception is that IEDs implementing IEC 61850 are “plug and play” and mapping data from IED to another is eliminated. IEDs require conguration specically for the communications of IEC 61850 information between IEDs, data concentrators (gateways or RTUs), and HMIs. A conguration plan addresses how congurations will be documented, created, stored, and revised. Additionally, common tools to congure IEDs from multiple vendors are generally not available, so it is necessary to become procient in multiple conguration tools. The conguration plan should examine not only the vendor’s documentation, but also the software applications. This detailed review may provide insights into conguration settings and procedures that are not well described in the other. Feedback should be provided to the vendors when this situation occurs.



4.3.5 Documentation Documentation is not what it used to be, when a stack of drawings may have been left out at the substation, marked up over time, and perhaps updated at some point. It is not uncommon to have a set of documentation provided for each facility when it is built, commissioned, and placed into operation. This documentation includes a facility operations manual, test and commissioning procedures, station IED maintenance procedures, substation drawings, IED manuals, equipment manuals, and point lists (some of these are described in “Schematic Representation of Power System Relaying” [B70]). This set of documentation should also include backups for all software application executables and rmware, plus congurations. As conditions change at the facility over time, this documentation must be kept up to date. Document management systems and conguration management systems can help with this task. Good documentation helps improve troubleshooting support (see 4.4.2) and testing (see 4.4.1).

4.3.6 Simulator One technique that some users have employed is to create a substation automation simulator/laboratory for IEC 61850. A simulator serves multiple purposes, such as the following: — Testing of IED congurations prior to loading in the eld IEDs — Investigation/troubleshooting of IED and network conguration issues —

Training of new designers, engineers, and technicians

—

Periodic retraining and refreshment of designers, engineers, and technicians

— Testing new applications or functions before they are deployed in the eld People who are contemplating the adoption of IEC 61850 should strongly consider making the investment to construct a simulator. Typical construction mimics exactly what is installed in the facilities. This can become problematic when there is a lack of standardized implementations. Other problems can occur as technology matures, but these problems will mimic the problems being experienced in the eld.

4.3.7 Migration A migration plan is needed when some IEDs are initially implemented in the architecture without supporting IEC 61850. The migration plan addresses how and when the devices will be migrated to supporting IEC 61850. This can be accomplished in many ways, such as the following: — Working with the vendor to provide an IEC 61850 implemented IED — Arranging for the review of the technical specications for the device and evaluating other IEDs that support the same functional requirements, but with IEC 61850 support already supported Of course, it is possible that some IEDs will not be migrated until the vendor no longer supports the IED. This could happen sooner than people think it will, therefore, maintaining good relationships with vendors is key to understanding when this will happen so a migration plan can be developed before the IED is no longer available.

4.4 Testing, troubleshooting, and maintenance Testing, troubleshooting, and maintenance are not covered in detail by IEC 61850 but is an area that will be signicantly impacted during a transition to IEC 61850. Previous discussion on interoperability (see 3.10) has covered testing as well as operation and maintenance.



4.4.1 Testing IEC 61850-4 [B15], [B16] discusses dierent stages of testing during the stages of quality assurance areas, as well as IEC 61850-10 [B37], [B38] and IEEE Std C37.1 [B65] as shown in Table 4.

Table 4—Comparison of tests Test Name

Test Description in IEC 61850-10 [B37], [B38]

Basic test

The manufacturer provides tests for prototypes before the system test is performed.

System test

The system test proves the correct functionality and each IED’s performance under dierent application conditions and in cooperation with other IEDs in the substation automation system.

Type test

The manufacturer is responsible for the correct handling of type tests and system tests of his individual products. Type tests and system tests are preconditions for starting the regular delivery.

Verication test

Customer specic verications and approvals may be required according to the customer’s philosophy and shall be negotiated between the system integrator and the customer. These might be done by the customer at product level as well as at system level.

Conformance test

An IED conformance test reduces the risk for the system integrator that all IEDs in an integrated system will prove the fulllment of the technical requirements.

IEEE Std C37.1 [B65]

The type test proves the “tness for use” by performing tests on samples from the manufacturing process: a) Mechanical capability b) Electromagnetic compatibility c) Climatic inuences d) Functional correctness and completeness The type test is passed before the start of regular production.

The conformance tests are performed on the communication channels of IEDs and include the check of the communication protocol in accordance with the standard or its parts. Any device supporting a “standard” protocol shall be certied by an organization that is approved to perform testing by the User Group associated with the protocol (i.e., the Modbus-IDA, the DNP Users Group, and UCA International Users Group). This testing is the only way to certify that the product properly supports the protocol.

Table continues



Table 4—Comparison of tests (continued) Test Name

Test Description in IEC 61850-10 [B37], [B38]

IEEE Std C37.1 [B65]

Routine test

All IEDs have to pass the manufacturer’s dened, specic routine tests for quality before the products are delivered.

The routine test consists of special hardware and functionality tests such as burn in, insulation, and function, which should be carried out for each IED before leaving the manufacturer.

Factory Acceptance Test (FAT)

The FAT takes place before the appropriate integration and commissioning phases take place and tests all functions with their specic conguration and parameter settings. When required, the successful nishing of the FAT results in equipment delivery to the site and commissioning. The contents of the FAT have no additional specic requirements, but IEC 62381 Automation systems in the process industry – Factory acceptance test (FAT), site acceptance test (SAT), and site integration test (SIT) [B50] could provide guidance on what could be included in the FAT and SAT.

The optional FAT provides validation and verication prior to system deployment. Tests performed during the FAT may include: ⎯ Availability test ⎯ Computer and display performance ⎯ Control performance ⎯ Data acquisition performance ⎯ Expandability test ⎯ Functional test ⎯ Maintainability test ⎯ Stability test ⎯ System performance tests ⎯ User interface performance

Site Acceptance Test (SAT)

A mandatory version of the optional FAT that occurs before or after trial operation that veries each data and control point and the correct functionality inside the automation system and between the automation system and its operating environment in the substation with nal congurations.

The SAT contains the same types of tests as the FAT and is carried out on the completely installed equipment in the following four steps: 1) Process—IED level 2) IED level—station control level 3) Station control level—system control center(s) 4) Process—system control center(s)

IEC 61850-90-4 [B42] provides additional guidance on network testing, with specic insights into what conformance tests are provided for several of the network protocols that can be used when implementing IEC 61850 (RSTP, SNTP, multiple VLAN registration protocol (MVRP), PTP, PRP, HSR, etc.). Additional conformance tests are included, as well as some guidance on network tests that could be included in the FAT and SAT. One variation of the verication test is otherwise known as a “proof of concept” test, whose purpose is to verify that the system could meet some of the more critical system requirements, outside of routine and type tests. Critical areas are typically associated with interoperability. Whether called verication or proof of concept, this testing is highly recommended before detailed design begins. This testing limits the risk associated with interoperability. Key to testing will be what exists for system documentation to support the testing process as discussed in 4.3.5.

4.4.2 Troubleshooting IEC 61850 addresses troubleshooting in an extremely limited manner, but IEC 61850-4 [B15], [B16] addresses the concept of troubleshooting by using other terms in warranty and after sales service that include the following: —

Providing urgent information to the customers about malfunctions

—

Correcting of detected software errors and hardware defects

—

Releasing software updates

IEEE Std C37.1 [B65] discusses troubleshooting tools as part of the overall substation HMI or substation computer, including the following items:



—

Protocol analyzers

—

Vendor software applications

—

Manuals and documentation for system components, protocols, and IEDs

— Help les for software applications HMI tools can also be developed, such as customized screens to display status and diagnostic data from system components, evaluating the retrieved data against some dened values as element tests, providing corrective actions, and displays indicating device health and other statistics. Key to the troubleshooting process will be what exists for system documentation to support the troubleshooting process as discussed in 4.3.5. In addition to documentation, consolidated communication diagnostic information supported by managed network switches, network protocol analyzers, and GOOSE/SV test sets can help in the troubleshooting process. A key change in troubleshooting occurs with the implementation of any substation automation technology, not necessarily only caused by implementing IEC 61850. The past reliance on substation drawings to aid the troubleshooting process is being replaced with a reliance on vendor conguration software applications (see “Schematic Representation of Power System Relaying, [B70], and Young and Haas [B71]).

4.4.3 Maintenance IEC 61850-4 [B15], [B16] denes maintenance as part of the customer’s life cycle also including service and support. IEC 61850-4 [B15], [B16] requires that documentation include any preventative maintenance steps and that the customer carry out these steps for service or exchange. In addition, corrective maintenance should be carried out to limit the decrease in system availability. Who provides these maintenance activities depends upon how the system is developed (internally by the customer and/or using a system integrator). IEC 61850-4 [B15], [B16] considers the most important maintenance tool to be the IED conguration software, but also states that engineering tools are needed for system maintenance. Finally, IEC 61850-4 [B15], [B16] states that maintenance of failed parts is preferred through the provision of identical or backward compatible products. IEC 61850-90-4 [B42] states that when maintenance of a remote substation is typically several factors more expensive than other substations, remote maintenance of networking equipment is highly recommended along with modular design of equipment with eld replaceable or hot-swappable modules. These are good recommendations that apply to every aspect of a substation automation system, regardless of implementing IEC 61850. IEEE Std C37.1 [B65] addresses maintenance in several ways, as follows: —

Documenting preventative maintenance and corrective maintenance

—

Maintainability testing

—

Database maintenance tools

—

System maintenance tools

—

Software maintenance contracts

—

Impacts of cybersecurity on maintenance

—

Communication interfaces supporting maintenance

—

Impact of maintenance on mean time to repair



4.5 General cybersecurity comments Cybersecurity is not an exhaustive topic within IEC 61850 itself. IEC 61850-90-4 [B42] contains the following: —

Provides one short clause on cyber security

—

Summarizes where the security provisions are located: IEC 61850-8-1 [B33], [B34], IEC 61850-9-2 [B35], [B36], IEC 61850-90-5 [B43] and Annex K of IEC 61588:2009 [B9]

—

Refers to IEC 62351-6 [B49] for additional details

Edition 2 of IEC-61850-1 [B11] describes that the IEC 62351 [B47] standards specify the necessary mechanisms for data and communication cyber security, specically IEC 62351-6 [B49], which covers the following issues: — For Client/Server communication using TCP/IP based protocols like MMS, IEC 62351-6 [B49] species security primarily through transport layer security [(TLS) as dened by RFC 2246], but actually correlates the IEC 61850 parts and IEC 62351 [B47] parts (including IEC 62351-4 [B48]). — SV and GOOSE are likely adversely impacted by most encryption techniques or other security measures that impact transmission rates which may not be acceptable (Hohlbaum, Braendle, and Alvarez [B1]); therefore, authentication is the only security measure specied for these protocols. —

Other IEEE standards can also be applied to substation automation systems using IEC 61850:

—

IEEE Std 1686™ [B62] species security capabilities in IEDs used in any substation automation system, including those using IEC 61850.

—

IEEE Std C37.240™ [B69] provides cyber security requirements for substation automation, protection, and control systems.

5. Critical success factors Many users succeed at implementing IEC 61850. Whatever approach might be used, a business case may be required to justify the costs and quantify the benets (see 4.1). The adoption involves all departments that are impacted by the implementation (see 4.2). An implementation plan provides the guidance to keep the implementation on track (see 4.3). Testing, troubleshooting, and maintenance will be impacted by the adoption (see 4.4) and need to be addressed by the overall plan. Security must also be addressed as part of the plan as it may critically impact system performance (see 4.5). Critical success factors may be summarized as follows: — Develop a comprehensive IEC 61850 specication. — Create a well dened implementation plan. —

Test new technologies in a simulated testing laboratory.

— Educate everyone that is aected by the change. —

Create new design, documentation, testing, troubleshooting and commissioning standards, policies, and procedures.

—

Develop a sound vendor equipment and software evaluation process for this new technology.

— Develop a sound lessons learned from the rst installation and make the required revisions.



Annex A (informative)

Examples for future 2030.100 Project Authorization Request (PAR)s Some examples for future PAR extensions to P2030.100: —

P2030.100.X Implementation for Substation local/remote using IEC 61850

— P2030.100.Y Implementation for Substation interlock schemes using IEC 61850 —

P2030.100.Z Implementation for Substation reclosing schemes using IEC 61850



Annex B (informative)

Bibliography Bibliographical references are resources that provide additional or helpful material but do not need to be understood or used to implement this standard. Reference to these resources is made for informational use only. [B1] Hohlbaum, F., M. Braendle, and F. Alvarez, “Cyber Security: Practical Considerations for Implementing IEC 62351,”4 [B2] IEC 60255, Electric Relays. 5 [B3] IEC 60255-27, Measuring relays and protection equipment—Part 27: Product safety requirements. [B4] IEC 60870-5, Transmission Protocols. [B5] IEC 60870-5-101, Transmission Protocols—companion standards especially for basic telecontrol tasks. [B6] IEC 60870-5-104, Transmission Protocols—Network access for IEC 60870-5-101 using standard transport proles. [B7] IEC 61000-6-5, Electromagnetic compatibility (EMC)—Part 6-5: Generic standards—Immunity for equipment used in power station and substation environment. [B8] IEC 61400-25, Wind energy generation systems—Part 25: Communications for monitoring and control of wind power plants. [B9] IEC 61588:2009, Precision clock synchronization protocol for networked measurement and control systems. [B10] IEC/TR 61850-1 ed1.0 (2003–04), Communication networks and systems in substations—Part 1: Introduction and overview. [B11] IEC/T 61850–1 ed2.0 (2013–03), Communication networks and systems for power utility automation— Part 1: Introduction and overview. [B12] IEC/TS 61850-2 ed1.0 (2003–08), Communication networks and systems in substations—Part 2: Glossary. [B13] IEC/CEI 61850-3 ed1.0 (2002–01), Communication networks and systems in substations—Part 3: General requirements. [B14] IEC 61850-3 ed2.0 (2013–12), Communication networks and systems for power utility automation— Part 3: General requirements. [B15] IEC/CEI 61850-4 ed1.0 (2002–01), Communication networks and systems for power utility automation—Part 4: System and project management. 4

Available at: http://www.abb.com. IEC publications are available from the International Electrotechnical Commission (http://www.iec.ch) and the American National Standards Institute (http://www.ansi.org/). 5



[B16] IEC 61850-4 ed2.0 (2011–04), Communication networks and systems for power utility automation— Part 4: System and project management. [B17] IEC 61850-5 ed1.0 (2003–07), Communication networks and systems in substations—Part 5: Communication requirements for functions and device models. [B18] IEC 61850-5 ed2.0 (2013–01), Communication networks and systems for power utility automation— Part 5: Communication requirements for functions and device models. [B19] IEC 61850-6 ed1.0 (2004–03), Communication networks and systems in substation—Part 6: Conguration description language for communication in electrical substations related to IEDs. [B20] IEC 61850-6 ed2.0 (2009–12), Communication networks and systems for power utility automation— Part 6: Conguration description language for communication in electrical substations related to IEDs. [B21] IEC 61850-7-1 ed1.0 (2003–07), Communication networks and systems in substation—Part 7–1: Basic communication structure—Principles and models. [B22] IEC 61850-7-1 ed2.0 (2011–07), Communication networks and systems for power utility automation— Part 7-1: Basic communication structure—Principles and models. [B23] IEC 61850-7-2 ed1.0 (2003–05), Communication networks and systems in substation—Part 7-2: Basic information and communication structure—Abstract communication service interface (ACSI). [B24] IEC 61850-7-2 ed2.0 (2010–08), Communication networks and systems for power utility automation— Part 7-2: Basic information and communication structure—Abstract communication service interface (ACSI). [B25] IEC 61850-7-3 ed1.0 (2003–05), Communication networks and systems in substation—Part 7-3: Basic communication structure—Common data classes. [B26] IEC 61850-7-3 ed2.0 (2010–12), Communication networks and systems for power utility automation— Part 7-3: Basic communication structure—Common data classes. [B27] IEC 61850-7-4 ed1.0 (2003–05), Communication networks and systems in substation—Part 7-4: Basic communication structure—Compatible logical node classes and data object classes. [B28] IEC 61850-7-4 ed2.0 (2010–03), Communication networks and systems for power utility automation— Part 7-4: Basic communication structure—Compatible logical node classes and data object classes. [B29] IEC 61850-7-410 ed1.0 (2007–08), Communication networks and systems for power utility automation—Part 7-410: Hydroelectric power plants—Communication for monitoring and control. [B30] IEC 61850-7-410 ed2.0 (2012–10), Communication networks and systems for power utility automation—Part 7-410: Hydroelectric power plants—Communication for monitoring and control. [B31] IEC 61850-7-420 ed1.0 (2009–03), Communication networks and systems for power utility automation—Part 7-420: Basic communication structure—Distributed energy resources logical nodes. [B32] IEC/TR 61850-7-510 ed1.0 (2012–03), Communication networks and systems for power utility automation—Part 7-510: Basic communication structure—Hydroelectric power plants—Modelling concepts and guidelines.



[B33] IEC 61850-8-1 ed1.0 (2008–12), Communication networks and systems in substation—Part 8-1: Specic communication service mapping (SCSM)—Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3. [B34] IEC 61850-8-1 ed2.0 (2011–06), Communication networks and systems for power utility automation— Part 8–1: Specic communication service mapping (SCSM)—Mappings to MMS (ISO 9506-1 and ISO 95062) and to ISO/IEC 8802-3. [B35] IEC 61850-9-2 ed1.0 (2004–04), Communication networks and systems in substation—Part 9-2: Specic communication service mapping (SCSM)—Sampled values over ISO/IEC 8802-3. [B36] IEC 61850-9-2 ed2.0 (2011–09), Communication networks and systems for power utility automation— Part 9-2: Specic communication service mapping (SCSM)—Sampled values over ISO/IEC 8802-3. [B37] IEC 61850-10 ed1.0 (2005–05), Communication networks and systems in substations—Part 10: Conformance testing. [B38] IEC 61850-10 ed2.0 (2012–12), Communication networks and systems in substations—Part 10: Conformance testing. [B39] IEC/TS 61850-80-1 ed1.0 (2008–12), Communication networks and systems for power utility automation—Part 80-1: Guideline to exchanging information from a CDC-based data model using IEC 60870-5-101 or IEC 60870-5-104. [B40] IEC/TR 61850-90-1 ed1.0 (2010–03), Communication networks and systems for power utility automation—Part 90-1: Use of IEC 61850 for the communication between substations. [B41] IEC/TR 61850-90-2 ed1.0 (2016-02) Communication networks and systems for power utility automation—Part 90-2: Using IEC 61850 for communication between substations and control centres. [B42] IEC/TR 61850-90-4 ed1.0 (2013–08), Communication networks and systems for power utility automation—Part 90-4: Network engineering guidelines. [B43] IEC/TR 61850-90-5 ed1.0 (2012–05), Communication networks and systems for power utility automation—Part 90-5: Use of IEC 61850 to transmit synchrophasor information according to IEEE C37.118. [B44] IEC/TR 61850-90-7 ed1.0 (2013–02), Communication networks and systems for power utility automation—Part 90-7: Object models for power converters in distributed energy resources (DER) systems. [B45] IEC/TR 61850-90-12 ed1.0 (2015–07), Communication networks and systems for power utility automation – Part 90-12: Wide area network engineering guidelines. [B46] IEC 62271-3, High-voltage switchgear and controlgear—Part 3: Digital interfaces based on IEC 61850. [B47] IEC 62351, Power systems management and associated information exchange—Data and communications security. [B48] IEC 62351-4, Power systems management and associated information exchange—Data and communications security—Part 4: Proles including MMS. [B49] IEC 62351-6, Power systems management and associated information exchange—Data and communications security—Part 6: Security for IEC 61850.



[B50] IEC 62381, Automation systems in the process industry—Fac tory acceptance test (FAT), site acceptance test (SAT), and site integration test (SIT). [B51] IEC 62439-1, Industrial communication networks—High availability automationnetworks—Part 1: General concepts and calculation methods. [B52] IEC 62439-3, Industrial communication networks—High availability automation networks—Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR). [B53] IEC/ISO 81346–1, Industrial systems, installations and equipment and industrial products – Structuring principles and reference designations – Part 1: Basic rules.6 [B54] IEC/ISO 81346-2, Industrial systems, installations and equipment and industrial products – Structuring principles and reference designations—Part 2: Classication of objects and codes for classes. [B55] IEEE Std 525™, IEEE Guide for the Design and Installation of Cable Systems in Substations.

7,8

[B56] IEEE Std 802.1w™, IEEE Standard for Local and Metropolitan Area Networks—Common Specication. Part 3: Media Access Control (MAC) Bridges—Amendment 2: Rapid Reconguration. [B57] IEEE Std 802.3™, IEEE Standard for Ethernet. [B58] IEEE Std 1588™, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. [B59] IEEE Std 1613™, IEEE Standard Environmental and Testing Requirements for Communications Networking Devices Installed in Electric Power Substations. [B60] IEEE Std 1613.1™, IEEE Standard Environmental and Testing Requirements for Communications Networking Devices Installed in Transmission and Distribution Facilities. [B61] IEEE Std 1615™, IEEE Recommended Practice for Network Communication in Electric Power Substations. [B62] IEEE Std 1686™, IEEE Standard for Intelligent Electronic Devices Cyber Security Capabilities. [B63] IEEE Std 1815™, IEEE Standard for Electric Power Systems Communications-Distributed Network Protocol (DNP3). [B64] IEEE Std 1815.1™, IEEE Standard for Exchanging Information Between Networks Implementing IEC 61850 and IEEE Std 1815(TM) [Distributed Network Protocol (DNP3)]. [B65] IEEE Std C37.1™, IEEE Standard for SCADA and Automation Systems. [B66] IEEE Std C37.2™, IEEE Standard Electrical Power System Device Function Numbers, Acronyms and Contact Designations. [B67] IEEE Std C37.90™, IEEE Standard for Surge Withstand Capability (SWC) Tests for Relays and Relay Systems Associated with Electric Power Apparatus. 6

ISO publications are available from the International Organization for Standardization (http://www.iso.org/) and the American National Standards Institute (http://www.ansi.org/). 7 The IEEE standards or products referred to in Annex B are trademarks owned by the Institute of Electrical and Electronics Engineers, Incorporated. 8 IEEE publications are available from the Institute of Electrical and Electronics Engineers (http://standards.ieee.org/).



[B68] IEEE Std C37.118™, IEEE Standard for Synchrophasors for Power Systems. [B69] IEEE Std C37.240™, IEEE Standard Cybersecurity Requirements for Substation Automation, Protection, and Control Systems. [B70] “Schematic Representation of Power System Relaying,” PSRC I5 report dated 2014/5/13. 9 [B71] Young, J. and D. Haas, “The Importance of Relay and Programmable Logic Documentation.”10

9

Available http://www.pes-psrc.org/Reports/IEEE _I5 _Schematic _Approved _Final.pdf . Available at https://www.selinc.com/WorkArea/DownloadAsset.aspx?id=3513.

10


EE Recommended Practice for Implementing an IEC 61850 Based Substation Communications Protection Monitoring and Control System

Recommend Documents