JUKKA PIIRAINEN

APPLICATIONS OF HORIZONTAL COMMUNICATION IN

INDUSTRIAL POWER NETWORKS

Master of Science Thesis

Examiner: professor Pekka Verho

Examiner and topic approved in the
Computing and Electrical
Engineering Faculty Council
meeting on 3rd of February 2010
 II

ABSTRACT
TAMPERE UNIVERSITY OF TECHNOLOGY
Master’s Degree Programme in Electrical Engineering
PIIRAINEN, JUKKA: Applications of Horizontal Communication in Industrial
Power Networks
Master of Science Thesis, 62 pages, 7 Appendix pages
May 2010
Major: Power Engineering
Examiner: Professor Pekka Verho
Keywords: IEC 61850, GOOSE, Substation automation, IED, Station bus,
REF615

The amount of information generated in substation automation systems has grown

exponentially since the introduction of Intelligent Electrical Devices (IED). Until recent
years substation communication between IEDs was realized with proprietary protocols.
This led to communication problems in systems with IEDs from different vendors. The
IEC 61850 standard was introduced in order to harmonize substation communication
and gain interoperability.
The IEC 61850 is an international standard defining communication networks and
systems in substations. The standard defines substation functions, communication
services and communication between devices as independent units. Thus the standard
provides an opportunity for redefinition if technology in one area develops. The
standard divides substation communication into three levels. This study focuses on
horizontal GOOSE communication between IEDs in bay level and its applications.
Horizontal communication has conventionally been solved by hardwiring required
information between devices. GOOSE communication enables the transmission of these
signals via Ethernet network, therefore creating a system that is more easily expandable
and reducing the need of hardwiring.
The purpose of this work is to provide information for ABB Process Industry Plc
concerning IEC 61850 and GOOSE. The substance of IEC 61850 and horizontal
communication are presented in the theory chapters. The applications of GOOSE were
examined in order to get more practical results. The applications were selected based on
the capabilities of recently introduced REF615 IED. Each application is first described
in general, followed by an example solution with REF615 IEDs. A fault arc protection
application was selected for further testing based on an upcoming customer project.
This application was configured between two REF615 IEDs and the functionality of the
application was confirmed before the customer project was initiated.
 III

TIIVISTELMÄ
TAMPEREEN TEKNILLINEN YLIOPISTO
Sähkötekniikan koulutusohjelma
PIIRAINEN, JUKKA: Horisontaalisen kommunikoinnin sovelluksia teollisessa
sähkönjakeluverkossa
Diplomityö, 62 sivua, 7 liitesivua
Toukokuu 2010
Pääaine: Sähkövoimatekniikka
Tarkastaja: Professori Pekka Verho
Avainsanat: IEC 61850, GOOSE, sähköasema-automaatio, IED, asemaväylä,
REF615

Sähköasemien tuottaman informaation määrä on kasvanut merkittävästi älykkäiden

toimilaitteiden (IED) tultua markkinoille. Viime vuosiin asti sähköaseman laitteiden
kommunikointi on toteutettu valmistajakohtaisia protokollia käyttäen, jolloin eri
laitevalmistajien laitteiden välinen kommunikointi on ollut hankalaa toteuttaa.
Tiedonsiirron yhdenmukaistamiseksi ja eri valmistajien laitteiden yhteentoimivuuden
saavuttamiseksi esiteltiin IEC 61850 standardi.
Kansainvälinen IEC 61850 standardi määrittelee tiedonsiirtoverkot ja -järjestelmät
sähköasemilla. Standardissa sähköaseman toiminnot, kommunikaatiopalvelut ja
laitteiden välinen kommunikaatio on määritelty kukin erillisenä kokonaisuutena. Täten
standardi tarjoaa mahdollisuuden uudelleenmäärittelyyn, mikäli teknologia jollakin osa-
alueella kehittyy. Sähköaseman kommunikaatio on standardissa jaettu kolmeen tasoon.
Tämä diplomityö keskittyy kenttätason horisontaaliseen GOOSE kommunikaatioon ja
sen sovelluksiin. Perinteisesti horisontaalinen tiedonsiirto on ratkaistu johdottamalla
tarvittavat tiedot laitteiden välillä. GOOSE kommunikaatio mahdollistaa tilatietojen
siirtämisen Ethernet-verkkoa pitkin, jolloin johdotuksen tarve vähenee ja järjestelmää
pystytään tarvittaessa helpommin laajentamaan.
Työn tarkoituksena on tuottaa ABB Prosessiteollisuudelle tietoa IEC 61850
standardista ja horisontaalista kommunikaatiosta. Standardin ja horisontaalisen
kommunikaation keskeiset ajatukset on esitetty teoriakappaleissa. Hyödynnettäviä
tuloksia varten myös GOOSE kommunikoinnin sovelluksia tutkittiin. Tutkittavat
sovellukset valittiin äskettäin julkaistun REF615 IED:n toiminnallisuuden perusteella.
Kukin sovellus kuvataan ensin yleisesti, jonka jälkeen esitetään esimerkkitoteutus
REF615 releitä käyttäen. Lähestyvän asiakasprojektin perusteella tarkempaan
testaukseen valittiin valokaarisuojaukseen liittyvä sovellus. Sovellus konfiguroitiin
kahden REF615 releen välille, jotta sen toimivuus voitiin todentaa ennen
asiakasprojektin käynnistymistä.
 IV

PREFACE
This master’s thesis was written for ABB Process Industry Plc as a part of a
development project concerning the IEC 61850 standard. It is written specially for
professionals familiar with substation automation, but who have minor knowledge about
the IEC 68150 and GOOSE communication. I hope this study provides valuable
information to future projects implementing applications based on GOOSE
communication.
During the study the support and guidance from the project team was essential. Thus
I wish to show my acknowledgements to Timo Haapalainen, Timo Peltoniemi and Toni
Korpi-Halkola. Other important sources of information include Janne Starck and Juha
Willman, who familiarized the author with GOOSE communication and process
industry electrification. I also wish to thank Katja Rajaniemi for the chance to work for
ABB Process Industry Plc and professor Pekka Verho for examining this study.
The greatest gratitude during my studies belongs to my family Heikki, Sinikka,
Elina and Antti-Juhani for their endless support. Equally important are all my friends, to
whom I would like to show my acknowledgements.
Finally I would like to thank Anne for proofreading this thesis, and for showing me
what really matters in life.

Tampere 26.04.2010

_________________________
Jukka Piirainen
Hämeenpuisto 14 A 4
33210 Tampere
+358 503 295 510
 V

CONTENTS
Abstract ............................................................................................................................ II
Tiivistelmä ...................................................................................................................... III
Preface ............................................................................................................................. IV
Abbreviations and Notation .......................................................................................... VII
1. Introduction ............................................................................................................... 1
1.1. Purpose .............................................................................................................. 1
1.2. Background ....................................................................................................... 1
1.3. Scope of the Study ............................................................................................ 2
2. Research Methods ..................................................................................................... 3
2.1. Objective ........................................................................................................... 3
2.2. Workflow .......................................................................................................... 3
2.3. Methods and Sources ........................................................................................ 4
3. IEC 61850 Standard .................................................................................................. 6
3.1. Overview ........................................................................................................... 6
3.2. Purpose and Objective of the Standard ............................................................. 7
3.3. Information Structure in IEC 61850 ................................................................. 7
3.3.1. Object Model ....................................................................................... 9
3.3.2. Data Mapping .................................................................................... 14
3.3.3. Information Exchange ....................................................................... 17
3.3.4. Substation Description Language ...................................................... 20
3.4. Network ........................................................................................................... 22
3.4.1. Network Topologies .......................................................................... 22
3.4.2. Component Features .......................................................................... 25
3.4.3. Data Transfer Medium ....................................................................... 26
3.4.4. Information Security .......................................................................... 27
4. Applications of GOOSE.......................................................................................... 29
4.1. Process Industry Electrification ...................................................................... 29
4.2. Conventional Solution..................................................................................... 30
4.3. GOOSE Solution ............................................................................................. 32
4.4. Benefits of GOOSE ......................................................................................... 33
4.5. GOOSE Applications ...................................................................................... 33
4.5.1. Bay Interlocking ................................................................................ 34
4.5.2. Inter-Bay Interlocking ....................................................................... 36
4.5.3. Reverse Blocking ............................................................................... 38
4.5.4. Breaker Failure Protection ................................................................. 40
4.5.5. Fault Arc Protection ........................................................................... 41
4.5.6. Triggering of Disturbance Recording ................................................ 43
4.5.7. Future Applications ........................................................................... 45
4.6. Reliability and Redundancy ............................................................................ 47
4.7. Testing ............................................................................................................. 49
 VI

4.7.1. Testing Software ................................................................................ 49

4.7.2. Testing Method .................................................................................. 50
4.8. Documentation ................................................................................................ 50
4.8.1. Relevant Documentation ................................................................... 50
4.8.2. Signal Lists ........................................................................................ 51
4.8.3. Logical Diagrams............................................................................... 51
5. Application Test ...................................................................................................... 53
5.1. Application Tested .......................................................................................... 53
5.2. Test Equipment ............................................................................................... 54
5.3. Configuration Description............................................................................... 55
5.3.1. Configuration in the PCM600 ........................................................... 56
5.3.2. Configuration in the CCT .................................................................. 56
5.3.3. Parameterization and Uploading........................................................ 58
5.4. Test .................................................................................................................. 59
5.5. Problems in the Configuration ........................................................................ 59
6. Conclusions ............................................................................................................. 61
References ....................................................................................................................... 63
Appendix 1: Parts of the IEC 61850 ............................................................................... 66
Appendix 2: Guide for the Reader .................................................................................. 67
Appendix 3: Table of Logical Nodes .............................................................................. 68
Appendix 4: Screenshot from PCM600 .......................................................................... 71
Appendix 5: Screenshot from CCT ................................................................................. 72
 VII

ABBREVIATIONS AND NOTATION

ABB Asea Brown Boveri
ACSI Abstract Communication Service Interface
AIS Air-Insulated Switchgear
APPID Application Identification Number
BIO Binary Inputs and Outputs
CCT Communication Configuration Tool
CDC Common Data Class
CID Configured IED Description
CMD Command Interpreter
EMI Electromagnetic Interference
EPRI Electric Power Research Institute
FAT Factory Acceptance Test
FC Functional Constrain
GIS Gas-Insulated Switchgear
GOOSE Generic Object Oriented Substation Event
GOCB Goose Control Block
GSE Generic Substation Event
HMI Human Machine Interface
HV High Voltage
ICD IED Capability Description
IEC International Electrotechnical Commission
IED Intelligent Electronic Device
IEEE Institute of Electrical and Electronics Engineers
IGMP Internet Grouping Message Protocol
IP Inter-networking Protocol
ITT Integrated Testing Toolbox
LAN Local Area Network
LD Logical Device
LN Logical Node
LV Low Voltage
MAC Media Access Control
MBPS Megabytes Per Second
MMS Manufacturing Message Specification
MTBF Meat Time Between Failures
MV Medium Voltage
OSI Open Systems Interconnection
PD Physical Device
PDC Power Distribution Control
RSTP Rapid Spanning Tree Protocol
SAS Substation Automation System
 VIII

SAT Site Acceptance Test

SC Synchronism Check
SCADA System Control and Data Acquisition
SCD Substation Configuration Description
SCL Substation Configuration Description Language
SMT Signal Matrix Tool
SNMP Simple Network Management Protocol
SPS Single Point Status
SSD Substation Specific Description
SV Sampled Values
TCP Transport Control Protocol
TPAA Two Party Application Association
UCA Utility Communications Architecture
VLAN Virtual Local Area Network
VT Voltage Transformer
XML Extensible Markup Language
 1 1

1. INTRODUCTION

In this chapter the purpose and background of this study are presented, followed by a
short history of the IEC 61850 standard. Finally the scope of this study and an outline of
the chapters are presented.

1.1. Purpose
This master’s thesis was initiated by ABB Oy Process Industry Electrification,
Instrumentation and Composite Plants business unit as a part of a development project.
The project focuses on standardization of power distribution control based on the IEC
61850 standard, presented by the International Electrotechnical Commission (IEC). The
IEC 61850 describes communication networks and systems in substations. The focus of
this master’s thesis is to investigate the possible applications of horizontal
communication between Intelligent Electronic Devices (IEDs). The communication is
described by IEC 61850 as Generic Object Oriented Substation Event (GOOSE). [1]
This master’s thesis provides information about the technological aspects of GOOSE
communication.

1.2. Background
Substation is described as a number of switchgear controlled, supervised and protected
by a Substation Automation System (SAS). Substation can be divided into three levels,
which are called station level, bay level and process level. [2] From the perspective of
process industry, an SAS is essential in order to provide distribution of electricity for
various types of equipment. Substation automation provides the means for effective,
reliable and safe distribution of electric energy.
In recent years the development of substation automation systems has been rapid
due to the introduction of microprocessor relays. These relays are capable of executing
several protection and control functions to different devices in the substation. Modern
relays can also perform, for example, auto-reclosing and self-monitoring functions, thus
they are called IEDs. [3]
Due to the rapid development of IEDs, a vast amount of information is now
available within a substation and the requirements for communication technology are
increasing. Up till recent years, vendors have used different communication protocols to
exchange information inside a substation. This has lead to vendor-specific
communication solutions, leaving customers depending on the products of the selected
vendor. Due to vendor-specific communication, interoperability between products from
different vendors has been either cumbersome or impossible. This problem was
acknowledged by major vendors in the industry as well as international organizations.
 2

In order to gain genuine interoperability and standardize the communication of an

SAS, IEC published the 61850 standard between 2002 and 2005. The key aspect of the
standard is to describe communication of an SAS in a way that supports interoperability
and future solutions in communication and substation automation. The standard presents
a uniform way to describe data generated in an SAS by decomposing it into smallest
possible entities that can exchange data. By defining these data models, the transferring
services and communication protocols, a substation automation system can be described
uniformly. The principles for these data models, transferring services and protocols are
presented in this study.
One of the services for data exchange is horizontal GOOSE communication, which
can be best described as fast peer-to-peer communication between IEDs. The possible
applications of this communication can replace present solutions of protection and
control realized by hardwired schemes. The principles of the most relevant applications
for the target company' s needs are presented within this study. One of these applications
is described in detail by configuring the required parameters to IEDs and testing the
GOOSE solution.

1.3. Scope of the Study

Due to the publication of the IEC 61850 standard, ABB released a new series of IEDs
with native support to IEC 61850 communication. The aim of this study is to investigate
the possible applications of horizontal GOOSE communication for one IED from the
new Relion® series. The selected IED is REF615, which is designed for feeder
protection in low and medium voltage switchgear. The REF615 is commonly used for
industrial power systems protection, and thus the applications based on GOOSE
communication provide profitable information for ABB Process Industry. The
examination of more versatile REF630 IED and its applications was also suggested.
However, the REF630 was not yet available at the beginning of this study. Therefore it
was not included in this study.
The outline of this study is as follows. The first chapter provides background
information for the reader to understand the rationale behind the initiation of this
master’s thesis. Chapter 2 describes the objective, workflow and information sources
used in this study. Chapter 3 presents the basis for understanding how substation data is
described according to the standard. The required communication infrastructure for
horizontal communication is also presented. In Chapter 4 possible applications are first
described generally, and then with an example solution with ABB’s REF615 IEDs.
Information regarding reliability, testing and documentation of GOOSE based solutions
is also presented. Chapter 5 presents a detailed description of GOOSE implementation
to ABB IEDs. The required engineering and configuration with software tools, as well
as the performance of GOOSE communication, are presented. Finally in Chapter 6 the
outcome of this master’s thesis is presented with proposals to future topics for
investigation.
 3

2. RESEARCH METHODS

In this chapter the objective of this study is defined, followed by a presentation of the
workflow of this study. In the final chapter the information sources and research
methods used in this study are presented.

2.1. Objective
This master’s thesis is a part of a development project which focuses on standardization
of power distribution control (PDC) systems. The focus of this study is on horizontal
communication between IEDs and its possible applications. The technological benefits
of the applications compared to conventional solutions are presented based on the
feedback received from the project team. Important aspects, such as reliability,
redundancy and security, are presented in order to evaluate the reliability of GOOSE
solutions compared to conventional solutions. The purpose of this work is to present
information about the new concept of horizontal communication based on IEC 61850
standard. Equal importance is given to producing the most suitable applications for
REF615 IED’s on the framework of Process Industry’s target business markets.

2.2. Workflow
At the beginning of the study a project team was appointed to investigate the
possibilities to standardize practices used in PDC systems. One part of this project was
to investigate possible applications of horizontal GOOSE communication, which is the
subject of this study. After the goals and milestones of this study were specified with
ABB and approved by Tampere University of Technology, the investigation was
initiated.
The investigation of the subject started with collecting reference material about the
IEC 61850 standard and horizontal communication. The content of this study was
enunciated after the author had familiarized himself with the standard and discussed
with the project team. When the requirements for horizontal communication were
internalized, ABB provided the author with training about the configuration of IEDs
including implementation of GOOSE communication. After the required training a
number of REF615 IEDs were acquired by the project team in order to test and
demonstrate the implementation of GOOSE communication. The most relevant
applications for REF615 IEDs were selected to be presented in this study. This was
achieved by studying reference material and discussing with project engineers. The
application of transferred arc protection trip was further on selected to be configured
 4

and tested. The author acquired the knowledge and skills required for application tests
by investigating the standard, product manuals, and by participating to relevant ABB’s
courses. This was followed by an application test, where the transferred arc protection
trip application was tested and also the performance of GOOSE communication was
noticed. The setting up of the test equipment, the configuration work and the actual
testing were done in ABB Process Industry’s facilities. After the tests, the principles and
signals required for all the selected applications were discovered by investigating the
product manuals and the IEC 61850 standard. The major tasks and workflow of this
study are depicted in Figure 1.

Figure 1. Workflow of the study.

After the author had done enough research on IEC 61850, the contents of this study
were enunciated and the writing process begun. After all selected applications were
introduced and the test completed, the findings of this study were documented for ABB.
Finally the conclusions of this study were written.

2.3. Methods and Sources

Because the IEC 61850 was published between 2003 and 2009, the reference material
available is vast. Naturally the standard itself is a major source of information, along
with a number of publications written by experts and scientists worldwide. Most of the
material was acquired from internet based databases of international organizations, such
as the Institute of Electrical and Electronics Engineers (IEEE). The fact that ABB has
access rights to major scientific databases concerning electrical engineering was a
notable contribution. Articles concerning IEC 61850 published in Praxis Profiline were
very useful at the initial phase of study. Master’s of Science thesis with relevant topics
were also used as a reference.
 5

After the author had familiarized himself enough with the subject, the actual process
of investigating and writing begun. During this phase the colleagues working at the
PDC development project were an important source of information. Interviews with
specialists in the fields of substation automation and process industry electrification
were also arranged. This provided important perspective and experience to the study.
 6

3. IEC 61850 STANDARD

The purpose of this chapter is to introduce the theoretical background and network
requirements for GOOSE based applications. At the beginning, an overview of the IEC
61850 is given, followed by a description of the purpose and objective of the standard.
The information structure defined by IEC 61850 is presented by introducing the object
model and data mapping. The services for information exchange are described in
chapter 3.3.3, followed by a presentation of the substation description language. The
requirements for network infrastructure are introduced by presenting network topologies
and component features. The data transfer medium and information security are
described in the final chapters.

3.1. Overview
The history of IEC 61850 began in 1990, when Electric Power Research Institute
(EPRI) and the IEEE started a project on Utility Communications Architecture (UCA).
The aim of the UCA-project was to develop both the communication between control
centers and the communication from substation to control center. The outcome of the
project was a standard called IEC 60870-6-TASE.2. In 1994 both EPRI and IEEE
started working on new standard called UCA2, which focused on the station bus
communication. In 1996 IEC Technical Committee 57 began working with IEC 61850,
a standard defining station bus. These two working groups with similar tasks joined
their forces in 1997, with a goal to create one single standard for station bus
communication. The result of the combined work is the new international IEC 61850
standard series, whose latest part was published in 2009. [3; 4]
The IEC 61850 standard currently consists of fourteen parts, which are presented in
Appendix 1. Together these parts constitute all the requirements that a substation
automation system has to fulfill. From the perspective of horizontal communication, the
IEC 68150-8-1 is the most relevant part in the standard. Due to the vast amount of pages
and information within the standard, a special reading guide has been composed. This
guide is meant to point out the relevant parts of the standard to a specific professional.
The reading guide is presented in Appendix 2. Horizontal communication between IEDs
and its applications are relevant to both application and communication engineering.
Therefore, all the parts mentioned in the reading guide are relevant in this context. [5]
 7

3.2. Purpose and Objective of the Standard

The implementation of IEDs has become prevailing in substation automation. Intelligent
electronic devices are performing all necessary functions inside a modern substation.
This requires efficient communications among the IEDs, which requires the use of
communications protocols. Before the IEC 61850 standard was released, different
vendor-specific communication protocols were used to exchange information among the
IEDs. This means that if different vendors were used, the information would have to be
converted to the protocol in question. Protocol converters cause delay and increase the
possibility of errors to the communication process. As the amount of information grows,
this can potentially create problems within the substation. [3; 6]
The purpose of the IEC 61850 series is to solve the problems related to different
communication protocols by introducing a standardized communication protocol. The
key objectives of the standard are interoperability of IEDs, supporting the operation
functions and performance requirements of the substation, and supporting future
technological development. The object of the IEC 61850 is not to standardize the
functions inside a substation. The functions simply have to be defined in order to
determine their requirements for the communication. The standard does not define how
different functions should be allocated in the system. It only specifies the structure and
communication interface of the functions. Therefore, the standard does not confine the
development of IEDs or substation automation, and vendors can continue developing
functionality in their products. [3; 6; 7]

3.3. Information Structure in IEC 61850

Horizontal GOOSE communication between IEDs is based on the IEC 61850 standard.
Consequently, the reader must understand how data generated in the IEDs is being
modeled in the standard. The following chapters present the models for information and
data used in the standard. [8]
According to IEC 61850, an SAS can be presented as a combination of three levels:
station level, bay level and process level. These levels and the possible interfaces
between them are presented in Figure 2. The numbers within Figure 2 present the
interfaces of data exchange between different parts of an SAS, which are listed below
[6]:
1. Protection data exchange between bay and station level.
2. Protection data exchange between bay level and remote protection (beyond
the scope of IEC 61850).
3. Data exchange within bay level.
4. Current transformer and voltage transformer instantaneous data exchange
between process and bay level.
5. Control-data exchange between process and bay level.
6. Control-data exchange between bay and station level.
 8

7. Data exchange between substation and a remote engineer’s workplace.

8. Direct data exchange between the bays especially for fast functions such as
interlocking.
9. Data exchange within station level.
10. Control-data exchange between substation and remote control centre
(beyond the scope of IEC 61850).

Figure 2. A Substation Automation System according to IEC 61850. [6]

This study focuses on horizontal communication, which is referred to by number 8

in Figure 2. The purpose of horizontal communication is to provide means for IEDs to
communicate with each other in order to perform, for instance, fast interlocking
protection schemes within substation. This requires fast and reliable communication,
also between IEDs from different vendors.
The IEC 61850 series defines communication by using the OSI-model (Open
Systems Interconnection). The OSI-model is an internationally standardized (ISO/IEC
7498-1) model that uses the concept of layering the communication functions. The
model contains seven layers each of which have defined functional requirements in
order to create a robust communication system. The OSI-model does not specify which
protocols should be used in order to achieve the functionality, nor does it restrict the
solution to a single set of protocols. Therefore, by using the OSI-model the IEC 61850
series preserves the possibility to change the chosen protocols if technology develops in
that particular area. [7; 9] The OSI-model is illustrated in Figure 3.
 9

Figure 3. Communication stack of OSI-model [3; 8]

The actual communication inside an SAS can be divided into three separate parts:
[10]
• Data of the applications
• Services for transferring this data
• Real communication protocols
In order to make the communication possible, all of these parts have to be defined. In
most standards used today these parts are defined together, which creates a unique
syntax for the messages being transmitted. This makes the data and the services
dependent from the protocol and also the protocol dependent from the communication
technology. In IEC 61850 series these parts are all defined separately. If technology in
one of these parts develops considerably, it is only required to redefine this part to meet
the state-of-the-art technology. Therefore, the requirement for supporting future
technology can be achieved.
Data of the applications is described by an object model. The idea of the object
model is to decompose data of the substation functions into smallest possible entities,
which are then used to exchange information. The structure of the object model is
described in Chapter 3.3.1. For transferring services an object-oriented concept called
Abstract Communication Service Interface (ACSI) is used. To achieve actual
communication, the abstract objects and services need to be mapped to real
communication protocols. These protocols should be practical to implement and should
operate in common computing environment of the power industry. The actual
implementation to real protocols is achieved through Specific Communication Service
Mappings (SCSM) which is defined in parts 61850-8-1, 61850-9-1 and 61850-9-2 of the
standard. The information exchange services and mappings to real protocols are
presented in Chapter 3.3.2. [11]

3.3.1. Object Model

Information exchange requires specific data models for data generated in the IEDs. The
IEC 61850 series uses the concept of virtualization in order to create these data models.
 10

Virtualization provides a view of those aspects of a real device that are of interest for
the information exchange with other devices. In the IEC 61850 series only the relevant
details that are required to provide interoperability are defined. These definitions are
created by using an object model, which decomposes the functionalities of a real device
into the smallest possible entities. A good illustration of the object model can be
achieved by imagining an IED as a container, which is presented in Figure 4. [12]

Figure 4. Object model of IEC 61850 [12]

In the IEC 61850 series object model begins with a physical device (PD). These
devices are capable of connecting to the network, and are therefore defined by a
network address. Each PD has to have a unique IP-address in order to ensure the
functionality of the network. A physical device, for instance an IED, consists of one or
several logical devices (LDs). A logical device is a compound of logical nodes (LNs),
and each of these logical nodes is related to a specific function inside a substation. At
least three logical nodes must be within a logical device, namely two LNs related to
common issues for the logical device (LLN0 and LPHD), and at least one LN
performing some functionality. A logical node is a grouping of data and services related
to certain substation function. Therefore, all data generated from the substation can be
assigned to a certain logical node. A complete list of logical nodes is defined in the IEC
61850-7-4 and is presented in Appendix 3. In the standard a logical node is specified as
the smallest entity that can exchange information. Logical nodes are combined into
groups based on their functionality. These groups and the number of nodes in a group
are presented in Table 1. At the moment a total of 92 logical nodes are defined in the
standard. [11; 12]
 11

Table 1. Logical node groups [5]

Symbol Logical node group Number of LNs
A Automatic control 4
C Supervisory control 5
G Generic references 3
I Interfacing and archiving 4
L System logical nodes 3
M Metering and measurement 8
P Protection functions 28
R Protection related functions 10
S Sensors and monitoring 4
T Instrument transformer 2
X Switchgear 2
Y Power transformer 4
Z Further power system equipment 15
Total 92

Each logical node contains one or more elements of data. These data elements are
named according to the standard and are related to a specific purpose in the substation.
An example of one logical node is given in Table 2.

Table 2. A logical node for circuit breaker; XCBR [13]

 12

The XCBR logical node is a model of a circuit breaker and it contains several
elements of data. The first column describes the name of the data. This name is unique
and defined by the standard. The second column describes the Common Data Class
(CDC) to which the data belongs. Part 61850-7-3 of the standard presents all CDCs,
which are 29 in total. The Explanation column presents a short description of the data
class in question. If there is a letter T marked in the next column, this informs the
transient nature of the data class. The last column informs whether the data class is
mandatory (M) or optional (O) for the logical node in question. For instance, XCBR
logical node has a data class Loc, which belongs to a single point status (SPS) common
data class, is non-transient, and is mandatory. [12; 13]
The elements of data within a logical node have to conform to the specification of a
Common Data Class (CDC), as stated above. A common data class is a description of
the type and structure of the data within a logical node. Each CDC has a defined name
and a set of attributes, which in turn have a defined name, a defined type and a specific
purpose. For illustration an anatomy of Single Point Status (SPS) common data class is
presented in Table 3.

Table 3. The anatomy of Single Point Status (SPS) common data class. [14]

The table lists all data attributes that belong to common data class SPS. The first and
second column describe the name and type of the data attribute, respectively. The
individual attributes of a common data class are grouped into categories by functional
constrains (FC). The functional constrain of a data attribute is told in the third column.
The trigger option column (TrgOp) defines when for instance reporting or reading of the
data will occur. The fourth column describes the predefined values or value range for
the data attribute. The last column (M/O/C) refers to whether the data attribute is
mandatory, optional or conditional. For instance the first data attribute in Table 3 is
 13

named stVal, the type of data is BOOLEAN and it belongs to a functional constrains for
status attributes (ST). The trigger option for stVal is data-change (dchg), and it is
mandatory (M) for single point status CDC. [3; 11; 12; 14]
The anatomy of an object name according to IEC 61850 can be easily understood by
following the data model described in this chapter. An example of such name is
presented in Figure 5, with explanations. The parts of the object name marked with an
asterisk (*) are defined by the standard, other parts can be freely allocated according to
the vendor. According to IEC 61850 the object name can contain 62 marks including
separation points. The name of the logical node can contain 11 marks including both a
prefix and a suffix. [3; 8]

Figure 5. The anatomy of an object name according to IEC 61850-8-1 [8]

In order to group chosen data attributes or object references of data, the IEC 61850
defines the concept of a dataset. A dataset is a single collection of object references,
including data or data attributes organized as a dataset for communication. Because IEC
61850 defines the object references, the communicating partners shall both
acknowledge them, therefore only the values and the name of the dataset need to be
transmitted. Datasets are divided into two types, persistent and non-persistent, which
relate to the visibility of the datasets. The persistent datasets are visible to any clients of
Two Party Application Association (TPAA). These include the pre-configured datasets,
which are also permanent. The non-persistent datasets are visible only to the defined
client that of the dataset in question. Non-persistent datasets are vital to the functionality
of GOOSE communication. The chosen data attributes of a GOOSE message have to be
grouped into a dataset, in order to perform the required function within the substation.
This is described in Chapter 3.3.3. [12; 15]
 14

3.3.2. Data Mapping

The object model describes all data generated by an IED in an abstract way, preserving
the direct relation with the functions from which the data is originated. In order to
transfer this uniformly constructed data, information exchange services have to be
defined. The IEC 61850 series uses an object-oriented concept called Abstract
Communication Service Interface (ACSI). The ACSI is very useful, because the
services are independent of the information content and the communication protocol.
This service enables all IEDs to behave identically from the perspective of a
communication network. This way also the services for transferring data are described
independently. Therefore, the object models and services can be mapped to any
protocol.
In the ACSI model there are two groups of communication services. The first group
uses client-server model, for example to get data values from IEDs. The second group is
a peer-to-peer model with Generic Substation Event (GSE) services, which are used for
fast communication between IEDs and periodic sampled value transmissions. These
services comprise the communication services described by the IEC 61850 series, which
are listed below: [7; 12]
• Client-Server Communication
• Time-critical Sampled Values
• Time-critical GOOSE Messages
Client-Server communication works as a service where the client requests data from
a server which offers it. The server contains the content of logical device, the
association model, time synchronization and file transfer, which are defined as
accessible and visible from the communication network. [12] In the SAS a Client-
Server communication is used for transferring relatively large amounts of information,
which is not time-critical. This means, for instance, transferring configuration data to
IEDs. When time-critical information has to be moved, the standard describes two types
of communication services. These are Sampled Values (SV) for metering information
and GOOSE messages for fast peer-to-peer communication between IEDs.
Sampled Values are messages related to instrumentation and measurement.
Therefore, they are transferred between bay and process levels, as illustrated by number
4 in Figure 2. The SV messages are time critical and they need to be in chronological
order. Possible loss of messages also has to be detected. These messages can be sent as
unicast to one receiver or as multicast for several receivers. [7] The SV messages are
beyond the scope of this study, and therefore are not described in detail. However, it is
worth mentioning that as technology migrates to next generation, digital information
exchange between IEDs and process level devices becomes possible. For instance,
current transformers can send values digitally via IEC 61850 network. This need has
been taken into account by defining transmission of SV messages. [11]
Time-critical GOOSE messages have been defined for fast horizontal
communication between IEDs. They are used to transfer state and control information
 15

between IEDs, for instance trip or locking commands in order to achieve designed
control and protection schemes. GOOSE messages are transmitted as a multicast over
Local Area Network (LAN), from which all IEDs configured to receive the message can
subscribe it. The demand for fast transmission is obvious, as most protection and control
schemes depend on fast action of devices. Different message types are presented in
Table 4. For SV and GOOSE messages this demand can be achieved by a different
mapping to real protocols, which are presented next. [7]

Table 4. Types of messages according to IEC 61580 [16]

Type Name Example
1a Fast messages – trips Trips
1b Fast messages – others Commands, simple messages
2 Medium speed messages Measurement values
3 Low speed messages Parameters
Output data from transducers
4 Raw data messages
and instrument transformers
5 File transfer functions Large files
Time synchronization,
6a Time synchronization messages a
station bus
Time synchronization,
6b Time synchronization messages b
process bus
7 Command messages with access control Commands from station HMI

In order to communicate by using the OSI-model, communication services have to be

mapped to real communication protocols by using different communication profiles.
The profiles used in IEC 61850 are presented in Figure 6.
Basically, in the upper three layers of the OSI-model, the IEC 61850 uses two
application profiles, the Connection Oriented OSI and Connectionless OSI. For the four
lower layers of the OSI-model three types of transmission profiles are used, Connection
Oriented TCP, Connection Oriented OSI and Connectionless OSI. The actual
communication profiles can be divided into MMS (Manufacturing Message
Specification) and non-MMS profiles according to IEC 61850-8-1. [8]
For client-server communication MMS is used. This protocol was originally
designed for manufacturing, but it was chosen because it has proven to support the
complex naming and service models of IEC 61850. [11] MMS is an internationally
standardized messaging system for exchanging real-time data and supervisory control
information between networked devices and computer applications. [12] MMS covers
the application profile of the OSI-model, and the transfer and network layers are
covered either by TCP/IP or ISO. In the perspective of GOOSE messages, client-server
communication is used only to transfer GOOSE Control Block information during the
configuration phase of IED engineering. [8] Because client-server communication
 16

cannot fulfill the real-time demands of GOOSE-messaging, different communication

profiles have to be used for time-critical messages. [8; 11; 12;]

Figure 6. An overview of functionality and profiles in IEC 61850 [8]

For GOOSE communication Connectionless OSI and non-MMS profiles are used.
This means that the connection between IEDs prior to sending is not confirmed. The
GOOSE message is simply sent to the network. This is needed in order to meet the
time-critical demand of GOOSE communication. As depicted in Figure 6, GOOSE
messages are mapped directly into the Ethernet data frame in order to eliminate
processing time of the middle layers. The communication profiles for GOOSE services
and GSE management are described in part 61850-8-1 Clause 6.3. The protocols and
services for OSI application profile according to IEC 61850-8-1 are shown in Table 5.

Table 5. Application profile for GOOSE messages and GSE management. [8]

As presented in Table 5, the specific GSE/GOOSE protocol is presented in Annex A

of IEC 61850-8-1, and the Basic Encoding Rules for presentation layer are described in
ISO/IEC 8824-1 and ISO/IEC 8825-1. The protocols used for OSI transmission profile
 17

are illustrated in Table 6. The chosen protocols assure that GOOSE communication can
meet the strict real-time demands of peer-to-peer communication of IEDs. These
protocols among others related to the performance of the network are described in
Chapter 3.4.2 of this study.

Table 6. Transmission profile for GOOSE messages and GSE-management. [8]

In addition to services described earlier, time synchronization and Generic

Substation Status Event (GSSE) are depicted in Figure 6. Time synchronization
provides a reference clock for the entire network, which is used, for instance, to have
sampled values in chronological order. It uses the Simple Network Time Protocol
(SNTP), which is mapped to the ISO/IEC 8802-3 Ethernet frame via UDP/IP protocols.
The GSSE provides similar status information as GOOSE, but is merely a list of
information compared to configurable datasets of GOOSE. [8]

3.3.3. Information Exchange

The information exchange with GOOSE messages is established by using a specific

Generic Substation Event (GSE) model. This model provides the possibility of fast and
reliable system-wide information exchange of input and output data values. The GSE
model presents an efficient method for simultaneous delivery of the same generic
substation information for more than one physical device through the use of multicast
services. According to the standard, the GSE model applies to the exchange of values of
a collection of data attributes. There are two different message types defined in the
standard that use the GSE model. The Generic Substation State Event (GSSE) message
type is able to transfer state change information, which means bit pairs. The GOOSE
message type can convey a wide range of data attributes organized in a dataset. The
 18

major difference between these two message types is that GSSE provides a simple list
of status information, whereas GOOSE provides a flexible combination of information
organized into a dataset. Therefore, in GOOSE the information that needs to be
exchanged can be specified. The actual information exchange is based on a
publisher/subscriber mechanism. This mechanism along with services is presented in
Figure 7.

Figure 7. An overview of the classes and services of the GOOSE model. [15]

As illustrated in Figure 7, within a dataset there is a group of data attributes with

specific functional constrain, for instance st-attr for status. Each of these data attributes
within a dataset is called Member of the dataset, with a MemberReference-numbering
starting at one. If any of these data attributes change, the publisher will write the
changed values to a transmission buffer. The values are transferred as a GOOSE
message to the subscriber with a local service Publish.req. Communication mapping
specific services will transfer the values to a Reception buffer in the subscriber, from
which they are signaled further on, for instance to perform the application in question.
[15]
In a practical perspective, this means that a specific GOOSE control block (GOCB)
has to be configured for each GOOSE message. This control block includes the
information which a dataset needs for transmission. The GOOSE control block specifies
the MAC addresses (Media Access Control) for both the destination and source of the
GOOSE message. The actual addressing of GOOSE messages is done via MAC
addresses. The destination address of a GOOSE message contains a multicast MAC
address, whereas the source address of a GOOSE message contains a unicast MAC
address. The recommended definitions and limitations of MAC addresses are depicted
 19

in Table 7. The first three octets are defined by IEEE, and are 01-0C-CD for GOOSE
and GSSE messages. The fourth octet in the MAC address defines the type of the
message. Value 01 is used for GOOSE messages. Finally, the last two octets are used
for individual addressing of different messages types. The recommended range for
addressing is presented in Table 7. Recommended MAC address range for GOOSE and
GSSE messages. [8]

Table 7. Recommended MAC address range for GOOSE and GSSE messages. [8]
Recommended address range assignments
Service Starting address Ending address
(hexadecimal) (hexadecimal)
GOOSE 01-0C-CD-01-00-00 01-0C-CD-01-01-FF
GSSE 01-0C-CD-02-00-00 01-0C-CD-02-01-FF

A specific three digit hexadecimal virtual local area network (VLAN) identification
number is also a part of the GOCB with the range of 000 to FFF. This is used to identify
which VLAN the GOOSE message is been transmitted to. The priority of the GOOSE
message can be determined by a specific VLAN priority number, which is a decimal
value with a range from 1 to 7. Messages with a priority from 1 to 3 are considered low
priority messages, and messages with a priority from 4 to 7 high priority messages.
Also an application identity number (APPID) has to be part of the GOCB. That is a
unique hexadecimal value for sending the GOCB within the network. It identifies the
dataset and GOOSE message. APPID has a hexadecimal range of 0000 to 3FFF.
In order to ensure the arrival of the GOOSE message, it is sent multiple times on
fast intervals. The multiple transmissions are depicted in Figure 8, where vertical lines
present GOOSE messages send by the publisher.

Figure 8. Transmission of GOOSE messages. [8]

 20

When no data change occurs, the GOOSE message is transmitted periodically

according to set MaxTime. Periodic transmissions enable the monitoring of GOOSE
communication. When one or several of the data attributes within the GOOSE dataset
change, the first transmission with the updated data values is send within the configured
MinTime. After the first transmission the same GOOSE message is retransmitted a
number of times until the stable condition time is achieved. This enables the supervision
of GOOSE communication, which was not possible with hardwired solutions. The
receiver can detect communication losses if the periodically sent message disappears.
The actual detection of communication loss is detected according to a parameter called
TimeAllowedToLive. The relation between this parameter and MaxTime is not defined
in the standard, and is therefore manufacturer and product specific. MinTime and
MaxTime are defined in the GOCB. Values for MinTime and MaxTime are application
specific, for example 10 and 1000 milliseconds respectively. [8]

3.3.4. Substation Description Language

A substation automation system is typically project specific, and the introduction of

IEDs has generated a need for propriety software tools for configuration of the IEDs. If
interoperability has to be maintained, a standardized format for configuration data of
both substations and IEDs is essential. Therefore, for describing and configuring an
SAS, a specific Substation Configuration Description Language (SCL) has been defined
in IEC 61850-6. The actual syntax of SCL is defined with Extensible Markup Language
(XML). The XML-schema enables to automatically check the data contained in the
different configuration files described below.
An illustration of the engineering process of an IEC 61850 based SAS is presented
in Figure 9. As depicted in the figure, the engineering process needs different software
tools in order to define the specification of a substation, the characteristics of an IED
and the complete SAS including data and communication models. These programs
produce different kind of files, each using SCL as an interface providing basis for
continuous engineering. There are four separate file types in the IEC 61850 series,
which are described next.
 21

Figure 9. Engineering process of an IEC 615850 based SAS. [17]

The Substation Specific Description (SSD) is a file used to specify the structure of
the electrical switchyard. This type of file is needed when data has to be exchanged
from a system specification tool to a system configuration tool. The file contains all
required logical nodes and describes a single line diagram of the substation. Also, all the
needed data type templates and the logical node type definitions are contained in the
file.
The IED Capability Description (ICD) describes data model and communication
services of an IED in question. This information is exchanged from an IED
configuration tool to the system configuration tool, and it contains the information and
communication facilities available in the IED. With an ICD-file the system engineer can
parameterize communication messages between IEDs.
For a complete description of an SAS, including data and communication models,
the Substation Configuration Description (SCD) is needed. This type of file is required
for data exchange from the system configuration tool to the IED configuration tool. The
SCD file contains all IEDs, substation description section and communication
configuration defining properties for the sending and receiving devices.
Finally, for the data exchange from the IED configuration tool to the actual IED
within a project, the Configured IED Description (CID) is required. This file is
dedicated to a project specific IED, containing all configuration data for fluent operation
of the IED. [18; 19]
 22

3.4. Network
In order to establish a communication network for an SAS described in the IEC 61850
series, certain issues concerning the network have to be decided. The standard defines
qualities required for the performance of the network. Other issues not defined by the
standard include network topology, cyber security and reliability of the network. The
issues related to the network are presented next, as they are as important for the
functionality of the SAS as the definitions of data modeling and communication
services within an IED.

3.4.1. Network Topologies

A communication network can be established by using different network topologies.

There are three basic topologies, namely bus, star and ring. In reality these topologies
can be implemented with numerous variations and hybrids of the three. Different
topologies offer different redundancy and performance for the network. In this chapter
basic network topologies and few common variations suitable for substation LAN are
presented.
In the bus topology each switch is connected to the previous or next switch via one
of its ports, often referred to as uplink ports. These ports are usually operating at higher
speed than the ports connected to the IEDs. An example of bus topology is illustrated in
Figure 10. Although the bus topology is cost effective, it has two major disadvantages.
When the number of switches connected to the bus increases, the delay between the first

Figure 10. An example of bus topology. [20]

and last switch increases as well. The worst case delay, also referred as latency, should
always be considered. The latency of the bus topology can make it not suitable for time-
critical applications, for instance GOOSE messages. Another disadvantage is that bus
topology has no redundancy. If one of the connections between switches is lost,
communication to every IED downstream from that connection is also lost. [20]
The ring topology offers more redundancy compared to bus, as the last switch is
connected back to the first, as pictured in Figure 11. The ring topology forms a loop in
the network, which requires the use of managed switches. The switches should support
Rapid Spanning Tree Protocol, which is depicted in Chapter 3.4.2. In ring topology one
 23

of the switches is configured as backup switch, which breaks the loop in the network. If
one of the connections between switches is lost, the backup switch will establish
connection via another route. This way some redundancy can be achieved. However, if
one of the switches is lost, the communication to all IEDs connected to that switch is
also lost. The advantage of ring topology is improved redundancy in a cost effective
way. It still has the same disadvantage with latency as the bus topology. The added
complexity and cost of managed switches can also be seen as a disadvantage. However,
in the context of this study this is irrelevant, as all switches within the IEC 61850
communication network have to be managed, as depicted later on. [20]

Figure 11. An example of ring topology. [20]

In the star topology all switches are connected to a backbone switch, thus forming a
star configuration as illustrated in Figure 12. This topology offers the best latency
compared to others, since communication between any two IEDs can be established via
the backbone switch. However, it has no redundancy. If one of the switches fails the
communication to IEDs connected to that switch is lost, or if the backbone switch fails,
all the switches are isolated. [20]

Figure 12. An example of star topology. [20]

 24

In order to improve redundancy and latency the basic topologies can be merged.
Basically any combination of topologies can be applied, but in this study two possible
combinations to improve redundancy are presented. A fault tolerant hybrid topology, as
illustrated in Figure 13, can offer enhanced redundancy by implementing two parallel
star topologies connected to form a ring. [20]

Figure 13. An example of fault tolerant hybrid topology. [20]

This kind of hybrid topology can tolerate certain faults, as depicted on Figure 13.
Nevertheless, switches connected to IEDs are not redundant, thus communication faults
can affect the performance of an SAS. By duplicating each switch and connection in the
network a high redundancy can be achieved. This requires dual Ethernet ports in the

Figure 14. An example of duplicated high redundancy topology. [20]

 25

IEDs, as each IED is connected via two separate links to the network. This kind of
topology can tolerate any fault related to network equipment, as illustrated in Figure 14.
Only the failure of an IED will isolate that particular IED from the network. Of course
in critical applications this kind of failure has to be taken into account in the application
itself, for instance by backup protection. [20]

3.4.2. Component Features

The IEC 61850 defines Ethernet as the physical layer of the OSI-model. The use of
Ethernet requires that all IEDs are physically connected to an Ethernet switch. These
connections form a Local Area Network (LAN), which the IEC 61850 uses for
communication. Ethernet is based on frames of information, which can be sent to the
LAN at any time. In order to meet the real-time control requirements of an SAS,
Ethernet switches need to conform to certain features. These features offer advanced
functions for layers 2 and 3 of the OSI model.
The IEEE 802.3x Full-Duplex operation on all ports makes sure that no collisions
appear between the transmitted frames. This is achieved by a store and forward process
within the Ethernet switch. The received packets are first buffered in the memory of the
switch, placed in a queue, and then transmitted one by one as they reach the front of the
queue. This makes Ethernet much more deterministic than the previous methods used
for collision detection. The Full-Duplex operation can be found in unmanaged switches.
However, for all other features required of the switches a managed switch is required.
Therefore, only managed switches should be used with IEC 61850. [20; 21]
In order to ensure that time-critical information can pass through the switches
without additional delay due to store and forward process, the IEEE 802.1p Priority
Queuing has to be implemented within the switches. This feature allows frames to be
tagged with different priority levels, allowing the frames with the highest priority to
bypass the buffered memory of the switch, therefore eliminating additional delay. This
means that priority tagged GOOSE messages are placed in front of the store and
forward queue. The transmission of any frame is not interrupted when a priority tagged
frame arrives in front of the queue. The priority tagged frame is just simply transmitted
next. [20; 21]
The VLAN defined in IEEE 820.1Q allows to logically separate network to virtual
LANs. This means that the same physical network sharing cabling and infrastructure
can contain several VLANs. The different VLANs are indentified by the switches with a
tag header on the Ethernet frame. Each VLAN has its own broadcast domain, which
means that Ethernet frames from one VLAN will not be transmitted onto another
VLAN. Different communication traffic of the IEC 61850 substation network can be
segregated into separate VLANs. These separate VLANs could be used for instance to
substation LAN management, MMS communication, GOOSE messages and sampled
values in IEC 61850 network. The advantages of VLANs concerning GOOSE include
restricted access to VLAN for GOOSE, and preserving free bandwidth as only GOOSE
messages are allowed to use the specific VLAN. The use of VLANs in GOOSE
 26

communication is not mandatory, and is thus decided by the designer. It can be enabled
by configuring the specified VLAN identification in the GOOSE control block, and by
configuring same VLAN to switches in the network. [20; 21]
To achieve network redundancy some form of ring topology has to be applied.
However, if a physical loop occurred in an Ethernet network, the first broadcasted frame
would consume all available bandwidth by circulating endlessly in the loop. This is
prevented by Rapid Spanning Tree Protocol (RSTP), defined in IEEE 802.1w. The
RSTP puts certain links in the network into a backup state, which means that no traffic
is allowed to flow across the link. This way any physical loops in the network are
disconnected. The RSTP enables this by forming a logical tree network including all
switches in the network. If network problems occur, the backup links are re-enabled in
order to restore communication of all devices. This happens automatically within
milliseconds and it works on any network topology. The RSTP also supports
interoperability. Therefore, switches from different vendors can be implemented in the
network. The RSTP has been enhanced by proprietary protocols. However, as they are
not standardized solutions, they are not presented in this study. [20; 21]
The Internet Grouping Message Protocol (IGMP) Snooping/Multicast filtering
allows the sending of multicast frames in the network, which are then filtered and
assigned to those IED’s which request them. In IEC 61850 station bus GOOSE
messages are sent as multicast frames, hence the requirement for IGMP is justified. [12;
15]
An important protocol related to redundancy is called Simple Network Management
Protocol (SNMP). This protocol enables to verify the redundancy of the network in
regular intervals. Therefore, any faults related to the network can be detected and
recovered in order to maintain the redundancy of the network. [2]

3.4.3. Data Transfer Medium

The IEC 61850 defines Ethernet as a standard medium for the communication. Ethernet
supports both widespread CAT5/RJ45 copper cabling and fiber optics. However, IEC
61850 does not specify whether copper or fiber optics should be used. This creates a
technological and economical dilemma, as fiber optics has technical advantages but also
a higher cost compared to copper cabling. Fiber optic cabling is immune to
electromagnetic interference (EMI), which makes it well suitable for substation
environment. Other advantages of fiber optics include ability to span long distances and
maintain extensive bandwidth. The problem between copper and fiber cabling can be
solved by a compromise. Copper interconnections between IEDs and Ethernet switches
can be used for instance between bays and to use fiber to connect switches between
switchgears. This compromise can be justified by the fact that IEDs within a bay are
usually located inside the switchgear where connections are relatively short, therefore
inducting less EMI to copper cabling. In the field of process industry electrification
IEDs and Ethernet switches are usually located in metal enclosed cabinets. This creates
a Faraday shield which removes EMI within the cabinet. The use of copper cabling in
 27

such cases is therefore further justified. However, the designer of the network should
always compare between costs saved versus reliability and criticality of the electrical
system.
Fiber optics has two basic types available in the market. These are multi-mode and
single-mode fiber. A multi-mode fiber requires less expensive light source, but has
limitations regarding distance and bandwidth. It can reliably carry signal over a distance
of two kilometers at bandwidth of 100 Megabytes Per Second (MBPS) or 300 meters at
1000 MBPS. The single-mode fiber is more expensive as it requires a high quality laser
light source. Its advantage is that it allows nearly infinite bandwidth with distances
exceeding 100 kilometers. [21]

3.4.4. Information Security

When communication is performed via network, information security has to be

considered. Generally information security of an SAS has been achieved by physically
isolating the communication network from Wide Area Networks (WANs). Together
with restricted access to the substation facility the isolation provides effective means to
implement a required security level, as only authorized personnel are allowed to gain
access to the network components. Access to network components should be restricted
also within the substation, in order to avoid unintentional access to networks with
critical tasks, such as networks used for IEC 61850-communication. In electrification of
process industry, this means that the IEC 61850 network is situated in the same facilities
as the switchgear equipment. However, interconnections to WANs might be required,
for instance to provide customer support via internet. Usually this is done by a
controllable switch, so that the owner of the switchgear can decide whether external
communication is allowed or denied. If such interconnections are allowed, the
substation LAN becomes vulnerable for attacks.
The IEC 61850 standard does not define information security, although it uses
common protocols, such as Ethernet and TCP/IP, for data transmission. The IEC TC 57
recognized a need for another standard to specify security issues that would encompass
the IEC 61850 series. This led to the development of IEC 62351, which covers security
issues for IEC 60870-5, IEC 60870-6 and IEC 61850 series. Security for IEC 61850 is
presented in part 6 of the IEC 62351 standard. For security issues concerning GOOSE
the standard states that applications requiring multicast addressing and 4ms response
times should not be encrypted. Instead, a communication path selection process should
be used, which means that GOOSE messages should be restricted to a logical substation
LAN. [22; 23]
Substation LAN should be designed as a private network, however, interconnections
to WANs might be required, thus making the substation LAN vulnerable for attacks.
The interconnections to WANs are enabled via a gateway. The gateway should provide
security by using a firewall and an encrypted Virtual Private Network (VPN). However,
it should be stated that because GOOSE does not use TCP/IP protocol, it is not possible
to send GOOSE messages trough a gateway. Therefore, possible harm to GOOSE
 28

communication via a gateway can only be produced by reducing available bandwidth.

This problem can be resolved by using encrypted VLANs, which secure configured
bandwidth for each VLAN. [22; 23]
Information security can be further improved via layered security. Managed
switches offer several means to implement this. By using VLANs, critical applications
can be isolated in the same physical network. Switches can also have so called managed
security by means of SSL/SSH. Independent port security and IEEE 802.1x can be
deployed to deny physical access to the network. This means that only recognized
computers can be connected to the network. The IEC 62351 working group is exploring
more methods for making IEC 61850 and GOOSE messages more secure. [21]
 29

4. APPLICATIONS OF GOOSE

Horizontal communication has a variety of possible applications in substation

automation. Based on the input from the project team, only the most relevant
applications for ABB Process Industry’s PDC-solutions are considered. This input
consists of prior experience and solutions used in customer projects. The selection of
applications was also affected by the fact that the implementation should be possible
with ABB’s REF615 IEDs.

4.1. Process Industry Electrification

Process industry in general refers to metal-, petrochemical- and forest industry. ABB
Process Industry is specialized in electrification and instrumentation of pulp and paper
factories. The variety of completed customer projects is large, including both greenfield
and renovation sites. From the perspective of electrification, each project is unique and
the scale varies substantially. An overview of process industry electrification equipment
is presented in Figure 15.

Figure 15. A general overview of process industry electrification.

 30

Typically industrial power systems have relatively high short-circuit currents and
the power density of the system is high. Most of the load consists of electric motors
with a majority of asynchronous motors. This can create disturbances in the power
system if adequate filtering is not implemented. In order to ensure the persistence of the
industrial process different control and data acquisition systems need to be
implemented. These include systems for power distribution control and process
automation. [24]
In complete electrification of a pulp and paper factory the scope of the project is
vast. Electrification starts with the energy production, which can be done either locally
or via a distribution network. If the required energy is produced locally by generators,
they require adequate protection. Energy can also be transferred from power plants via
transmission lines, which requires substation with either Air-Insulated Switchgear (AIS)
or Gas-Insulated Switchgear (GIS). In the transmission level reactive power
compensation might also be required by local distribution company. Electrical energy is
transferred from the generators or switchgear trough transformers to Medium Voltage
(MV) switchgears. The MV switchgear supplies power to MV motors and possibly to
MV frequency converters. Adequate protection for motors is required, and the use of
frequency converters usually demands harmonic filtering. From the MV switchgear
power is further supplied to Low Voltage (LV) switchgear via distribution transformers.
The LV switchgears provide power to LV motors and other process equipment, for
instance instrumentation devices. Instrumentation and its requirements are beyond the
scope of this study.
Trough the complete chain of power distribution, adequate protection and control of
the equipment must be provided. This means that the power system is safe to use and it
can isolate faults preferably without interrupting critical processes. The designing of a
dependable power system is always a task of economical optimizing. This means that a
certain amount of interruptions must be tolerated, because a totally dependable system
would be too expensive. In process industry electrification even short interruptions in
power distribution can cause substantially long or expensive interruptions in the
industrial process. [24]
The presented power system requires a control and monitoring system, possibly with
an interface to local power company’s control system. An interface with process
automation control system is often required as well. This creates challenges for the
engineering of communication, as different control systems need to be able to exchange
information.

4.2. Conventional Solution

Information exchange between bay level devices is conventionally realized by
hardwiring. This means that any information which should be transferred to another
IED is assigned to an output contact. The terminals of this output contact are then wired
to an input in the receiving IED. The functions of the inputs are configured in the
 31

receiving IED by using proprietary configuration software. The principle of hardwiring

is to use specific wiring for every transferred signal. As a number of inputs and outputs
are needed to interact with the circuit breakers, disconnectors and earth switches, the
use of hardwiring is limited to the available number of inputs and outputs of a given
IED.

Figure 16. An example of horizontal communication via hardwiring.

An example of a hardwired solution can be illustrated by a simple blocking scheme,

which is presented in Figure 16. If any of the feeder IEDs, for example IED 1 detects an
overcurrent situation, the start signal of overcurrent protection is transferred upstream to
IED 0 via hardwiring marked with red lines. This signal can then be used to block the
fast stage overcurrent protection in the incomer IED 0, allowing the feeder IED 1
enough time to send a trip signal for clearing the fault. Without the blocking scheme,
the upstream IED 0 would detect the overcurrent and send a trip signal, which would
interrupt power flow for all feeder IEDs. Therefore, blocking can reduce the size of the
affected area in fault situations. However, in order for the blocking application to work,
the overcurrent start signal will have to be hardwired from all feeder IEDs, therefore
resulting in a lot of assembly work and wiring.
When the number of IEDs increases, the number of individual wires becomes
excessive due to the information exchange required between all relays taking part in the
blocking application. Within an SAS there can be a number of other applications, which
require horizontal communication between IEDs. Typical signals between switchgear
bays include breaker, disconnector and earth switch status signals, service and
interlocking position information, and protection start signals. Hardwiring is also used
for signaling to and from external systems, for example Remote Terminal Units (RTU)
or other automation systems. As well as the signals between bays, current, voltage and
 32

power measurements are transferred. This is often the case in process industry
electrification, where process automation and SAS have interfaces.

4.3. GOOSE Solution

The purpose of GOOSE messages is to replace hardwired signals by unambiguously
naming all elements of data and then transferring this data via Ethernet network station
bus. This is illustrated in Figure 17 with a similar scheme as presented in the previous
chapter. The use of GOOSE can be achieved by using the object model of substation
information, which is described in IEC 61850-7-4. When the object oriented data model
is used, each data attribute will have a unique name in the whole substation, and thus the
subscriber and publisher of this data will know where it originated. Required data for
certain application can be organized and transferred as GOOSE message.

Figure 17. An example of horizontal communication via GOOSE

The configuration of GOOSE messages is done by using proprietary software tools.

The desired data attributes are attached into a dataset, and this dataset is then configured
to be sent as a GOOSE message. The sending of a dataset via GOOSE needs specific
GOOSE Control Block, where essential information regarding GOOSE traffic is
presented. Detailed description of GOCB is presented in Chapter 3.3.3. The subscribers
of the GOOSE message are also defined in the configuration process. Information sent
via GOOSE needs to be configured in the receiving IEDs to perform the desired
function. This is done by virtually connecting the signals inside the IED and configuring
them to perform desired application. After the configuration is done, the information of
the SCD file is uploaded separately into IEDs. All IEDs within the substation need to
 33

get this information, therefore the proprietary software tools must be able to import the
SCD file into the IEDs via network. Finally the physical connections have to be
established by implementing Ethernet switches and cabling between substation IEDs.
The requirements for network components are described further in Chapter 3.4.2.

4.4. Benefits of GOOSE

Extensive hardwiring of signals creates significant cost in switchgear installations. The
amount of hardwiring required for typical 10-bay medium voltage switchgear
installation is pictured in Table 8. When the amount of hardwiring needed is so vast, it
becomes apparent that the use of GOOSE communication can significantly reduce costs
in switchgear installations. [25]

Table 8. I/O wiring in conventional hardwired medium voltage switchgear. [25]

Number of IO wires Between protection Between other Total
and control devices devices
Inter-bay signaling 104 116 220
Automation system 85 47 132
Other external
383 252 635
systems
Total 572 415 987

An important characteristic of GOOSE is that communication is monitored. As

presented in Chapter 3.3.3 GOOSE messages are sent periodically even if no data
change occurs. If these periodically sent messages disappear, the loss of horizontal
communication can be detected. In conventional solutions, failure in the communication
can be detected either in regular testing, or when an application fails to work. The
period for regular tests is from one to three years depending on the customer. Thus in
practice the communication is not monitored at all in hardwired solutions. In GOOSE
based solutions communication failures can be detected within seconds, depending on
the IEDs.
Other benefits of GOOSE include the expandability of the SAS without additional
hardwiring between IEDs. New hardwiring is only required between process equipment
and the implemented IEDs. Similarly, new applications or modifications to existing
applications can be implemented without incremental hardwiring, as required data can
be transferred via GOOSE.

4.5. GOOSE Applications

Different protection and control applications, which can be realized by using GOOSE
communication, are presented in the following chapters. Each application is first
described in general, and then the functions and signals required for GOOSE solution
 34

are presented. The functions and signals are defined according the IEC 61850 standard.
The signals are presented in tables, for example Table 9. These tables state the name of
the GOOSE publisher IED and the name of the GOOSE subscriber including the
function block input where the GOOSE signals needs to be connected. On the third
column a general description of the signals is given followed by an example of the
required data attributes for ABB’s REF615 IED’s. The underlined parts of the name
path are defined by the standard, whereas other parts can be chosen by the vendor, in
this case ABB. The data attributes for each signal were found by investigating the
appropriate LN for the application from the IEC 61850. Manuals for REF615 IEDs were
also used as a source in order to create examples of the applications. By examining the
list of data classes defined for that LN the correct data objects were selected. Similarly,
the data classes have defined tables of data attributes, from which the proper attributes
for each signal could be selected. Because the names of the LNs, data classes and data
attributes are defined by the standard, they were easy to locate in the IED
communication configuration software.

Table 9. An exemplary table of the application signals.

Publisher Subscriber Signal Data attributes for REF615
description
Publisher Subscriber General LD.$$LN$$.DataClass.DataAttribute
IED’s IED’s name description
name Function Block
Input

The REF615, which was selected for this study by the project team, is a dedicated
feeder IED. It is designed for protection, control, measurement and supervision of utility
substations and industrial power systems. The REF615 is designed according to IEC
61850, therefore it fully supports GOOSE communication. The REF615 can be ordered
in six different variants from A to F, which all include a different standard
configuration. The GOOSE communication is application specific, and therefore it has
to be individually configured to IEDs depending on the application. In the following
chapters selected applications for this study are presented, and the possible
implementation with REF615 IEDs is given as an example.

4.5.1. Bay Interlocking

Switchgear interlocking is used to prevent switchgear operation, which could lead to

malfunction or damage of primary switching equipment. This is achieved by comparing
switch positions in related switches or disconnectors, and determining the individual
interlocking conditions to switches according to logical rules. Based on the logical rules
between switch positions, interlocking can either prevent or allows switching execution.
The conditions for interlocking depend on the station configuration. In bay interlocking
 35

only the switch positions in the same bay are evaluated, as presented in the following
example.
In order to provide safe working conditions for assembly or maintenance work in
switchgear certain conditions have to be met. The switchgear must be isolated from the
power system and it must be grounded. Generally, this means using two types of bay
interlocking. When the disconnector is closed, the closing of the earth switch circuit
breaker is locked. Another type of interlocking must be used when earth switch is
closed, and the work in the switchgear is in progress. In this case all disconnectors of
lines capable of power feed to the line in question must be locked to open position.
Therefore, the closing of related circuit breakers has to be locked. The status values of
disconnectors and earth switches are conventionally hardwired in order to implement
this type of interlocking applications. These values can be transmitted via GOOSE by
using the signals provided in the logical node XSWI. These signals are presented in
Table 10 with descriptions.

Table 10. Signals for bay interlocking example.

Publisher Subscriber Signal description Data attributes
Infeed Feeder IED 1 Disconnector position
IED 0 CBXCBR1 Position closed CTRL.DCSXSWI1.PosCls.stVal
BLK_CLOSE Position ok CTRL.DCSXSWI1.PosOk.stVal
Feeder Infeed IED 0 Earth switch position
IED 1 CBXCBR1 Position closed CTRL.ESSXSWI1.PosCls.stVal
BLK_CLOSE Position ok CTRL.ESSXSWI1.PosOk.stVal

An example of bay interlocking is pictured in Figure 18. For simplicity, only one
disconnector and one earth switch are presented. If the disconnector is closed, the
Feeder IED1 controlling the earth switch needs the position closed and position ok
signals from the Incomer IED0, which are depicted in blue color in Figure 18. The
position ok signal means that the disconnector is not between positions, in other words
the information is valid. If either of the signals equals true, the closing of the related
circuit breaker is locked. In the case of REF615 this is done by virtually connecting
signals via a logical OR gate to CBXCBR1 function BLK_CLOSE input. Similarly, in
the opposite case, when the earth switch is closed, the Infeed IED0 needs the signals
stating that the earth switch position is closed and ok. These signals are virtually
connected via OR gate to the locking input of CBXCBR1.
 36

Figure 18. Example of bay interlocking application.

The control functions providing these signals are included in variants B, D, E and F
of REF615. There are three functions for disconnectors and one for earth switch
indicator. In the given example only one disconnector function is applied, the other two
functions are separated by increasing the number after the LN.

4.5.2. Inter-Bay Interlocking

In interlocking schemes, where switch positions in other bays need to be taken into
account the applications are referred to as inter-bay interlocking. Conventionally, an
SAS is used for inter-bay interlocking schemes. In these schemes all feeder and bay
controllers report the switch positions to a station controller, which then evaluates and
defines interlocking conditions. In conventional designs, this leads to a vast amount of
hardwiring.
When similar schemes are realized by using GOOSE, the switch positions can be
transmitted directly between bay controllers, as presented in Figure 19. The evaluation
and definition of interlocking conditions can be done directly in the IEDs instead of the
station controller. When switch positions are transferred as GOOSE messages, only the
signals controlling the disconnectors remain hardwired. Therefore, the need of
hardwiring is reduced. As interlocking schemes depend on station configuration, an
overall description of transmitted signals is not possible. However, interlocking
applications can be represented by the example depicted in Figure 19. In the example,
interlocking is used to enable or interlock the circuit breaker QA1, which connects the
two busbars.
 37

Figure 19. An example of inter-bay interlocking application.

In the IEC 61850 a logical node called SCILO is defined for interlocking purposes.
However, this LN is not included in the REF615 IEDs and therefore they can only be
used to send required information for interlocking function located in the bus coupler
IED. The configuration of the interlocking logic to the SCILO LN is beyond the scope
of this study. Instead, exemplary switching conditions for bus coupling disconnectors
and circuit breaker are given in Table 11.

Table 11. Switching conditions for bus coupler bay.

Switch and direction Interlocking conditions
QA1 open not allowed if:
((feeder 1A: QB1 = closed) AND
(feeder 1A: QB2 = closed)) OR
((feeder 2A: QB1 = closed) AND
(feeder 2A: QB2 = closed))
QA1 close allowed if:
the disconnectors of the bay are not
between positions AND
earthing switches QC1 and QC2 are
open
QB1 open / close allowed if:
QA1 = open
QB2 open / close allowed if:
QA1 = open
 38

For the given exemplary switching conditions, the signals presented in Table 12
should be transmitted via GOOSE, in order to transfer required information for the
interlocking scheme. Both feeder IEDs publish the status information of their
disconnectors and earthing switches. As stated in Table 11, the opening of circuit
breaker QA1 is not allowed if both disconnectors in either bay 1 or bay 2 are closed.
Therefore, the data attributes CTRL.DCSXSWI1.PosCls.stVal and
CTRL.DCSXSWI2.PosCls.stVal are included in the GOOSE message. In order to verify
that disconnectors are not between positions the PosOk.stVal attributes are transferred.
Similar attributes indicate that earthing switches are open and not between positions.
Thus, all required information for this exemplary interlocking function is transferred via
GOOSE.

Table 12. Signals for inter-bay interlocking example.

Publisher Subscriber Signal description Data attributes
Feeder Bus Disconnectors QB1 CTRL.DCSXSWI1.PosCls.stVal
bay 1 coupler and QB2 in bay 1 are CTRL.DCSXSWI1.PosOk.stVal
closed and not CTRL.DCSXSWI2.PosCls.stVal
between stages, and CTRL.DCSXSWI2.PosOk.stVal
earthing switch QC1 CTRL.ESSXSWI1.PosOpn.stVal
is open. CTRL.ESSXSWI1.PosOk.stVal
Feeder Bus Disconnectors QB1 CTRL.DCSXSWI1.PosCls.stVal
bay 2 coupler and QB2 in bay 2 are CTRL.DCSXSWI1.PosOk.stVal
closed and not CTRL.DCSXSWI2.PosCls.stVal
between stages, and CTRL.DCSXSWI2.PosOk.stVal
earthing switch QC2 CTRL.ESSXSWI1.PosOpn.stVal
is open. CTRL.ESSXSWI1.PosOk.stVal

In real interlocking applications the number of required position signals is often

vast. For simplicity, the number of signals was kept low in this example. The REF615
IEDs do not have the required logical node SCILO for creating interlocking logic.
However, standard configurations B, D, E and F have the required control functions for
transferring disconnector and earth switch positions. For the actual implementation of
sophisticated interlocking schemes more complex IEDs, for instance RE_630, RE_650
or RE_670 are required.

4.5.3. Reverse Blocking

Blocking applications are used to restrict a fault in the power system to a smaller area.
One typical application is reverse blocking, which is used for high speed busbar
protection. In reverse blocking the instantaneous overcurrent protection stage of an
upstream incomer IED is blocked by a downstream feeder IED, which operates and
isolates the fault. By blocking the fast operation of the incomer IED, the influence of the
 39

fault can be limited to the feeding line where the fault occurred. If the feeder IED
cannot isolate the fault, the incomer IED will clear the fault after the predefined delay of
low stage overcurrent protection. The blocking signal is transferred in reverse direction
compared to power flow, hence the name reverse blocking. Conventionally, this
application needs hardwiring for each blocking signal from the feeder IEDs to the
incomer IED. If the same application is realized with GOOSE, the blocking signals can
be transmitted via GOOSE messages. In IEC 61850 the logical node PTOC is defined
for time overcurrent protection. Depending on proprietary solutions, the PTOC LN can
have more than one function with different operation time characteristics. For example,
in ABB’s REF615 IEDs, there are four PTOC functions for non-directional overcurrent
protection. These are named PHLPTOC1, PHHPTOC1, PHHPTOC2 and PHIPTOC1
for low, high and instantaneous stages respectively, including two instances for high
stage. The following example uses these function blocks in order to demonstrate a
reverse blocking application, as depicted in Figure 20.

Figure 20. Example of reverse blocking application.

When one of the feeder IEDs high stage overcurrent protection function detects a
fault, the start signal is sent via GOOSE to incomer IED 0. This start signal is
configured to block the instantaneous stage overcurrent protection in IED 0, and
therefore the feeder IED has a chance to clear the fault by tripping related circuit
breaker. If this does not clear the fault, the high stage overcurrent protection of the
incomer IED will operate, and clear the fault after the configured delay time. The use of
reverse blocking can thus potentially minimize the impact of a fault.
 40

Table 13. Signals for reverse blocking example.

Publisher Subscriber Signal description Data attributes
Feeder 1 Incomer IED Start signal of high stage LD0.PHHPTOC1.Str.general
PHIPTOC1 non-directional
BLOCK overcurrent protection
Feeder 2 Incomer IED Start signal of high stage LD0.PHHPTOC1.Str.general
PHIPTOC1 non-directional
BLOCK overcurrent protection

The signals required for the presented example are listed in Table 13. The required
function of non-directional overcurrent protection is available in standard configurations
A to E of REF615 IEDs.

4.5.4. Breaker Failure Protection

When an IED detects a fault in the power system, it will operate and send a trip signal to
the circuit breaker. Under normal conditions the circuit breaker will open and isolate the
fault from the power system. Thus the operation of a circuit breaker is essential for the
protection function to perform as desired. If the circuit breaker fails to operate, the fault
can cause further damage or threat the stability of the power system. In order to avoid
this, a breaker failure protection can be implemented. This is achieved by monitoring
the time delay between the trip signal and the actual opening of the circuit breaker. If
the fault current has not been interrupted within a set time delay from the circuit breaker
trip, the breaker failure protection is initiated. This is realized by sending a trip signal to
adjacent circuit breakers in order to ensure that the fault is isolated. This trip signal can
be sent via GOOSE communication.

Table 14. Signals for circuit breaker failure example.

Publisher Subscriber Signal description Data attributes
Feeder 1 Incomer IED Signal for external LD0.CCBRBRF1.OpEx.general
TRPPTRC1:1 backup trip
TRIP
Feeder 2 Incomer IED Signal for external LD0.CCBRBRF1.OpEx.general
TRPPTRC1:1 backup trip
TRIP

In ABB’s REF615 there is a specific function for circuit breaker failure protection,
the CCBRBRF, which is based on the RBRF logical node defined in IEC 61850. The
function is available in all standard configurations of REF615. This function has two
independent timers for re-tripping. One timer is for internal re-trip of its own breaker
and another for external back-up trip. The required signals for external upstream trips
 41

are listed in Table 14. This signal can be configured in the receiving IED to perform
tripping of related circuit breaker. An illustration of the example is given in Figure 21.

Figure 21. An example of circuit breaker failure protection.

In the presented example both feeder IEDs have circuit breaker failure function. In
case of breaker failure, the function will try to re-trip the circuit breaker after the initial
trip signal has failed. If the re-trip signal cannot isolate the fault, the function will send
back-up trip signal to upstream incomer IED. This signal is configured in the incomer
IED to trip the related circuit breaker. The breaker failure protection is useful for
achieving the n-1 criterion, which means that the fault is cleared from the system even if
one component fails to clear the fault.

4.5.5. Fault Arc Protection

Fault arc protection is used to detect arc situations in air insulated metal-clad
switchgear, which can be caused by insulation breakdown during operation or human
errors during maintenance. According to IEC 61850, the arc protection is realized by
protection logical node SARC. This LN is used as a function, which monitors phase and
residual currents and can detect light either locally or remotely in order to make
accurate decisions on ongoing arc situations. When an arc situation is detected, the
function sends trip signal to the related circuit breaker. However, if the arc is located
upstream in relation to power flow direction, the circuit breaker cannot isolate the fault.
This can also be the case if the arc is located within the circuit breaker compartment. In
these cases, the arc protection IED can send fault arc detection signal to upstream IED
which can isolate the fault by opening the related circuit breaker. This signal can be sent
 42

by using GOOSE. The upstream IED is also equipped with SARC function and the arc
fault detection can be used as an input in remote light detection. In order to avoid
unnecessary tripping, it is convenient if the arc protection IED has different light
sensors. These sensors can be installed, for example, in the busbar compartment, the
breaker compartment or the cable compartment of the switchgear.

Figure 22. Example of fault arc protection application.

In the REF615s the fault arc protection is available as an optional function in all
standard configurations. As depicted in Figure 22, the REF615 has three different light
sensors for the fault arc detection. In the given example the sensors are placed in the
cable compartment, the circuit breaker compartment and the busbar compartment. If one
of the feeder IEDs detects an ongoing arching situation in either sensor 1 or 2, the IED
sends a GOOSE message to the upstream incomer IED. Because the sensors one and
two are in the busbar and the circuit breaker compartment, the feeder IED cannot isolate
the fault. The fault arc detection signal is transferred to incomer IED, where it is
virtually connected to the related ARCSARC function as remotely detected arc fault.
Together with phase current values the function concludes that there is an arching
situation, and opens the circuit breaker. The result is the same whether the light is
detected with sensor 1 or sensor 2.
 43

Table 15. Signals for fault arc protection.

Publisher Subscriber Signal description Data attributes
Feeder 1 Incomer IED Fault arc detected:
ARCSARC1 Light sensor 1 LD0.ARCSARC11.FADet.stVal
REM_FLT_ARC
ARCSARC2 Light sensor 2 LD0.ARCSARC21.FADet.stVal
REM_FLT_ARC
Feeder 2 Incomer IED Fault arc detected:
ARCSARC1 Light sensor 1 LD0.ARCSARC11.FADet.stVal
REM_FLT_ARC
ARCSARC2 Light sensor 2 LD0.ARCSARC21.FADet.stVal
REM_FLT_ARC

The required signals for this example are listed in Table 15. Arc fault protection was
selected by the project team as the application that would be demonstrated and tested as
a part of this study. Therefore, detailed description of the configuration and testing of
transferred arc protection trip is presented in Chapter 5.

4.5.6. Triggering of Disturbance Recording

When a fault occurs in a power system, a disturbance record from a time period
including values prior and after the fault can be very useful on order to analyze why the
fault occurred. In IEC 61850 a dedicated LN is defined for disturbance recording, which
is named RDRE. This LN describes basic functions of the disturbance recorder. For
consistent modeling, the disturbance recorder function is decomposed into one LN class
for analogue channels and one LN class for binary channels, named RADR and RBDR
respectively.
In IEDs the triggering of disturbance recording can be configured to happen
automatically, for example when a trip signal is commenced. In some cases it would be
useful to have disturbance records from other parts of the power system as well, in order
to see how the fault has affected them. The triggering of these recordings can be
achieved by GOOSE communication. For instance, the trip signal of an IED can be send
via GOOSE to adjacent IEDs, and this signal can be used as a trigger of disturbance
recording.
In the example pictured in Figure 23 the start signals of overcurrent protection are
being used to trigger the disturbance recorder in the incomer IED. The standard defines
PTOC function for non-directional time overcurrent protection. In REF615 IED’s there
are low stage, high stage instance 1, high stage instance 2 and instantaneous stage
functions for non-directional time overcurrent protection. The functions are named
PHLPTOC1, PHHPTOC1, PHHPTOC2 and PHIPTOC1 respectively. The non-
directional overcurrent protection functions are available in standard configurations A to
E. In standard configuration F overcurrent protection is directional, and its functions are
 44

named DPHLPDOC1, DPHLPDOC2 and DPHHPDOC1, with two instances for low
stage. The instantaneous stage remains non-directional, therefore the PHIPTOC1
function is used. These functions have similar data attributes for GOOSE
communication, thus only non-directional functions are presented in this example.
Start signals of all three stages are transferred via GOOSE to the upstream IED as
pictured in Figure 23. If the disturbance records are required only from actual fault
situations, the operate signal of the protection functions can also be used. In this case
the last two parts of the transferred data attribute’s name would be changed to
Op.general.

Figure 23. Example of disturbance recorder triggering.

In REF615 IEDs the disturbance recorder has up to 12 analog and 64 binary signal
channels. This function is available in all standard configurations. The triggering of
these channels can be done in several ways. The analog channels can be triggered on
limit violations, and the binary channels on state changes. Both channel types can also
be triggered periodically or manually. The manual triggering can be done via a
parameter called trig recording. The trig recording can be configured to start via local
human machine interface (HMI) or GOOSE communication. If GOOSE communication
is used, the incoming signal is virtually connected to one binary input, which triggers
the recording for all configured channels. It would be convenient to use one binary input
for all trigger signals transferred via GOOSE. In this example channel one is chosen, as
depicted by C1 in Figure 23.
 45

Table 16. Signals for triggering of disturbance recorder.

Publisher Subscriber Signal description Data attributes
Feeder 1 Incomer Time overcurrent
IED protection star signal:
RDRE:1 Instantaneous stage, LD0.PHIPTOC1.Str.general
C1 High stage instance1, LD0.PHHPTOC1.Str.general
High stage instance2, LD0.PHHPTOC2.Str.general
Low stage LD0.PHLPTOC1.Str.general
Feeder 2 Incomer Time overcurrent
IED protection star signal:
RDRE:1 Instantaneous stage, LD0.PHIPTOC1.Str.general
C1 High stage instance1, LD0.PHHPTOC1.Str.general
High stage instance2, LD0.PHHPTOC2.Str.general
Low stage LD0.PHLPTOC1.Str.general

Table 16 presents exemplary signals for disturbance recorder triggering. In this

example the start signals of time overcurrent protection are used. The start signals of all
four instances are transferred via GOOSE to the incomer IED. These signals are then
virtually connected through a logical OR gate to RDRE:1 channel C1. Thus any of the
signals will trigger the disturbance recorder.

4.5.7. Future Applications

The use of IEDs supporting IEC 61850 enables the implementation of several protection
and control applications via GOOSE. The applications presented in this study were
selected because they are relevant for ABB Process Industry, and can be realized with
ABB’s REF615 IEDs. However, with more sophisticated IEDs the possibilities of
GOOSE based applications increase. Two possible applications for future research are
shortly presented below.
When two circuits with different power sources are connected through impedance, a
Synchronism Check (SC) is required. In IEC 61850 a specific logical node, RSYN, is
defined to perform as an SC function. The RSYN function monitors the conditions on
both sides of a breaker, and verifies that conditions are safe before closing the breaker.
The verification of synchronism is done by comparing the voltages on both sides of the
breaker. The difference in magnitude, phase angle and frequency has to be within
certain limits, in order to maintain the stability of the power system and minimize
possible internal damages. The IED which compares the voltages requires magnitude,
phase angle and time stamp of all phase voltages, as pictured in Figure 24.
 46

Figure 24. An example of synchronism check

In the presented example bus has two possible feeders, a generator or transmission
line. When the generator is, for instance, under maintenance and the power feed needs
to be transferred to transmission line, a synchronism check is required. The SC IED
subscribes the line voltages from the line protection IED as an analogue GOOSE
message. The challenge of analogue GOOSE messages is the time synchronization of
the network. In order to provide accurate information, the time difference in the network
should be less than one microsecond. [27] The bus voltages are transferred straight from
a bus VT via conventional hardwiring. The RSYN function compares the difference of
the values, and decides whether the closing of the circuit breakers is safe or not.
However, this application requires the use of more complex IEDs including the RSYN
function, and is not presented in detail in this study.
Another application where GOOSE could be implemented is transformer differential
protection. According to IEC 61850, a logical node PDIF is defined for differential
protection. In this scheme differential protection IED requires three phase currents from
the High Voltage (HV) and LV sides of the transformer. Depending on the grounding
method the residual current of the transformer might also be needed. Based on this
information the differential protection IED can decide whether a fault is inside its
protection zone or not. The currents from LV side and residual current of the
transformer can be transferred to the differential protection IED via GOOSE as
presented in Figure 25. The LV side protection IED publishes three phase current values
as GOOSE message and the differential protection IED subscribes it. If a neutral point
earth-fault IED is required, it publishes residual current as GOOSE message and the
differential protection IED subscribes it.
 47

Figure 25. An example of differential transformer protection.

Both of the presented future applications extend the use of GOOSE to transfer
measurement values. In the IEC 61850 standard sampled values are defined for this
purpose. However, the sampled values are defined to originate straight from the process
equipment, i.e. current and voltage transformers with native IEC 61850 support.
Because such instruments are not yet available in the market, the presented schemes can
only be implemented by using either GOOSE or hardwiring to transfer measurement
values. According to ABB experts, applications utilizing GOOSE for transferring
measurement values are currently being evaluated. Similarly, the performance of
presented schemes should be tested before actual implementation.

4.6. Reliability and Redundancy

The requirements for the reliability of an SAS are described in IEC 61850-3 Clause 4.
These requirements refer to IEC 60870-4, which specifies performance requirements for
a telecontrol system. In IEC 60870-4 different properties, which influence the
performance of a system, are defined and classified. These properties include concepts
of reliability, availability, maintainability, security and integrity. According to IEC
61850-3, any single point of failure should not cause the substation to be inoperable.
[26] This means that all components, including those used only for communication,
should be reliable enough to meet this demand.
The concept of reliability is defined as the measure of a system to perform its
intended function under specified conditions for a specified period of time. The
reliability can be described by Mean Time Between Failures (MTBF), which means the
statistical period of time in hours between any component failure in the system. From
MTBF values of a component a failure rate can be calculated by dividing the number of
 48

failures with the time taken into consideration. If no valid data is available, failure rate
can be estimated as inverse MTBF, as shown in Formula 1. [27]
1
Fr = (1)
MTBF
For a complete system the failure rate can be calculated from the individual
components. If the components are in series, the total failure rate is the sum of the
components’ failure rates. If the components are parallel the MTBF values can be added
together, resulting to smaller failure rate. The total failure rate and total MTBF of a
system can be calculated according to these rules. Other indicators of redundancy can be
calculated with these values.
The concept of availability is defined as the ability of a unit of a system to perform
its function on a given instant. The availability is a probability figure, which concerns
operation on a given instant, whereas reliability concerns operation over a given time
period. Availability A can be calculated if the uptime and the downtime of the system
are known, as presented in Formula 2.
uptime
A= ⋅100% (2)
(uptime + downtime)
According to IEC 60870-4, the Formula 2 is applicable if there are statistics from a
period of twelve months regarding the equipment and six months regarding the system.
If these times are not known, the predicted availability Ap can be calculated by using the
MTBF and Mean Time To Repair (MTTR). The predicted availability can be calculated
with Formula 3. [27]
MTBF
Ap = ⋅100% (3)
( MTBF + MTTR )
The concept of maintainability is described as the ability of a system to restore its
operation and maintain it under normal working operations after detection of a fault.
Maintainability is expressed in hours by Mean Time To Restoration (MTTR), which
means the sum of different tasks required to restore the operation of the system.
In this context the concept of security means that any single component failure
should not result in a critical failure in the system. In GOOSE communication this can
be achieved by applying redundant network topologies, as described in Chapter 3.4.1.
Solutions concerning information security are presented in Chapter 3.4.4. [27]
The term data integrity is defined as the unchangeability of information between a
source and a destination. Data integrity with GOOSE is guaranteed by sending the
message several times, as presented in Figure 8 earlier in this study. With the GOOSE
message a specific quality bit is also published, thus the subscriber can detect whether
the information in the GOOSE message is valid or not.
The most relevant meters for redundancy and reliability are MTBF and availability
values. During this study reliability information concerning GOOSE communication
was acquired. An Excel template, which calculates the reliability, availability and
MTBF of the whole system, was created based on the MTBF values and number of
components. The template was excluded from this report, as it is only valid to
 49

components used by ABB Process Industry. In order to improve redundancy in GOOSE

applications, the best practices are redundant network topologies and redundant
components.

4.7. Testing
In order to assure the functionality of horizontal communication, both the products and
implementation regarding GOOSE communication should be tested. The general
classifications of quality tests are defined in IEC 61850-4. A more detailed presentation
of conformance testing is presented in Part 10 of the standard. In the IEC 61850-10
specific test cases for GOOSE communication are introduced. Products with native IEC
61850 should pass all these tests, in order to show conformance to IEC 61850.
However, the conformance testing of individual products is out of the scope of this
study. Hence the focus is in the testing of functionality of applications, which are
project specific. The IEC 61850-4 states that when a new SAS is introduced, the system
integrator is responsible for testing all functions. The term system integrator refers to a
turnkey deliverer of an SAS. The testing is carried out by the representatives of the
system integrator and the customer in optional Factory Acceptance Test (FAT) and
mandatory Site Acceptance Test (SAT). The FAT is described as the functional tests of
an SAS manufactured according to customer specification. This means that the
parameters of the SAS are set according to the planned applications. The FAT can be
carried out in the facilities of the manufacturer or other agreed location by using process
simulating test equipment. When the actual installation of the SAS is completed, further
testing of the functionality of the SAS is accomplished trough mandatory SAT. The
SAT is defined as the verification of each data and control point and the correct
functionality within the SAS and also between the SAS and its operating environment.
The SAT is carried out in the whole installed plant by using the final parameters as
defined in the customer specification. [28; 29]

4.7.1. Testing Software

In GOOSE applications it is possible to send messages by using dedicated software

which use the configuration files of the IEDs. Thus the simulation of substation events
is not mandatory. Naturally for the testing of overall performance of the SAS the
simulation is essential. However, if only GOOSE needs to be tested, dedicated software
is sufficient.
For this purpose there are vendor based programs available, such as Omicron’s
IEDScout and ABB’s Integrated Testing Toolbox (ITT). The configuration files of the
IEDs can be loaded into these programs either from database or straight from the IEDs.
The programs can then create virtual IEDs based on the configuration files and send
related GOOSE messages to the network. The functionality of these messages in the
receivers can then be verified. A detailed description of the functionality and use of
these programs is beyond the scope of this study.
 50

4.7.2. Testing Method

The GOOSE applications presented in this study have to be tested in FAT and SAT tests
before actual operation. This can be achieved by simulating the related process events
and verifying the desired operation of the SAS. This should be done similarly as when
testing hardwired solutions. First the connections to process level equipment in all IEDs
are verified. This means the hardwired connections to voltage and current transformers,
as well as connections to circuit breaker trip coils.
The performance of applications utilizing horizontal communication is tested by the
following method. The required output of IED’s function block is manually activated by
using IED’s local HMI. The output signals from a function are transferred via GOOSE
or hardwire. The transferred signals are connected to function blocks in the receiving
IEDs, where they should activate certain outputs. The receiving function blocks are
accessed via local HMI and the required outputs verified. This procedure is repeated to
all applications. As all connections to process equipment were verified at the beginning,
the performance of applications utilizing horizontal communication is also verified. By
using this procedure, the configuration of GOOSE in the sending IEDs is verified by
activating the correct function block. The connection to receiving IEDs is verified. And
finally the configuration of receiving IEDs is verified.

4.8. Documentation
A substation automation system forms a complex entity with vast amount of equipment,
wiring and signals. Therefore, a detailed documentation of specific definitions of the
SAS is required. The IEC 61850 defines references for SAS documentation in part
61850-4. According to the standard, required SAS documentation can be divided into
two separate groups, hardware documentation and parameter documentation. The
hardware documentation includes circuit diagrams, signal lists and function diagrams
for external equipment. The circuit diagrams should describe links between SAS
components and their connections with the primary process equipment. The parameter
documentation consists of configuration list, signal lists and parameter lists. Graphical
displays and operation menu sequences as well as function diagrams for internal
features such as IED internal function blocks should be included in the parameter
documentation. The interfaces between hardware and parameter documentation are the
signal lists, which should have identical identifiers in both documentations. [29]

4.8.1. Relevant Documentation

A complete description of SAS documentation is beyond the scope of this study, but
documentation concerning GOOSE is an essential part of GOOSE based applications.
The hardware documentation should include all equipment related to GOOSE. In circuit
diagrams this means all IEDs, Ethernet switches and related wiring needed to establish
GOOSE communication. All relevant documentation concerning this equipment should
 51

also be included in the hardware documentation, in other words manuals and technical
information about the equipment. Hardware documentation does not require much
additional work compared to hardwired solutions. The role of parameter documentation
becomes essential when GOOSE based solutions are applied in an SAS. Primarily, all
information regarding GOOSE is stored in the SCD files of the SAS. Thus updated
backup SCD files are an essential part of the documentation.

4.8.2. Signal Lists

In order to provide readable documentation about GOOSE, specific signal lists with
functional descriptions should be provided. These lists should present the publishers and
subscribers of GOOSE messages with reference to parameter and configuration lists. An
example of such a list is given in Table 17.

Table 17. An example of GOOSE message signal list.

Publisher Signal Data attributes GOOSE Function Subscribers
description APPID block input
Name of General Complete The The function Names of
the description names of the unique block and the the
publisher of the data attributes in application name of the subscriber
IED being the data set ID of the input where IEDs
transferred GOOSE the message
message is connected
Example Example Example data Example Example Example
publisher signal attributes GOOSE function subscribers
description APPID block input
REF615_26 Arc light LD0. 0001 ARCSARC1. REF615_25
detection ARCSARC11. REM_FLT_DET

signal, FADet.stVal
sensor 1

Table 17 provides all the information regarding GOOSE communication that is

necessary for the person responsible for GOOSE configuration. When the configuration
is done, more detailed information can be found in the backup SCD files.

4.8.3. Logical Diagrams

The documentation should also provide description of the applications within the SAS.
With applications utilizing GOOSE this can be achieved, for instance, by logical
diagrams as pictured in Table 18. The functionality of the application is presented with
logical operators, presenting an overview of the logic and signals required for the
applications. As the GOOSE APPID is unique within the system, it links the logical
 52

diagram to the signal lists. A logical diagram presents the overall functionality of the
application more illustratively than mere signal lists.

Table 18. An example of GOOSE message logical diagram.

Documentation of horizontal communication is needed in the engineering,

configuration and testing phases of an SAS project. Further on, documentation is
assigned to the customer during commissioning. The presented examples of signal lists
and logical diagrams have all necessary information regarding GOOSE based solutions.
However, ABB Process Industry suggested that when GOOSE is implemented in
interlocking applications the relevant information regarding GOOSE should be
documented in interlocking diagrams. Similarly, when GOOSE is used in protection
applications, GOOSE documentation should be implemented in protection diagrams.
Thus the information regarding GOOSE would be documented where it is most likely
needed. However, this is a vendor specific solution, and therefore it is not presented in
this study.
 53

5. APPLICATION TEST

In the following chapters an example case of GOOSE based application is given. First
the general idea of the selected fault arc protection is described. The equipment used in
the test is presented, followed by a detailed description of the configuration process with
ABB’s products. Finally, the operation of the application is presented.

5.1. Application Tested

The fault arc protection was chosen as the application to be tested on the basis of an
upcoming customer project, which requires applying of GOOSE communication to fault
arc protection scheme. The purpose of the test is to describe how fault arc protection
with two IEDs can be realized with ABB’s products and software tools. The idea of the
application is similar to the example presented in Chapter 4.5.5, and is pictured in
Figure 26.

Figure 26. Tested fault arc protection application.

When the downstream Feeder IED detects an ongoing fault arc situation in the
busbar compartment it cannot isolate the fault. If the arc is detected in the breaker
 54

compartment, the breaker might be damaged and the isolation of the fault is not
possible. Therefore, the detection of arc fault in these two compartments is transferred
to upstream Incomer IED, which can isolate the faults by operating the related breaker.
The Incomer IED sends the trip signal based on the externally detected light signal and
locally sensed overcurrent. In this test the load is assumed to be capable of injecting
short-circuit current to the arc fault location. Therefore, both of the IEDs are designed to
send trip signals if arc fault is detected in busbar or breaker compartment.
In real cases there would be more loads and more feeder IEDs to protect them.
However, the configured signals for similar arc protection scheme would be the same,
therefore using only one feeder IED is justified.

5.2. Test Equipment

The application test was conducted with two ABB’s REF615 relays, equipped with
optional arc protection. The arc protection includes three light sensors, which are able to
detect ongoing arc situations. In order to establish GOOSE communication, an Ethernet
network was created. The test equipment with IP addresses is illustrated in Figure 27.
The network equipment included one managed Ethernet switch, three RJ-45 LAN
cables and a configuration computer. The required programs for configuring ABB
products were included in the laptop that ABB provided for the testing.

Figure 27. Test equipment for fault arc protection.

Programs include the PCM600, which is a configuration software designed for

substation automation. In the PCM600 the layout of the substation is defined by
creating required voltage levels and bays. Required IEDs are created in the PCM600
 55

project, and the correct parameters and settings for the IEDs are defined. Also, the
required connections of incoming and outgoing signals between the IEDs function
blocks are defined by using a specific Signal Matrix Tool (SMT).
Another program called Communication Configuration Tool (CCT) is needed for
defining horizontal communication. The required datasets and GOOSE control blocks
are created in the CCT, as well as the subscribers of the GOOSE messages.
In order to power up the IEDs and simulate current to incomer IED, a simulation
device SIM600 was introduced. The SIM600 supplied direct current for the IEDs. A
powerful flashlight was also required to simulate the arc flash of fault arc situation.

5.3. Configuration Description

In order to create a test network, the IP-addresses for the REF615 IEDs were manually
configured via local HMI. The IP-address and the sub-network mask of the
configuration computer were also changed in order to create a functional LAN. After
this the IEDs and computer were connected to the Ethernet switch by using a star
topology. The connections were verified by using the command interpreter (CMD) in
the configuration computer. It can be launched by choosing Start > Run and typing cmd
to the Run-window. The communication settings of the computer can be printed to the
CMD by typing ipconfig. The IP-address and sub-network mask of the computer were
printed as shown in Figure 28.

Figure 28. Screenshot from CMD.

The connections between the computer and the IEDs can be verified with ping-
command. For instance, by typing ping 172.16.4.25 the connection between the
computer and the incomer IED can be tested. Similarly, all connections within the same
 56

network can be tested when the IP-addresses are known. This testing is based on
Internet Control Message Protocol (ICMP) echo request tool, which uses TCP/IP. The
tool sends ICMP packages to the target IP-address, and monitors the replies to these
packages. If all four reply packages return from the target IP-address, the connection is
functional, as shown in Figure 28.

5.3.1. Configuration in the PCM600

The configuration of an SAS project begins by defining the layout of the substation in
the PCM600. The engineering starts by creating a new project in the PCM600. For this
test a project called Arc_Test_PCM was created. After this, required substations, voltage
levels, bays and IEDs can be created. A new substation can be added in the Project
Explorer – window by right clicking over the project name and choosing New >
General > Substation. The voltage levels are added similarly by right clicking over
Substation and choosing New > General > Voltage level. After this bays are added in
similar fashion under Voltage Level. Finally, the IEDs are added with a right click over
Bay and choosing New > Feeder IEDs > REF615.
For the purpose of this test a simple layout was created including one substation and
one voltage level. Two bays were created within the voltage level, each containing one
REF615 IED. When an IED is created in the PCM600, it can be configured online or
offline. In online configuration the PCM600 will retrieve the order code of the IED and
automatically generate functions for the IED. This is done with the help of a wizard
window, which only requires the IP-address of the IED. When the functions have been
generated, the IED is ready for application specific configuration. Similar procedure has
to be repeated in order to create another REF615 IED to the substation. The final plant
structure of the PCM600 project is depicted in Appendix 4.

5.3.2. Configuration in the CCT

The configuration of GOOSE communication for ABB’s IEDs is done in separate

software called CCT. The project created in PCM600 has to be exported and then
imported to CCT. The file being exported is an SCD file, it contains all information
regarding the substation description and IEDs. In CCT the imported SCD file shows the
data structure of the substation as a logical tree. The GOOSE configuration is done in
the IED section of CCT. There all IEDs described in the SCD file are presented by their
technical keys, which are unambiguous within the project. Technical keys used in the
test are pictured in Figure 27, REF615C_26 for the sending IED and REF615F_25 for
the receiving IED.
The GOOSE configuration is done first for the sending IED. By navigating to the
logical device LD0 and logical node LLNO, the actual GOOSE configuration can be
done in the IEC61850 Data Engineering window. The specific dataset is first created in
the Dataset Engineering tab by clicking New Dataset. In this test the dataset was named
Arc_DS. All required data attributes are then added to the created dataset by choosing
 57

them from the Data Model column and clicking Add. In this case, the data attributes are
the arc detection signals, which are listed in Table 19. The created dataset is presented
in Appendix 5.

Table 19. Configured data attributes.

Publisher Subscriber Signal description Data attributes
Feeder IED Incomer IED Fault arc detected
REF615C 26 REF615F 25 Light sensor 1 LD0.ARCSARC11.FADet.stVal
Light sensor 2 LD0.ARCSARC21.FADet.stVal
Light sensor 3 LD0.ARCSARC31.FADet.stVal

When the required data attributes are added, the dataset needs a GOOSE control
block. This is done in the Goose Control Engineering tab. By clicking GSE Control, a
new GOCB can be configured. First the GOCB was named Arc_GOCB and the correct
dataset selected. By clicking Address Definition CCT automatically creates all other
required information, which is confirmed in a pop-up window. The values used in this
test are pictured in Figure 29.

Figure 29. Values for GOCB.

The GOCB for this GOOSE message is now defined. The subscriber of the message
is added by dragging it from the Project Navigator window to the upper right corner of
the GOCB, which is depicted by the cursor arrow in Figure 29. If more than one
subscriber is required, they can be added similarly by using drag-and-drop. The
subscribers are show in Figure 29 under Client IED heading.
 58

Now all required information for the GOOSE message is defined. The created
information has to be updated to the SCD file. This is done by choosing Tools >
IEC61850 Data Flow Engineering > Update dataflow. After the update, the created
GOOSE message and the related data attributes are visible in the subscriber IED’s
logical node LLNO as inputs. The CCT project should be saved at this point.

5.3.3. Parameterization and Uploading

Before the application is operative, certain parameters have to be defined and the
configuration loaded to IEDs. This is done in the PCM600 program, thus the SCD file
must be exported from the CCT back to PCM600. This is done by choosing Tools >
SCL Import/Export > Export SCL File. The exported file is imported to the PCM600 by
right clicking over Substation and selecting Import. After importing the SCD file with
GOOSE configuration, it is available for further configuration.
The created GOOSE message has to be connected to desired functions in the
subscriber IED. This is done in SMT, which is opened by right clicking over the
subscriber IED and selecting Signal Matrix Tool. The SMT shows all binary inputs,
binary outputs and functions of the IED in spreadsheets. All connections between the
inputs, outputs and functions are made virtually in these spreadsheets. The created
GOOSE message is visible in the Binary Inputs tab. Each data attribute appears as one
binary input, and each of them can be connected to a desired function. In the arc
protection test, the fault detection signals from sensors 1 and 2 are designed to result in
a trip in the incomer IED. Therefore signals ARCSARC11.FADet.stVal and
ARCSARC21.FADet.stVal are virtually connected to the ARCSARC1 REM_FLT_DET
and ARCSARC2 REM_FLT_DET as pictured in Appendix 4. The remotely detected
light signals operate as inputs of the incomer IED’s arc protection function.
In order to easily notice whether a GOOSE signal is received in the subscribing
IED all three signals are configured to turn on a led in the front cover of REF615C_25.
Configuration is done in SMT by first connecting signals to a generic timer function
called TPGAPC4:4 via logical OR gate. The timer function is then connected to the led
number 11 on the binary outputs tab. Every time the configured GOOSE message is
received, the led number 11 will lit according to the default time set in the TPGAP4:4.
When the configuration in the SMT is done, the changes made are automatically saved
to the configuration file by closing the SMT.
The parameterization of the IEDs is also done in the PCM600. Parameterization
means the configuration of application specific values and settings, for example the start
level of overcurrent protection. Parameterization is done by browsing to the correct
function in the Project Explorer. The arc protection functions for the Feeder IED are
found with the following path, REF615C_26 > Application Configuration > Settings >
Other Protection > ARCSARC11 and ARCSARC21. The parameter settings can be
opened by a right click over the correct function. For this test example it was merely
checked that the operation mode for functions ARCSARC11 and ARCSARC21 was Light
+ Current and the start value was 2.5 times the nominal current. In this mode the arc
 59

protection function needs both light and overcurrent signals in order to send a trip signal
to circuit breaker. The light signal can either come from IED’s own sensors or as
remotely detected light, as in this example. When the Parameter Settings window is
closed, the changes are automatically saved to the configuration file.
Finally, the completed configuration needs to be written to IEDs. This is done
separately for each IED by right-clicking over them in the Project Explorer and
selecting Write to IED. When the new configuration is uploaded to IEDs, they will
automatically reboot in order for the new settings to come into operation. After
rebooting the IEDs are operative including the created GOOSE communication.

5.4. Test
In order to test the created application and GOOSE communication, an overcurrent
signal was simulated with SIM600 and the light sensors were simulated with flashlight.
The light sensors for arc detection are equipped with automatically compensated
reference level in order to prevent unfounded operation. The light sensors are covered
with black dust caps, thus each sensor could be tested separately. When overcurrent and
light flash in front of light sensor one were simulated, the outcome was tripping of both
IEDs, as designed. Similar results were achieved by simulating light sensor two. The
flashes were so fast that the configured led only flashed quickly, unless the light in front
of the sensors was left on. Because the fault detection signal of light sensor three was
not connected to trip function in the Incomer IED, the simulation of sensor three only lit
the led number 11 as configured. In the Feeder IED the simulation resulted in tripping,
as designed.
The performance of GOOSE communication was not subjected to study because
ABB has tested the performance of REF615 IEDs with KEMA. The conclusion of these
tests is that REF615 complies with performance class P1 for type 1A – Fast messages.
This means that the total transmission time of the GOOSE message is below 10
milliseconds, as defined in IEC 61850-5. [16; 30]

5.5. Problems in the Configuration

During the testing process several problems with configuration were encountered. Most
of them were human errors caused by lack of experience. However, the use of two
different programs for GOOSE configuration was found cumbersome by all members of
the project team. The team members found importing and exporting the SCD file
between programs confusing. Therefore, the integration of PCM600 and CCT would
rationalize the configuration process.
Some problems could be traced as actual software bugs, which were reported further
on. One of the bugs discovered in CCT was related to a parameter called Config.Ref,
which is included in every GOCB. The configuration reference is automatically
increased, if any changes are made to the GOOSE message. The Config.Ref has to be
 60

same in the sending and receiving IEDs, otherwise the GOOSE message will be
ignored. When the dataset was changed, and the configuration file written to both IEDs,
the Config.Ref parameter in the subscribing IEDs was not changed automatically. Thus
the subscribers did not accept the incoming GOOSE message, as the Config.Ref
parameters did not mach. This problem could be avoided by deleting the GOCB and
creating it again. However, it should be possible to make changes to an existing GOOSE
message. The problem was reported further on, and will be taken into account in the
next version of CCT.
Another problem related to configuration files was found in other IED’s. If the
configuration file was uploaded straight from the IED, it did not include the GOOSE
configuration. Therefore, if any changes to the configuration are required, they should
be done to the original file, and uploaded to IED. Otherwise the configured GOOSE
messages are lost.
The problems found indicate that the usability of the programs and IEDs requires
development. The bugs that were found will be fixed in the next versions of the
programs. However, all these problems can be avoided, if the configuration process is
familiar and the bugs known. Therefore, adequate training and practice is essential in
engineering of GOOSE based applications.
 61

6. CONCLUSIONS

The purpose of this study was to investigate possible applications of GOOSE

communication for ABB Process Industry’s electrification solutions. The customers
have not yet requested GOOSE based applications, but a few pilot projects including
GOOSE have been realized. As the IEC 61850 becomes more common in the field of
substation automation, it is highly likely that the standard will become a prominent
solution for process industry customers.
The selected applications were presented with example signals for ABB’s REF615
IEDs. Because the logical nodes are named according to IEC 61850, the presented
applications can be implemented similarly with other ABB IEDs equipped with required
functions. Applications can be implemented with other vendor products, although the
complete signals names might change.
Interviews with process industry specialists showed general interest concerning the
possibilities of GOOSE communication. The IEC 61850 is seen as the standard defining
communication in substations and beyond. The next editions of the standard will
include more specifications concerning reliability of the communication and extending
the scope of the standard to hydro and wind power generation. However, with GOOSE
based applications most experts are still waiting for more reference cases in order to be
convinced of its performance. It can therefore be suggested, that GOOSE
communication is first implemented to less time critical applications, such as
interlocking. With the experience gained from these pilot projects, the use of GOOSE
can be further extended. If the IEDs conform to IEC 61850, and the requirements of the
standard are taken into account in the network structure, GOOSE can be implemented to
more demanding and critical applications as well.
As mentioned above several problems were encountered during the configuration of
GOOSE based application. This indicates that the configuration programs need to be
developed in order to provide more user friendly programs in the future. Compared to
conventional hardwired schemes, GOOSE based applications require new type of
configuration work. Unfortunately, not a lot of experience has been gained in this area
so far. One of the advantages of GOOSE is the cost saved by using less labor intensive
hardwiring. Initially the use of GOOSE might be more expensive if the costs related to
training and learning are taken into account. In the long run the use of GOOSE is more
cost effective, as the configuration process becomes part of the engineering. Further
benefits can be achieved via expandability of GOOSE based applications. New IEDs
can be added or replaced without additional hardwiring. Instead the required signals can
be added to each IEDs configuration files. The challenges of GOOSE based solutions
 62

are related to redundancy, security and documentation of the applications. In order to

provide reliable communication the network structure has to be designed with proper
components, topology and required features. In the next edition of the IEC 61850 these
matters will be taken into account in detail. The documentation of GOOSE applications
requires new type of documents, as the signals between IEDs cannot be read from
circuit diagrams. The configuration files need to have backups that are up to date with
the system. GOOSE based applications require new type of training for service
personnel, as horizontal communication is verified with programs instead of
conventional metering. Adequate training of GOOSE is required also among engineers
and sales personnel, in order to avoid false beliefs and resistance for change.
As technology develops more IEDs with native IEC 61850-communication will
become available in the market. With additional functionality in the IEDs more
applications can be realized with GOOSE communication. The full potential of IEC
61850 becomes topical when first process level devices with native IEC 61850-
communication are introduced to the market. This means that process level devices can
transfer measurement values as SV messages via IEC 61850-network. This provides
interesting topics for further study, as the process level devices can communicate to
IEDs without hardwiring.
Based on the interviews with experts, the common opinion in the industry is that
IEC 61850 is the present and future standard for substation communication. This
becomes topical in the field of process industry electrification when the customers
become aware of the potential of IEC 61850. Therefore, it can be stated that IEC 61850
will play a significant role also in the future of process industry electrification.
 63

REFERENCES

[1] IEC 61850-2. 2003. Communication networks and power systems in substations –
Part 2: Glossary. IEC. 48 p.

[2] Jang H.-S., Jang B.-T., Kim Y.-W., Kim S.-S., Park B.-S., Song U.-S., Yang H.-S.
Communication Networks for Interoperability and Reliable Service in Substation
Automation System, 5th ACIS International Conference on Software Engineering
Research, Management & Applications (SERA 2007), Haeundae Grand Hotel,
Busan, South Korea, August 20-22, 2007. 6 p.

[3] Keskinen A. Sähköasemastandardin IEC 61850 soveltaminen toimitusprojektissa.

Diplomityö. Tampere 2008. Tampereen Teknillinen Yliopisto, Sähkötekniikan
osasto, sähkövoimatekniikan laitos. 53 p.

[4] Proudfoot, D. UCA and IEC 61850 for dummies. Siemens Power Transmission &
Distribution. 2002. 37 p.

[5] IEC 61850-7-1 2003. Communication networks and power systems in substations –
Part 7-1: Basic communication structure for substation and feeder equipment –
Principles and models. IEC 111 p.

[6] IEC 61850-1 2003. Communication networks and power systems in substations –
Part 1: Introduction and overview. IEC. 37 p.

[7] Vanninen T. Uuden sukupolven sähköasema-automaatioratkaisut. Diplomityö.

Tampere 2007. Tampereen Teknillinen Yliopisto, Sähkötekniikan osasto,
sähkövoimatekniikan laitos. 77 p.

[8] IEC 61850-8-1. 2003. Communication networks and power systems in substations –
Part 7-3: Specific communication service mapping (SCSM) – Mappings to MMS
(ISO/IEC 9506-1 and ISO/IEC 9506-2) and to ISO/IEC 8802-3. IEC. 133 p.

[9] IEC 61850-9-2. 2003. Communication networks and power systems in substations –
Part 9-3: Specific communication service mapping (SCSM) - Sampled values over
ISO/IEC 8802-3. IEC. 28 p.
 64

[10] Hoga C., Wong G., Communications according to IEC 61850 – Reliability at high
speed, CIRED International Conference and Exhibition on Electricity Distribution,
Turin, Italy, June 6-9, 2005. 4 p.

[11] Mackiewicz R. Benefits of IEC 61850. Praxis Profiline – IEC 61850. April 2007. 7
p.

[12] Lidén, J. Design and Implementation of an IEC 61850 gateway for PLC Systems.
Master Thesis. Stockholm, Sweden 2006. KHT Electrical Engineering. 45p.

[13] IEC 61850-7-4. 2003. Communication networks and power systems in substations –
Part 7-4: Basic communication structure for substation and feeder equipment –
Compatible logical node classes and data classes. IEC. 104 p.

[14] IEC 61850-7-3. 2003. Communication networks and power systems in substations –
Part 7-3: Basic communication structure for substation and feeder equipment –
Common data classes (CDC). IEC. 64 p.

[15] IEC 61850-7-2. 2003. Communication networks and power systems in substations –
Part 7-2: Basic communication structure for substation and feeder equipment –
Abstract communication service interface (ACSI). IEC. 171 p.

[16] IEC 61850-5. 2003. Communication networks and power systems in substations –
Part 5: Communication requirements for functions and device models. IEC. 131 p.

[17] Goraj M, Hermann J. Experience in IEC 61850. Praxis Profiline – IEC 61850. April
2007. 4 p.

[18] Dawidczak H, Dufaure T. SCL in practice. Praxis Profiline – IEC 61850. April
2007. 4 p.

[19] IEC 61850-6-1. 2003. Communication networks and power systems in substations –
Part 6-1: Configuration description language for communication in electrical
substations related to IEDs. IEC. 144 p.

[20] Puzzuoli, M.P., Moore, R. Ethernet in the substation. IEEE Power Engineering
Society General Meeting, June 18-22, 2006. 7p.

[21] Moore R. Substation LAN. Praxis Profiline – IEC 61850. April 2007. 4 p.

[22] IEC 62351-1. 2007. Power systems management and associated information
exchange – Data and communications security – Part 1: Communication network
and system security – Introduction to security issues. IEC. 35p.
 65

[23] IEC 62351-6. 2007. Power systems management and associated information
exchange – Data and communications security – Part 6: Security for IEC 61850.
IEC. 16p.

[24] Kainulainen K, Teollisuussähköverkon stabiilisuus saarekekäyttöön siirryttäessä.

Diplomityö. Lappeenranta 2001. Lappeenrannan teknillinen korkeakoulu.
Energiatekniikan osasto. 85 p.

[25] Hakala-Ranta A., Rintamäki O., Starck J. Utilizing possibilities of IEC 61850 and
GOOSE. CIRED International Conference on Electricity Distribution. June 8-11.
2009. 4p.

[26] IEC 61850-3. 2003. Communication networks and power systems in substations –
Part 3: General requirements. IEC. 33 p.

[27] IEC 60870-4. 1990. Telecontrol equipment and systems. Part 4: Performance
requirements. IEC. 59 p.

[28] IEC 61850-10. 2005. Communication networks and power systems in substations –
Part 10: Conformance testing. 43 p.

[29] IEC 61850-4. 2002. Communication networks and power systems in substations –
Part 4: System and project management. IEC. 59 p.

[30] Achterkamp M, Pokorny J, Schimmel R, Starck J. Comparison between hardwired

and GOOSE performance of Unigear switchgear panels with REF615 and REF630
Feeder Protection and Control IEDs based on IEC 62271-3. Arnhem 2010, KEMA
Inspection Report 09-1398. 37 p.
 66

Appendix 1: Parts of the IEC 61850

IEC 61850 - Communication networks and systems in substations
Part Title
IEC 61850-1 Introduction and overview
IEC 61850-2 Glossary
IEC 61850-3 General requirements
IEC 61850-4 System and project management
IEC 61850-5 Communication requirements for functions and device models
IEC 61850-6 Configuration description language for communication in electrical
substations related to IEDs
IEC 61850-7-1 Basic communication structure for substation and feeder equipment
– Principles and models
IEC 61850-7-2 Basic communication structure for substation and feeder equipment
– Abstract communication service interface (ACSI)
IEC 61850-7-3 Basic communication structure for substation and feeder equipment
– Common data classes (CDC)
IEC 61850-7-4 Basic communication structure for substation and feeder equipment
– Compatible logical node classes and data classes
IEC 61850-8-1 Specific communication service mapping (SCSM) – Mappings to
MMS (ISO/IEC 9506-1 and ISO/IEC 9506-2) and to ISO/IEC 8802-
3
IEC 61850-9-1 Specific communication service mapping (SCSM) – Sampled values
over serial unidirectional multi drop point to point link
IEC 61850-9-2 Specific communication service mapping (SCSM) – Sampled values
over ISO/IEC 8802-3
IEC 61850-10 Conformance testing
 67

Appendix 2: Guide for the Reader

User IEC IEC IEC IEC IEC IEC IEC IEC

61850- 61850- 61850- 61850- 61850- 61850- 61850- 61850-
1 5 7-1 7-4 7-3 7-2 8-x 9-x
Manager x - clause - - - - -
5
Utility

Engineer x x x x x in x -
extracts
Application x x x x x in x in
engineer extracts extracts
Communi- - x
cation x x x - - x
Vendor

engineer
Product x x x x in in in -
manager extracts extracts extracts
marketing x x clause in in in in -
5 extracts extracts extracts extracts
Application x x x x x - x -
Consultant

engineer
Communi- - - x x x
cation x - x
engineer
All others x x x - - - - -
The “x” means that this part of the IEC 61850 should be read.
The “in extracts” means that extracts of this part of the IEC 61850 series should be read to
understand the conceptual approach used.
The “-“ means that this part of the IEC 61850 may be read.
 68

Appendix 3: Table of Logical Nodes

!" #

$! $ %
& ' & ( (
'$
) *
&
$ $+
!
$ $ ) #
$
$" , $ " )
$ $ )
$, $ )
! # *
!&" - & # )
! #
!! . ! # /
, , # 0
, - $1 - ))
, " $ "
, " #
, , ,
, ,2 #
, , 23 ,
, 4$ 5 # 6
, ,
& & ) 70
&- $1 - ))
&- $ -
&- $ -
&- & -
&- 3 & - #
&1 ) )) 5
&" "
 69

&" $8 ##
&$ $
&, $ , 6
&, ,
& &1 )
&& , &
& " &
& -9 # )
& 91 )
&
& 1 ) 5
&
& & #
& #
& 3 3 #
& 3 3 #
&3 &1 3 # )
& 31 3 # ) 5
& #
& &" "/
&8 3 8 # # #
& #) :.
- 9 - 6 # )
- - 6 #
;- - 6 # 6
- - 6 # #
; 1 ; % )
-$ -
1! 1
& ; & # +6 %
9
< ( %
#
, ## )
$, $ #
$, ! $ # 5 #
&- , ## ) #
$ ) 7
)
)
2 7
2 ; 6 %
2 '$
< & )
 70

<91 9 ) / &
<!
<& " &
<& & )
8 1 5 :
8 2 = %
8; ;
8; " ;
8 ; & 6
8 & 6 %
8
8 9
8 $! #
8!$ & #
8, ,
8 9
8
8
8 1 #) 5
8 #
 71

Appendix 4: Screenshot from PCM600

 72

Appendix 5: Screenshot from CCT