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

IEEE Recommended Practice for Implementing an IEC 61850-Based Substation Communications, Protection, Monitoring, and Con

Views 72 Downloads 0 File size 4MB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

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

IEEE Power and Energy Society

Sponsored by the Substations Committee

IEEE 3 Park Avenue New York, NY 10016-5997 USA

IEEE Std 2030.100™-2017

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

IEEE Std 2030.100™-2017

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

Substations Committee

of the

IEEE Power and Energy Society Approved 18 May 2017

IEEE-SA Standards Board

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

Abstract: The steps and procedures a user should undertake to implement an IEC 61850 substation in both a single and multi-vendor equipment environment are outlined in this recommended practice. Intelligent electronic device (IED) specification, procurement, configuration, and documentation to develop a general design philosophy that transforms the IEC 61850 standard are addressed in this recommended practice, using this as a practical working implementation guide. A general overview of an IEC 61850 implementation is given in this recommended practice. Future work may develop more detail behind the topics presented herein. Keywords: GOOSE, IEC 61850, IEEE 2030.100™, MMS, sample values, substation automation, SV

The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 2017 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 19 June 2017. Printed in the United States of America. IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers, Incorporated. PDF: Print:

ISBN 978-1-5044-4032-5 ISBN 978-1-5044-4033-2

STD22592 STDPD22592

IEEE prohibits discrimination, harassment, and bullying. For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.

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

Important Notices and Disclaimers Concerning IEEE Standards Documents IEEE documents are made available for use subject to important notices and legal disclaimers. These notices and disclaimers, or a reference to this page, appear in all standards and may be found under the heading “Important Notices and Disclaimers Concerning IEEE Standards Documents.” They can also be obtained on request from IEEE or viewed at http://​standards​.ieee​.org/​IPR/​disclaimers​.html.

Notice and Disclaimer of Liability Concerning the Use of IEEE Standards Documents IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (“IEEE-SA”) Standards Board. IEEE (“the Institute”) develops its standards through a consensus development process, approved by the American National Standards Institute (“ANSI”), which brings together volunteers representing varied viewpoints and interests to achieve the final product. IEEE Standards are documents developed through scientific, academic, and industry-based technical working groups. Volunteers in IEEE working groups are not necessarily members of the Institute and participate without compensation from IEEE. While IEEE administers the process and establishes rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained in its standards. IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure against interference with or from other devices or networks. Implementers and users of IEEE Standards documents are responsible for determining and complying with all appropriate safety, security, environmental, health, and interference protection practices and all applicable laws and regulations. IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and expressly disclaims all warranties (express, implied and statutory) not included in this or any other document relating to the standard, including, but not limited to, the warranties of: merchantability; fitness for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness of material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort. IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.” Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE standard. IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.

3

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.

Translations The IEEE consensus development process involves the review of documents in English only. In the event that an IEEE standard is translated, only the English version published by IEEE should be considered the approved IEEE standard.

Official statements A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of that individual rather than the formal position of IEEE.

Comments on standards Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of membership affiliation with IEEE. However, IEEE does not provide consulting information or advice pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is important that any responses to comments and questions also receive the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to comments or questions except in those cases where the matter has previously been addressed. For the same reason, IEEE does not respond to interpretation requests. Any person who would like to participate in revisions to an IEEE standard is welcome to join the relevant IEEE working group. Comments on standards should be submitted to the following address: Secretary, IEEE-SA Standards Board 445 Hoes Lane Piscataway, NJ 08854 USA

Laws and regulations Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory requirements. Implementers of the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so.

Copyrights IEEE draft and approved standards are copyrighted by IEEE under US and international copyright laws. They are made available by IEEE and are adopted for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making these documents available for use and adoption by public authorities and private users, IEEE does not waive any rights in copyright to the documents.

4

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.

Photocopies Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to photocopy portions of any individual standard for company or organizational internal use or individual, non-commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center.

Updating of IEEE Standards documents Users of IEEE Standards documents should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. Every IEEE standard is subjected to review at least every 10 years. When a document is more than 10 years old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE standard. In order to determine whether a given document is the current edition and whether it has been amended through the issuance of amendments, corrigenda, or errata, visit the IEEE Xplore at http://​ieeexplore​.ieee​.org/​ or contact IEEE at the address listed previously. For more information about the IEEE-SA or IEEE’s standards development process, visit the IEEE-SA Website at http://​standards​.ieee​.org.

Errata Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL: http://​ standards​.ieee​.org/​findstds/​errata/​index​.html. Users are encouraged to check this URL for errata periodically.

Patents Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEESA Website at http://​standards​.ieee​.org/​about/​sasb/​patcom/​patents​.html. Letters of Assurance may indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses. Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards Association.

5

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.

Participants At the time this IEEE recommended practice was completed, the C15 Working Group had the following membership: Rick Liposchak, Chair Alex Apostolov Farel Becker Jim Bougie Christoph Brunner Craig Bryant Fernando Calero Ed Cenzon Mike Dood Ron Farquharson Anand Fernando Jalal Gohari

J. Gosalia Richard Harada Yi Hu Gregory Huon Suhail Hussain Mansour Jalali Anthony Johnson Marc Lacroix Jason Lapenta Alex Lee Deepak Maragal Bruce Muschlitz

Henry Pinto Craig Preuss Qun Qiu Peter Rietmann Grant Ringham Sam Sciacca Eric Thibodeau Tim Tibbals Benton Vandiver Clarence Wallace Adrian Zvarych

The following members of the individual balloting committee voted on this recommended practice. Balloters may have voted for approval, disapproval, or abstention. William Ackerman David Aho Ali Al Awazi Jay Anderson Philip Beaumont Jim Bougie Jeffrey Brogdon William Byrd Paul Cardinal Christopher Chelmecki Randall Crellin Ratan Das Mike Dood Neal Dowling Jiyuan Fan Kenneth Fodero Dominick Fontana Fredric Friend Mietek Glinkowski Jalal Gohari Edwin Goodwin Roman Graf Randall Groves Nathan Gulczynski Roger Hedding Lee Herron

Werner Hoelzl Gary Hoffman Yi Hu C. Huntley Richard Jackson Innocent Kamwa Piotr Karocki Yuri Khersonsky James Kinney Joseph L. Koepfinger Boris Kogan Richard Kolich Jim Kulchisky Raluca Lascu Charles Lennon Albert Livshitz Lawrence Long Pierre Martin John McDonald R. Murphy Bruce Muschlitz Arthur Neubauer Michael Newman Gary Nissen James O'Brien

Lorraine Padden Richard Paes Charles Pestell Charles Rogers Thomas Rozek Ronald Rumrill Ryandi Ryandi Daniel Sabin Miriam Sanders Steven Sano Bartien Sayogo Thomas Schossig Mark Simon Jerry Smith Yuyin Song David Tepen Eric Thibodeau Michael Thompson Joe Uchiyama James Van De Ligt John Vergis Ilia Voloh John Wang Kenneth White Robert Wilson Jian Yu

6

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.

When the IEEE-SA Standards Board approved this recommended practice on 18 May 2017, it had the following membership: Jean-Philippe Faure, Chair Gary Hoffman, Vice Chair John D. Kulick, Past Chair Konstantinos Karachalios, Secretary Chuck Adams Masayuki Ariyoshi Ted Burse Stephen Dukes Doug Edwards J. Travis Griffith Michael Janezic

Thomas Koshy Joseph L. Koepfinger* Kevin Lu Daleep Mohla Damir Novosel Ronald C. Petersen Annette D. Reilly

Robby Robson Dorothy Stanley Adrian Stephens Mehmet Ulema Phil Wennblom Howard Wolfman Yu Yuan

*Member Emeritus

7

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.

Introduction This introduction is not part of IEEE Std 2030.100™-2017, IEEE Recommended Practice for Implementing an IEC 61850-Based Substation Communications, Protection, Monitoring, and Control System.

This recommended practice is not intended to help equipment and software vendors in implementing the basic functions of IEC 61850 into their products, although they could use it to gain a perspective of how the end user may implement IEC 61850 with their products. This recommended practice is intended for the end user who is responsible for the planning and design of parts or all components of the IEC 61850 standard within a substation. Due to the nature and scope of IEC 61850, this recommended practice may be broken into several related standards. This introduction standard is the first in that series of standards to be developed that will go into detail covering a specific function within the standard.

8

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.

Contents 1. Overview��������������������������������������������������������������������������������������������������������������������������������������������������� 10 1.1 Scope�������������������������������������������������������������������������������������������������������������������������������������������������� 10 1.2  IEC 61850 changes and additions������������������������������������������������������������������������������������������������������� 10 1.3 Purpose����������������������������������������������������������������������������������������������������������������������������������������������� 10 2.  Definitions, acronyms, and abbreviations������������������������������������������������������������������������������������������������� 11 2.1  Definitions������������������������������������������������������������������������������������������������������������������������������������������ 11 2.2  Acronyms and abbreviations�������������������������������������������������������������������������������������������������������������� 11 3.  What IEC 61850 offers������������������������������������������������������������������������������������������������������������������������������ 13 3.1  IEC 61850 object model��������������������������������������������������������������������������������������������������������������������� 16 3.2  Ethernet network�������������������������������������������������������������������������������������������������������������������������������� 26 3.3 Protocols��������������������������������������������������������������������������������������������������������������������������������������������� 29 3.4  Time synchronization������������������������������������������������������������������������������������������������������������������������� 34 3.5  Data transfer performance measures�������������������������������������������������������������������������������������������������� 34 3.6  Environmental standards�������������������������������������������������������������������������������������������������������������������� 37 3.7  Configuration tools����������������������������������������������������������������������������������������������������������������������������� 39 3.8  Communications between substations������������������������������������������������������������������������������������������������ 39 3.9  SCADA master communications�������������������������������������������������������������������������������������������������������� 40 3.10 Interoperability��������������������������������������������������������������������������������������������������������������������������������� 41 3.11  Backward compatibility�������������������������������������������������������������������������������������������������������������������� 43 3.12  User processes���������������������������������������������������������������������������������������������������������������������������������� 45 4.  User considerations����������������������������������������������������������������������������������������������������������������������������������� 47 4.1  Business case�������������������������������������������������������������������������������������������������������������������������������������� 47 4.2 Adoption��������������������������������������������������������������������������������������������������������������������������������������������� 50 4.3  Implementation plan��������������������������������������������������������������������������������������������������������������������������� 52 4.4  Testing, troubleshooting, and maintenance����������������������������������������������������������������������������������������� 56 4.5  General cybersecurity comments������������������������������������������������������������������������������������������������������� 59 5.  Critical success factors������������������������������������������������������������������������������������������������������������������������������ 59 Annex A (informative) Examples for future 2030.100 Project Authorization Request (PAR)s���������������������� 60 Annex B (informative) Bibliography������������������������������������������������������������������������������������������������������������� 61

9

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.

IEEE Recommended Practice for Implementing an IEC 61850-Based Substation Communications, Protection, Monitoring, and Control System 1. Overview 1.1 Scope This recommended practice outlines the necessary steps and procedures implementers of IEC 61850 in substations should undertake in a multi-vendor equipment environment. It is not the intent of this recommended practice to change the IEC 61850 standard, but treats the standard as providing a set of tools engineers and integrators could use in substation protection, automation, and control systems.

1.2  IEC 61850 changes and additions The IEC 61850 standard is a constantly evolving standard with plans to update existing parts with new editions and create additional parts to the standard. At the time of this publication the IEC 61850 documents listed in the bibliography (Annex B) were considered ([B10] through [B45]).1

1.3 Purpose IEC 61850 has been promoted as an interoperability standard, but to date, interoperability among vendors has been achieved only at a communications level. When actually implementing the various substation functions, the user could be forced to change methods between vendors due to the flexibility and options provided for in IEC 61850. Additionally, IEC 61850 requires significant changes to the design, construction, and commissioning of a substation. Hard-wired signals are replaced by logical bits being communicated over Ethernet networks, documentation and naming conventions are distinctly different from existing substation practice, and device functionality could be assigned, and even migrate, in an operational environment. Users will also require a methodology to integrate IEC 61850 and non-IEC 61850 operational practices in their system as both approaches will have to exist side by side for many years. This recommended practice will provide a starting point for those users who would like to migrate to an IEC 61850 substation approach and 1

The numbers in brackets correspond to those of the bibliography in Annex B.

10

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.

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

establish baseline functionality to which vendors could adhere with confidence of achieving interoperability with other vendors. This guide is not intended to replace or change the IEC 61850 standard; users who implement IEC 61850 should reference the standard’s sections that apply to their implementation. This guide will help users understand the sections that most affect the end users of IEC 61850 equipment and software, and gives users additional insight into other areas to consider outside of the scope of the IEC 61850 standard. This recommended practice is a starting point for a series of additional recommended practices to provide implementation details in many specific functional areas of IEC 61850. Each additional subject matter will be given an extension off the existing standard number for this guide, 2030.100.1, 0.2 … 10 … etc. (For examples, see Annex A). This recommended practice provides a general overview of the concepts and tools provided within IEC 61850 with some general considerations the user should be aware of prior to, during, and after an IEC 61850 implementation. The following are examples of specific functional areas that would be good future extensions to this recommended practice: —— Using generic object oriented substation event (GOOSE) messages for protection trips and permissives, and interlock control blocking —— Implementing a line or feeder reclose function —— Combining logical nodes to achieve a variety of protection functions —— Implementing various local/remote configurations —— Using sample values (SV) messages for protection and metering applications —— Recommending substation and process bus network design and configuration (as a companion to the IEC-61850-90 series of reports ([B40] through [B45]) including networking topics) —— Merging IEC 61850 into an existing substation automation system

2.  Definitions, acronyms, and abbreviations 2.1  Definitions The IEEE Standards Dictionary Online should be consulted for terms not defined in this clause.2 This document uses acronyms, terms, and definitions that are defined in the IEC 61850 standard and are commonly used in the power industry.

2.2  Acronyms and abbreviations CDC

common data classes

CHP

combined heat and power

CID

configured IED description

CIM

common information model

DER

distributed energy resources

DNP

distributed network protocol

EMI

electromagnetic interference

2

IEEE Standards Dict ionary Online is available at: http://​dictionary​.ieee​.org.

11

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.

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

ESP

energy service provider

EV

electric vehicle

FAT

factory acceptance test

FTP

file transfer protocol

GGIO

generic input/output

GOOSE

generic object oriented substation event

HMI

human machine interface

HSR

high-availability and seamless redundancy

ICD

IED capabilities description

IED

intelligent electronic device

IID

instantiated IED description

IRIG

inter-range instrumentation group

ITPC

teleprotection communication interfaces

LAN

local area network

MAC

media access control

MDIF

differential measurements

MICS

Model Implementation Conformance Statement

MMS

manufacturing message specification

MVRP

multiple VLAN registration protocol

NERC

North American Electric Reliability Corporation

NIC

network interface controller

PAR

Project Authorization Request

PICOM

piece of information for communication

PICS

Protocol Implementation Conformance Statement

PIXIT

Protocol Implementation Extra information

PPS

pulse per second

PRP

parallel redundancy protocol

PSCH

protection scheme

PTP

precision time protocol

PV photovoltaic RAS

remedial action scheme

ROI

return on investment

RREC

reclosing logical node

RSTP

rapid spanning tree protocol

RTU

remote terminal unit

RXML

differential measurements

12

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.

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 configuration description

SCL

Substation Configuration Language

SED

system exchange description

SFTP

Secure Shell file transfer protocol

SICS

SCL implementation conformance statement

SIPS

system integrity protection schemes

SNMP

simple network management protocol

SNTP

simple network time protocol

SSD

system specification 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 offers Unlike IEEE  Std  1815™ [B63], the IEC 61850 standard is more than just a protocol specification. As a standard, it offers several protocols, project management, conformance testing, object models, configuration 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 —— Configuring 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.

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

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 —— Configuration 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 profile 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) —— Buffered/unbuffered 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]

14

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.

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

—— 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) file schema and well defined logical name sets enabling offline configuring IEDs and a standardized means to communicate between functional engineering groups —— Manufacturing message specification (MMS) messaging with substation-wide direct polls or configured data sets in a client-server arrangement enabling easy configuration 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 defined 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 defined 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 different aspects that need to be considered for using IEC 61850 for applications between substations. In particular this defines the required information exchange, communication services/architecture, and enhancements of the configuration language, SCL. —— IEC 61850-90-5 [B43] provides for the exchange of synchrophasor data (as defined in IEEE Std C37.118™ [B68]) within a WAMPAC (wide area monitoring, protection, and control) sytem for desired applications. This also provides routable profiles for IEC 61850-8-1 GOOSE and IEC 61850-9-2 SV packets to enable applications between control centers. —— IEC 61850-90-7 [B44] defines 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] defines 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 defined 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.

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

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: —— Identifies key elements of the standard that impact end user implementations —— Provides a general introduction to the concepts —— Offers some tips and suggestions These overviews are not intended to replace the standard. If a user requires a deeper understanding or access to definitions 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 defines a Substation Configuration Language (SCL) schema that allows any vendor configuration tool to read the IEC 61850 files created in a different 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 defined 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 configuring their IEC 61850 system using a SCL configuration tool will find themselves exposed to different concepts than they may be accustomed to for modeling their substation. Using this standard model creates the links between the substation’s electrical circuit configuration, 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.

16

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.

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

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

Figure 2—IEC 61850 SCL model Figure 3, Figure 4, and Figure 5 show the three different 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

17

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.

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

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

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

18

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.

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

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

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

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

19

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.

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

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

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 find 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 first 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 different 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.

20

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.

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

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 fixed 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 different 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 first must identify the software they wish to use to start their IEC 61850 configuration. Then there are steps to read the IED capabilities description (ICD) files from the devices and complete some vendor specific configuration using the vendor tools, which create a configured IED description (CID) file on the device. If a user wishes to subscribe to other devices’ published GOOSE messages or SV messages, the vendor’s configuration software will ask you for that device’s IEC 61850 configuration file, 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 configuration, 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 files The user will find a number of different named files defined in the IEC 61850 standard that all contain specific information using standard IEC 61850-defined XML schemas. Depending on the level at which the user implements the SCL model, the user may not see a number of these file types. Table 1 includes a description of their intended use and the IEC 61850 edition with which they are associated. Table 1—XML file descriptions File

Description

Edition 1

Edition 2

ICD

This is an IED Capabilities Description (ICD) file 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) file that provides information about a configured IEC 61850 device to an IEC 61850 System Configuration Tool.

No

Yes

CID

This is a Configured IED Description (CID) file that exchanges configuration information between the device and the vendor IED configuration tool.

Yes

Yes Table continues

21

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.

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

Table 1—XML file descriptions (continued) File

Description

Edition 1

Edition 2

SSD

This is a System Specification Description (SSD) file that exchanges information between the System Specification Tool and the System Configuration Tool.

Yes

Yes

SCD

This is a System Configuration Description (SCD) file that exchanges information between the System Configuration Tool and the Vendor IED Configurator Tool.

Yes

Yes

SED

This is a System Exchange Description (SED) file that exchanges information between the System Configuration Tool and other IEC 61850 projects.

No

Yes

Figure 6 provides a general overview on how the different file types are used in a complete IEC 61850 system.

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

Figure 6—SCL model file transfer The standard does not layout a configuration procedure that must be followed. The standard offers a set of files with a suggested use, where the user determines the tools based on their specification to the vendor. An IEC 61850 configuration could be as simple as using each vendor’s configuration software for each device, loading the individual CID files into that configuration 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 first 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

22

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.

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

The remaining three letters represent a specific 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 fixed by the standard and has an index number at the end of the four letter name to separate different data definitions within the specific function such as PTOC01, PTOC02, … PTOC99. There is also an optional prefix that could be applied to the four letter LN name to give the LN name additional meaning such as adding a “pha” prefix to “PTOC01”. This prefix would indicate that the PTOC (Protection Time Overcurrent) LN is for the phase A part of the circuit. Having a prefix for the LN is optional in the IEC 61850 standard and there are no guidelines for their naming or use. If there is a prefix, in most cases the vendor will supply the IED with a fixed prefix 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 Configuration, etc. The data object name follows semantics, which are defined in IEC 61850-7-4 [B27], [B28], giving the user the definition of the name. Also assigned to the data object under the logical node is the Common Data Class, which defines 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 fixed 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 offer a logical node that defines a function supported by the IED. For Edition 1 IEDs, in place of using the IEC 61850 defined 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 defined 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.

23

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.

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

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

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 definitions 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 different data object meanings. —— IEC 61850 defines 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 defined 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 difficult 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 defined in Edition 1. —— Vendors may fix 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 configuration 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 fixed by the vendor or programmable by the user?

24

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.

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

—— The standard allows for a prefix to be attached to the four letter logical node name, which is followed by an index number. Only the prefix part of the name can be modified. A vendor may fix this prefix 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 identifies 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 fixed 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 different 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 configurations 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 configuration tools only require the other IED’s ICD, IID, or CID file to subscribe to GOOSE and SV messages, not the complete system model files. Therefore, a user is not required, in most cases, to complete a full IEC 61850 system model using an IEC 61850 system configuration tool. In this case, the user first uses a vendor tool to configure the GOOSE/SV publisher and then the ICD/IID/CID file 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 configuration 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 file 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 files.

25

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.

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

• 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 first 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 fixed by the standard and only the prefix to this name can be modified if allowed by the vendor’s IED configuration 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 configuration 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 different sections of the LAN. Different sections of the LAN can also be built with different speeds and often with different types of media; either copper or optical fiber 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.

26

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.

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

There can be a number of physically separated LANs at the process level, which in some cases are confined to bays. The LAN configuration specified 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 specifies the physical layer connection options as fiber and copper. The differences 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 field, which introduces additional failure points for the fiber 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 specification, there is also no specification 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 specifies network speeds (Edition 2 of IEC 61850 does include an option for a gigabit fiber 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 different 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 traffic, filtering needs to be done at the Ethernet switches such that the multicast traffic reaches only those links where subscribing IEDs are located to meet the performance requirements specified. Gigabit ports for process bus on bus protection relays may also be required to reduce the latency and traffic 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 traffic 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 traffic. 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] specifies operation in extreme temperature and EMI conditions. Edition 2 [B14], however, expands these requirements significantly, including the error free requirements from

27

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.

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

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 specific 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 fiber ring where each device has two HSR aware configured fiber 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 first 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 first implementation: —— Optical fiber is required to obtain the performance of GOOSE and process bus under the demanding substation environment defined 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.

28

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.

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

—— 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 configuration should go through the same review procedures as applied to protection settings, because network design and configuration can adversely impact the response time of the protection and control functions. It is likely that the design and configuration will change as the network is tested to see if it meets the performance requirements. —— Network redundancy protocols affect how the network behaves under failure modes, such as cable or switch failure, and the available protocols provide different 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 first implementation. —— Vendors offer many products that have dual Ethernet connection points but how these connections can be used will differ. 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 first 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 first 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 defined 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 configured 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.

29

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.

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

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

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 certification test results confirming 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 differs from the GOOSE in that the SV uses periodic messages with a specified periodicity that never changes. These messages also use the VLAN and priority tagging, which must be properly configured 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 defined in the standard with various ranges open to vendors, such as sample

30

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.

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

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 configuration 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 differs from the GOOSE message in how it transmits the information. It is a continuous stream of synchronized sampled values.

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

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 fixed 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.

31

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.

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

3.3.3  MMS (manufacturing message specification) MMS existed well before IEC 61850 and was chosen as the application protocol for logical node data, control commands, control block data, reports, files, and logs. Under normal conditions, understanding the structures or mechanisms used by MMS to transfer information is not necessary. Network sniffers 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 specific data address. The second is a client-server connection to a report within a logical device that contains a data set that can be fixed by the vendor or generally user configurable. There are two types of reports, buffered and unbuffered. Buffered 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. Unbuffered 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 configurable 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 flow and control for both the report and log MMS functions.

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

Figure 10—MMS report and log data flow 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.

32

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.

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

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 effective means to pass information from the IED (server) to a client, such as a data gateway or HMI. The report control block allows for different methods of retrieving data such as an integrity poll, data change, quality change, etc. A data set may be configured 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-configured 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 specifies 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 specifies MMS file services as a method to transfer files from the IEC 61850 device. Additionally, many devices support optional file transfer protocol (FTP) and Secure Shell file transfer protocol (SFTP) services for file 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 difficult 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 specific configuration software. —— IEDs will have different 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 buffered report will only allow for single client connections. An un-buffered 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 configurable and not include the required data that is otherwise available in a supported logical node. —— Some IED server’s MMS report configuration requires special control flag settings to be accomplished before a report connection is made. —— Determine if the IED supports 61850 file transfer mechanism. For example, if a client needs a file and only supports MMS file transfer, while the server only supports FTP or SFTP file transfer, no files will be transferred.

33

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.

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

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 configured and, if allowed by the vendor, change the control block parameters using MMS. The IEC 61850 standard also defines 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 specification.

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 configuration. —— 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 defining 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

Transfer Time

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 P2 Hz 8 ms for 60 Hz

TT5, ≤ 10 ms Table continues

34

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.

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

Table 2—Message performance requirements (continued) Message Description

Edition 1 Type

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

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

Performance Class

Edition 2 Transmission Time

Type

Transmission Time

Performance Class

Transfer Time

1B

20 ms for 50 Hz 17 ms for 60 Hz

P3

TT4, ≤ 20 ms

P1

≤ 100 ms

P2/P3

≤ 20 ms

2

 

≤ 100 ms

2

 

P4

TT3, ≤ 100 ms

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)

P5

TT2, ≤ 500 ms

3

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

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 specified by the customer

3.0 ms

TT1, ≤ 1000 ms

3.0 ms P3: applies typically to a transmission bay with top performance synchronizing feature and breaker differential Table continues

35

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.

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

Table 2—Message performance requirements (continued) Message Description

Edition 1

Edition 2

Type

Performance Class

Transmission Time

Type

Transmission Time

Performance Class

Transfer Time

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

5

 

≥ 10 000 ms

5

10, 000 ms fit very well the file transfer requirements

P9

TT0, ≤ 10 000 ms

Command messages and file 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

 

 

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

Time synchronization messages

6

Does not apply

Does not apply

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

Despite the differences in the editions, these performance classes allow separation of the various messages into groups with different requirements. But when messages with different performance classes are transmitted over the same network segment, that network segment must be designed and configured 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 different performance classes than those given in the standard. The issue with defining the performance classes is that there is no mechanism in IEC 61850 to actually measure the transfer time as required in the different 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

36

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.

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

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 verifies the handling of VLANs using GOOSE messages with different VIDs —— Simple priority tagging, which verifies 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 verifies that the specific multicast (SV or GOOSE) messages are received on the configured ports and not received on other ports —— Simple RSTP recovery, which verifies the recovery of a single communication failure and measures the recovery time as well as the number of packet drops —— Simple HSR, which verifies that on connection failure, no packets are dropped or delayed —— Simple PRP, which verifies that on connection failure, no packets are dropped or delayed —— Simple PTP, which verifies PTP performance, master clock switchover, start-up convergence time, and offest 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 specifications. —— It is very difficult, 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 difficult 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 specifications.

37

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.

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

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 specific 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 differences in the specified 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 significantly different and vendors should be consulted on which edition is actually being certified 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 differences in compliance levels adversely impact the desired performance of the overall system. For example, the tested operating temperature range of some IEDs may be different and still compliant; however, some operate at a higher temperature range than others. If an IED is operated at a higher temperature than is certified, it may fail. If all of the functions the IED performs are non-essential, the user could accept its use despite the difference 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 figures of a standard are given for information only and do not contain requirements needed to implement this standard.

38

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.

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

3.7  Configuration tools A vendor’s IEC 61850 configuration software tool may not allow the user to fully configure a multi-vendor system. Vendors typically offer IEDs compliant with IEC 61850 while still offering equipment and software features that set them apart. Some vendors may one day offer configuration tools that will work with IEDs from every vendor. Issues typically arise with multi-vendor systems using custom logical nodes. When considering configuration tools, the user should understand the following: —— Each vendor offers a configuration software tool that is a small part of a whole IEC 61850 system configuration. —— A single third party tool will not likely be able to do everything that a vendor’s tool will perform. —— An IEC 61850 SCL configuration tool does not replace the vendor’s IED IEC 61850 configuration tool. —— IEC 61850-6-2010 [B20] added Annex G, SCL Implementation Conformance Statement (SICS), which vendors of system configuration tools and IED configuration 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 specific 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 differential 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:

39

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.

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

—— Describes that not all interfaces defined in IEC 61850 (Interfaces 1 through 10 as first defined 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 file transfer and command messages with access control. —— Creates a new Interface 11 for automatics. —— Defines 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 (differential measurements) logical node in Edition 2 [changed from MDIF (differential measurements) in Edition 1]. —— Discusses the configuration aspects of IEDs in multiple substations; in particular, using the SED SCL file 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 defined 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).

40

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.

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

—— 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 specification.

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 different ways, resulting in incompatibilities between logical nodes, GOOSE communications, reporting features, and IED configurability. 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 specification —— Procurement —— Design and configuration —— System commissioning —— Operation —— Maintenance 3.10.1  User specification At the user specification stage, interoperability can be problematic when the user tries to define the substation system using the SSD file according to IEC 61850-6 [B19], [B20]. The SSD file 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 defined in Annex G of Edition 2 of IEC 61850-6:2009 [B20] and the UCAIug provides a tool Conformance Testing and respective certification for the SICS. Vendors must be able to import the SSD file into their configuration tools. It is not yet commonplace for a user specification to include the SSD file, because few tools are able to create the file and many vendor tools typically are unable to import the file and use it. The file could be manually created, but this would likely increase interoperability issues. Many times a user specification will be written using different approaches to the written specification and bill of material. On the lower end are general specifications that only include a general requirement to build a substation that is “IEC 61850 compliant.” These specifications may include different 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 specifications that provide extensive written requirements with different levels of bill of materials. But this approach can also have problems.

41

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.

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

When developing a user specification, 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 configuration templates to the bidder prior to design beginning; the bidder providing sample configuration 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 final IED configuration files is split between the multiple parties developing them, one should be responsible as the lead to provide overall control of the IED configuration files so that a single cohesive file 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 specific environmental requirements so the whole system performs under the same environmental conditions. —— Including specific 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 specified 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 certification. —— 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 specification 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 file, which will require that the owner already has a tool that will work will all vendors required by the specification. 3.10.2 Procurement Once the specification is issued to the bidders, proposals will be submitted and evaluated. Depending upon the project approach, quality of the specification, and quality of bidder responses, the evaluation can be difficult. Several bidders may be invited to present their proposal, perhaps even demonstrating their solution. Upon final evaluation, the contract is awarded and the project begins based upon the specification’s requirements. If this is the first implementation, then the procurement of a test or laboratory system is highly recommended. Ideally, the test system should already exist so that a quality specification can be created. In some cases, this is not possible, sometimes because the project is for a single substation whose budget cannot afford the procurement of a test system. Other times, the test system can be included in the procurement and provided by

42

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.

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

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 configuration takes place. 3.10.3  Design and configuration Most interoperability issues occur during the design and configuration stage, as the implementation begins and devices are configured. The magnitude of the issues can vary in relationship with the quality of the original specification and the differing roles for the project. If no test system is specified and few design reviews are required, the user may find little opportunity to become aware of the problems being encountered in implementation when the vendor is only providing a final, configured system. The design and configuration 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 configuration process, it may be critical to provide sufficient consistent documentation to describe the intended configuration 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 first 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 specification. 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 difficult, 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 verified during testing. 3.10.6 Maintenance Interoperability issues can arise during maintenance activities, but these should be limited to vendors updating firmware and configuration 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 field.

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 specifications of editions and their differences. As already noted in previous sections, some parts of IEC 61850, such as part 3, have undergone significant transformation and great improvement. Each part in Edition 2 provides a different 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.

43

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.

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

Some argue that specifying IEC 61850 should be more than just specifying “Edition 1” or “Edition 2.” Many vendors do not differentiate between editions within their published documentation. This clause addresses the following issues: —— Differences 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  Differences between editions The differences between editions are not well documented with Edition 1 and 2. Edition 2 is a significant improvement on Edition 1, for too many reasons to list herein, but at a high level, the following are some significant 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 different 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 firmware upgrade, not just a firmware upgrade.

44

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.

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

—— Support of HSR and PRP will likely cause a hardware and firmware change, which depends upon the IED architecture as to whether this can be accomplished in the field, 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 firmware 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 significant 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 identified 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] clarifies that TISSUES are technical issues that vendors must transparently state in their documentation that they have implemented fixes. —— IEC 61850-10 [B38] states that the TICS is a statement with IED-specific 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 significant 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, significant hurdles can develop that can derail implementations. For example, Table 3 shows the potential impacts on substation, network, and fiber expertise when implementing IEC 61850 with MMS, GOOSE, and process bus. Table 3—Process impacts for implementation Expertise

Experience levels

Substation

No experience with fiber

Engineering/ Design

Construction

Operation and maintenance

L

M

H

L

M

H

L

M

H

 

 

X

 

 

X

X

 

 

Some experience with fiber

 

X

 

 

X

 

X

 

 

Deployed fiber

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

45

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.

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

Table 3—Process impacts for implementation (continued) Expertise

Network

Fiber

Experience levels

Engineering/ Design

Construction

Operation and maintenance

L

M

H

L

M

H

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 fiber

 

 

X

 

 

X

X

 

 

Some experience with substation fiber

 

X

 

 

X

 

X

 

 

Deployed substation fiber

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 different 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 fiber cables, patch panels, and connectors (refer to 3.2.1.6). Unfamiliarity with optical fiber cable specifications, design requirements, installation, splicing, connectors, termination in patch panels, pathways (tray and conduit), and testing may represent a significant challenge to the organization that has never installed optical fiber cables anywhere in the enterprise. Skills, experience, installation procedures, testing programs, and designs from other types of optical fiber 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 staff 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 fiber optic cables to the yard and routes that may not traditionally be supported by outdoor substation conduit design. —— Any documentation can be significantly 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.

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

4.  User considerations Success at implementing IEC 61850 depends upon the definition of success, using the following different approaches: —— Internal implementation with limited outside support, pilots may or may not be included using different 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 quantifiable business case, or cost benefit (return on investment (ROI)). Developing a business case for any substation automation implementation is a very complex and company-specific 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 retrofits 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 first, 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

47

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.

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

—— Schedule —— Technology refresh 4.1.1  Cost and considerations The business case must include the expected reductions in costs for new and retrofit 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 offset by the additional costs associated with substation network, construction, testing, and relay technicians being able to effectively work together to test and troubleshoot Ethernet networks that support the implemented functions. Some potential cost reductions and benefits 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 offset 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 field 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

48

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.

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

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 redefined. —— 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 benefits that come later with implementing a new standard. This is because it is difficult to anticipate benefits derived from applications that are not yet conceived. This is somewhat a “build it and they will come” benefit of deploying the technology, a result of the toolbox in IEC 61850 that allows engineers to develop new applications to solve problems more effectively 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 specifically identified in Edition 1, the technical issue resolution process is described within Edition 2. These TISSUES can cover many different 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 significantly 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 first 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.

49

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.

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

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 firmware upgrades to all or some IEDs to a complete substation retrofit. 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 difficult 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 effectively 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 fiber 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 configuration tools. —— Operations personnel will need training so they can develop a new set of operating instructions for IEC 61850 modified 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 offered 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 different 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.

50

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.

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

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 configuration/change management When evaluating a vendor’s IEC 61850 offering, part of that evaluation should include evaluating their IED configuration tools and system configuration 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 configuration file without manually editing the file to make it compatible. Adopting IEC 61850 may require frequent file changes for both configurations and firmware, 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 field, resulting in new firmware 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 configuration changes during testing and commissioning. In any case, interoperability issues can range in impact from small (simple firmware changes) to significant (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 configuration-change safeguards built in that require new configuration 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 reflect their choices in hardware and software architecture. For example, conversion from one edition to another can be anything from a simple firmware upgrade, to a module change that requires the IED to be sent to the factory (not field replaceable), to a completely new hardware platform under the same product family, or to a completely new product with a completely different form factor than the old model. Many of these file 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 configuration and firmware files can be a complicated process; it is strongly recommended that a centralized configuration management system be developed and employed. A configuration 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.

51

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.

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

4.2.3  User/Vendor/System integrator partnership For the sake of expediency in “getting started” with IEC 61850, some users approach their first 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 conflicts 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/field modifications. —— 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 specification that implements the parts of IEC 61850 that meets the identified 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 configurations, configuration 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 specific technologies. When adopting IEC 61850, there are specific modifications 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.

52

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.

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

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 —— Configuration —— 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 signals between IEDs, for example, trip circuits for bus differential, 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 modifications 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 offered 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 different 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).

53

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.

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

—— 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 flows, and programmable logic. An approach to documentation will need to be developed, which first 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 traffic and possible failure modes. The IEC 61850-90 series ([B40] through [B45]) provides some guidance on how a user could configure their networks, but the networks still need to be designed to meet the worst case scenarios laid out in the users’ specification. 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 fiber 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 specified 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 flows should be documented as part of the logical design in a data flow diagram. This diagram shows all data flows 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  Configuration One common misperception is that IEDs implementing IEC 61850 are “plug and play” and mapping data from IED to another is eliminated. IEDs require configuration specifically for the communications of IEC 61850 information between IEDs, data concentrators (gateways or RTUs), and HMIs. A configuration plan addresses how configurations will be documented, created, stored, and revised. Additionally, common tools to configure IEDs from multiple vendors are generally not available, so it is necessary to become proficient in multiple configuration tools. The configuration plan should examine not only the vendor’s documentation, but also the software applications. This detailed review may provide insights into configuration settings and procedures that are not well described in the other. Feedback should be provided to the vendors when this situation occurs.

54

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.

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

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 firmware, plus configurations. As conditions change at the facility over time, this documentation must be kept up to date. Document management systems and configuration 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 configurations prior to loading in the field IEDs —— Investigation/troubleshooting of IED and network configuration 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 field 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 field. 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 specifications 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 significantly impacted during a transition to IEC 61850. Previous discussion on interoperability (see 3.10) has covered testing as well as operation and maintenance.

55

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.

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

4.4.1 Testing IEC 61850-4 [B15], [B16] discusses different 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]

IEEE Std C37.1 [B65]

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 different 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.

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

Verification test

Customer specific verifications 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 fulfillment of the technical requirements.

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 certified 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

56

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.

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

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 defined, specific 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 specific configuration and parameter settings. When required, the successful finishing of the FAT results in equipment delivery to the site and commissioning. The contents of the FAT have no additional specific 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 verification 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 verifies 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 final configurations.

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 specific 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 verification 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 verification 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:

57

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.

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

—— Protocol analyzers —— Vendor software applications —— Manuals and documentation for system components, protocols, and IEDs —— Help files 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 defined 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 configuration software applications (see “Schematic Representation of Power System Relaying, [B70], and Young and Haas [B71]). 4.4.3 Maintenance IEC 61850-4 [B15], [B16] defines 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 configuration 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 field 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

58

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.

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

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, specifically IEC 62351-6 [B49], which covers the following issues: —— For Client/Server communication using TCP/IP based protocols like MMS, IEC 62351-6 [B49] specifies security primarily through transport layer security [(TLS) as defined 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 specified for these protocols. —— Other IEEE standards can also be applied to substation automation systems using IEC 61850: —— IEEE Std 1686™ [B62] specifies 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 benefits (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 specification. —— Create a well defined implementation plan. —— Test new technologies in a simulated testing laboratory. —— Educate everyone that is affected 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 first installation and make the required revisions.

59

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.

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

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

60

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.

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

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 profiles. [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. 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/​).

4 5

61

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.

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

[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: Configuration 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: Configuration 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.

62

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.

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

[B33] IEC 61850-8-1 ed1.0 (2008–12), Communication networks and systems in substation—Part 8-1: Specific 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: Specific 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: Specific 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: Specific 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: Profiles including MMS. [B49] IEC 62351-6, Power systems management and associated information exchange—Data and communications security—Part 6: Security for IEC 61850.

63

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.

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

[B50] IEC 62381, Automation systems in the process industry—Factory 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: Classification 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 Specification. Part 3: Media Access Control (MAC) Bridges—Amendment 2: Rapid Reconfiguration. [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. 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/​). 6

64

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.

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

[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

65

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.

IEEE standards.ieee.org Phone: +1 732 981 0060 © IEEE

Fax: +1 732 562 1571

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