aki suittio testing iec 61850 in multi-vendor …...mukaan. areva t&d oy:n micom-tuoteperheestä...

78
AKI SUITTIO TESTING IEC 61850 IN MULTI-VENDOR SUBSTATION AUTOMATION SYSTEM Master’s Thesis Examiner: Professor Pekka Verho Examiner and topic approved in the Department of Electrical Energy Engineering Council meeting on third of March 2010

Upload: others

Post on 27-Mar-2020

17 views

Category:

Documents


0 download

TRANSCRIPT

AKI SUITTIO TESTING IEC 61850 IN MULTI-VENDOR SUBSTATION AUTOMATION SYSTEM Master’s Thesis

Examiner: Professor Pekka Verho Examiner and topic approved in the Department of Electrical Energy Engineering Council meeting on third of March 2010

II

TIIVISTELMÄ TAMPEREEN TEKNILLINEN YLIOPISTO Sähkötekniikan koulutusohjelma SUITTIO, AKI: IEC 61850 sähköasema-automaatio järjestelmän testaus Diplomityö, 69 sivua, 9 liitesivua Toukokuu 2010 Pääaine: Sähkövoimatekniikka Tarkastaja: professori Pekka Verho Avainsanat: IEC 61850, sähköasema-automaatio, IED, GOOSE, yhteensopivuus Nopeasti kehittyvässä maailmassa myös sähköasema-automaation vaatimukset ovat

kasvussa. Sähköasema-automaation kehitykseen vaikuttavat merkittävästi kasvavat

sähkön laadun vaatimukset sekä sähköntuotannon rakenteiden muuttuminen kohti

hajautettua sähköntuotantoa. Sähköntuotannon muutoksia vauhdittavat ilmastonmuutos-

skenaariot, joiden vuoksi erityisesti tuulivoiman osuus sähköntuotannosta tulee rajusti

lisääntymään. Sähköyhtiöillä sähkön toimituksen keskeytyskustannukset kasvavat,

minkä takia sähköverkkoyhtiöt haluavat jatkossa vähentää keskeytyksistä syntyviä

menetyksiä ja parantaa sähkön laatua. Näiden asioiden solmupisteessä ja keskeisessä

roolissa on sähköasema-automaatio.

Uusi sähköaseman sisäisen tietoliikenteen standardi IEC 61850 mahdollistaa

uudenlaisen sähköasema-automaation kehittymisen. Aikaisemmin sähköasemien

sisäinen tietoliikenne on perustunut laitevalmistajien itse kehittämiin protokolliin. Tästä

syystä eri laitevalmistajien laitteiden keskinäinen kommunikaatio ei ole onnistunut

ilman protokollamuuntimia, joiden käyttö on ollut hankalaa. Käytännössä sähköaseman

kommunikoiva laitteisto on aikaisemmin toteutettu kokonaan yhden laitevalmistajan

laitteilla. Tämä on johtanut siihen, että markkinoita ovat hallinneet isot laitevalmistajat,

mikä on puolestaan vaikuttanut sähköasema-automaation tekniseen kehittymiseen. IEC

61850 on universaali standardi, joka on toteutettu eri standardisointilaitosten ja

laitevalmistajien yhteistyönä. Se on saanut osakseen kiinnostusta ja on jo vahvasti

mukana esimerkiksi ´Smart Grids´ -suunnitelmissa.

IEC 61850 -standardissa on monia asioita, jotka tekevät siitä aikaisempia

sähköasemakommunikaatiostandardeja edistyneemmän. Standardin objektimalli on yksi

standardin suurimmista eduista. Se antaa jokaiselle tietopisteelle yksilöllisen nimen.

Tietopisteiden nimet toimivat yksilöllisinä osoitteina, joista lukija tunnistaa heti tiedon

fyysisen lähteen ilman suurta määrää objektien ulkoa opettelua. Vanhemmat standardit

ovat käyttäneet hyväksi indeksinumeroita, jotka eivät kerro mitään tietopisteen

sisällöstä. Toinen standardin suurimmista eduista on horisontaalinen GOOSE-viestintä,

jonka avulla esimerkiksi sähköaseman suojareleet pystyvät kommunikoimaan suoraan

keskenään. GOOSE-kommunikaation avulla voidaan esimerkiksi parantaa

selektiivisyyttä ja lyhentää katkaisijan laukaisuaikoja.

Tämän diplomityön tavoitteena oli testata eri IEC 61850 -standardiin

perustuvien laitteiden yhteentoimivuutta, luoda samalla esimerkkikonfiguraatiot

III

valituille laitteille sekä antaa UTU Elec Oy:lle valmiuksia toimia IEC 61850 -standardin

mukaisten järjestelmien toimittajana. Diplomityön teettäjinä toimivat UTU Elec Oy

sekä Areva T&D Oy. Työn keskeisin osa koostuu Areva T&D Oy:n asematietokoneen

avulla toteutetusta demo-järjestelmästä, jossa asematietokoneeseen liitettiin IEC 61850

väylän kautta eri laitevalmistajien suojausreleitä ja yksi jänniteregulaattori. Lisäksi

työssä arvioitiin suppeasti IEC 61850 -standardin hyötyjä tuulivoimasovellutuksissa.

Demojärjestelmä suunniteltiin, ohjelmoitiin sekä rakennettiin pääasiallisesti UTU Elec

Oy:n toimitiloissa Ulvilassa. Areva T&D Oy:n toimitiloissa Frankfurtissa suoritettiin

Arevan asematietokoneen ohjelmointikoulutus sekä osa demo-järjestelmän

ohjelmoinnista. Muita järjestelmän laitteita varten ei hankittu erillistä koulutusta, koska

sitä ei havaittu tarpeelliseksi.

Tämä työ sisältää myös teoriaosuuden, joka käsittelee IEC 61850 -standardia.

Standardin sisältö on pyritty esittämään mahdollisimman selkeästi ja kattavasti, jotta sen

avulla voisi mahdollisimman hyvin sisäistää standardin teorian sekä taustalla olevat

periaatteet. Teorian ohessa käsitellään myös standardin etuja ja tulevaisuuden

mahdollisuuksia. Aluksi teoriaosuudessa käsitellään standardin taustalla olevia teorioita

yleisellä tasolla ja esitellään standardin historiaa. Lisäksi teoriassa käsitellään standardin

keskeisimpiä osa-alueita: objektimalli, MMS-kommunikaatio, GOOSE-kommunikaatio

ja fyysistä Ethernet-kommunikaatiota koskevat osa-alueet. Työ sisältää myös erillisen

osa-alueen, joka käsittelee suppeasti IEC 61850 ja IEC 61400-25 -standardeja

tuulivoimasovellutuksissa.

IEC 61850 -demojärjestelmän laitteet valittiin työn rahoittajien tarpeiden

mukaan. Areva T&D Oy:n MiCOM-tuoteperheestä valittiin C264-asematietokone sekä

P139-suojarele. Suojareleet valittiin sen mukaan, miten relevantteja ne ovat Suomen

markkinoilla, jotta UTU Elec Oy hyötyisi demo-järjestelmästä mahdollisimman paljon.

Jänniteregulaattori valikoitui järjestelmään sen mukaan, mitä Areva suositteli

käytettäväksi C264-asematietokoneen kanssa. Arevan C264-asematietokoneen kanssa

demo-järjestelmään liitettiin ABB Oy:n REF 615 - ja VAMP Oy:n VAMP52 -

suojareleet sekä A. Eberle GmbH & Co:n REG-DA jänniteregulaattori. Järjestelmän

kaikki laitteet laitettiin esille helposti liikuteltavaan puiseen laatikkoon. SCADA-

simulaattori ohjelmistoa ajettiin kannettavasta tietokoneesta, joka sijoitettiin puulaatikon

päälle.

Demojärjestelmän saattaminen alustavien suunnitelmien mukaiseksi tiedettiin

haasteelliseksi jo ennen konfiguroinnin aloittamista, koska lähteitä lukemalla saatiin

hyvä käsitys käytännön sovellutuksien yhteensopivuusongelmista. IEC 61850

yhteensopivuus on esisijaisesti riippuvainen asematietokoneen sekä releiden ja

jänniteregulaattorin välisestä kommunikaatiosta. Koska C264:n, P139:n ja REG-DA:n

välinen yhteensopivuus on Arevan testaama, mainittujen laitteiden kanssa ei

yhteensopivuusongelmia esiintynyt. Koska kaikkien laitteiden keskinäistä toimivuutta ei

ollut testattu, ongelmia oli odotettavissa. Kaikki laitteet saatiin kuitenkin liitettyä demo-

järjestelmään, mutta ihan kaikkia ongelmia ei saatu ratkaistua, koska konfigurointiin

käytettävä aika oli rajallinen.

IV

Suurin osa ongelmista aiheutui pääasiassa konfigurointiohjelmien välillä

vaihdettavista SCL-tiedostoista. SCL (Substation Configuration Language) on yleiseen

XML (Extensible Markup Language) -kieleen perustuva kieli, joka mahdollistaa eri

ohjelmistojen käytön sähköasema-automaatiojärjestelmän konfiguroinnissa. Standardi

määrittelee SCL-kieliset konfigurointitiedostot, jotka edustavat käytännön

konfigurointityön eri vaiheita. Demo-järjestelmän konfiguroinnissa ongelmia

aiheuttivat eri laitevalmistajien SCL-kieliset ICD (IED Capability Description) -

tiedostot, koska muita SCL-tiedostoja ei ollut juurikaan tarvetta käyttää. Ongelmat

johtuivat pienistä eroavaisuuksista ICD-tiedostoissa ja siitä, miten asematietokoneen

konfigurointiohjelma kulutti eri laitevalmistajien ICD-tiedostoja.

Demojärjestelmä saatiin toimimaan tiukassa aikataulussa, vaikka järjestelmässä

oli laitteita neljältä eri laitevalmistajalta. Niiden laitteiden kanssa, jotka olivat ennestään

Arevan testaamia, ei esiintynyt kommunikaatio-ongelmia. Kokemuksen karttuessa

järjestelmien saattaminen toimintakuntoon nopeutunee huomattavasti, koska demo-

järjestelmää konfiguroitaessa aikaa kului suhteellisen paljon ohjelmistojen toiminnan

sekä IEC 61850 -standardin periaatteiden opettelemiseen. Demolaitteistokin osoittaa,

että eri laitevalmistajien laitteiden välisessä yhteensopivuudessa on ongelmia, mutta

ongelmat ovat suhteellisen pieniä ja ovat useasti korjattavissa pienellä vaivalla.

Vaikka IEC 61850 -standardin edut ovat tiedossa, on standardin erilaisuus

verrattuna vanhempiin standardeihin osoittautunut ainakin pieneksi esteeksi standardin

yleistymiselle. Standardi ei ole aukoton ja siitä on haluttu mahdollisimman vähän

kehittymistä rajoittava. Koska standardi antaa laitevalmistajille tilaa käytännön

toteutuksille, tulee sovellutuksiin eroavaisuuksia, jotka aiheuttavat

yhteensopivuusongelmia. Standardi on vielä melko uusi siinä suhteessa, että

sähköasema-automaatiolaitteiston laskennallinen elinikä on melko pitkä ja laitteita

uusitaan suhteellisen harvoin. Koska sähköautomaatiojärjestelmät ovat suuria

hankintoja, kaikki eivät halua investoida tekniikkaan, joka on vielä kesken ja jonka

käyttäminen on vaikeaa. Kaikille aloille IEC 61850 -standardi ei välttämättä edes tuo

mitään, millä olisi lisäarvoa verrattuna vanhempiin järjestelmiin. Jotta IEC 61850

standardi lähtisi yleistymään siinä tahdissa kuin sen olettaisi yleistyvän, täytyisi

standardin mukaisten laitteiden yhteensopivuuden eteen tehdä vielä töitä. Joko

laitevalmistajien tulisi testata laitteidensa toimivuutta muiden laitevalmistajien laitteiden

kanssa enemmän ja vaihtaa testaustietoa keskenään, tai yhteensopivuusongelmista tulisi

julkaista standardi, jossa ratkaisuista sovittaisiin laitevalmistajien kesken.

V

ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Master’s Degree Programme in Information Technology SUITTIO, AKI: Testing IEC 61850 in multi-vendor substation automation system Master of Science Thesis, 69 pages, 9 Appendix pages May 2010 Major: Power Systems Examiner: Professor Pekka Verho Keywords: IEC 61850, Substation automation, multi-vendor, IED, GOOSE, interoperability In the quickly evolving world the requirements for substation automation is increasing.

The most significant factors in the progress of substation automation are the demands

for better quality electricity supply and the evolution of the electric generation towards

decentralized generation. The changes in electric generation are driven by the scenarios

of global warming. Because of the scenarios, especially the volume of wind power

plants is increasing drastically in the electric generation segment. The costs for

interruption in electricity supply is increasing and the electricity distribution companies

wants reduce interruption costs and offer better quality electricity. In the nodal point of

these matters is the substation automation.

The new standard IEC 61850 for communication in substation automation

enables a new kind of solutions in substation automation. Earlier the communication in

substations has been based on various manufacturers self developed protocols. For this

reason the communication between different manufacturers devices has not been

possible without protocol converters, which are difficult to use. In practise the working

installations have been actualised with devices from a single manufacturers selection.

The markets have dominated by large manufacturers that have a full selection of

substation automation devices. IEC 61850 is a universal standard, which has been

developed in co-operation with several standardisation organizations and manufacturers.

The standard has received lot of interest and already is strongly in future ‘Smart grid’

plans.

The objectives of this master’s thesis was to test the interoperability of

substation devices based on IEC 61850 and in the process create example configurations

from the selected devices for UTU Elec Oy. This work was funded by UTU Elec Oy

and Areva T&D Oy. A demo-system was built with Areva T&D Oy’s station computer,

with different manufacturers protective relays and one voltage regulator.

Communication between the devices was based on IEC 61850. This paper will also

include a narrow evaluation of the benefits of the IEC 61850 in wind power plant

solutions. The demo-system was built mainly in Ulvila at UTU Elec Oy’s office and

during couple weeks in Areva T&D Oy’s office at Frankfurt am Main.

VI

PREFACE

This master thesis presents results of testing substation automation system implemented

with IEC 61850. The automation components for the testing have been selected from

various vendors. The financiers for this thesis are UTU Elec Oy and Areva T&D Oy.

The goal of this work is to prepare UTU Elec Oy towards offering fully working

substation systems with IEC 61850. The multi-vendor demo-system was built mainly in

Ulvila at UTU Elec Oy’s office and at Areva T&D Oy’s office at Frankfurt am Main.

The main instructors for this work were Pasi Lauri from UTU Elec and Ari Pentikäinen

and Stefan Scharf from Areva T&D.

VII

Content

Tiivistelmä ........................................................................................................................ii

Abstract .............................................................................................................................v

Preface..............................................................................................................................vi

Glossary ...........................................................................................................................ix

1. Introduction ...............................................................................................................1

2. An overview of the new substation standard IEC 61850..........................................2

2.1. IEC 61850 purpose and benefits ....................................................................2

2.2. IEC 61850 background...................................................................................3

2.3. IEC 61850 content..........................................................................................4

2.4. IED modelling ................................................................................................5

2.5. Logical node concept......................................................................................9

2.6. IEC 61850 communication protocols...........................................................10

2.7. Physical communication...............................................................................11

2.8. ACSI (Abstract Communication Service Interface).....................................14

2.9. MMS (Manufacturing messaging specification) ..........................................15

2.10. GSSE, GOOSE and Sampled Values ...........................................................17

2.11. Substation bus topologies.............................................................................19

2.12. Time Synchronization ..................................................................................21

2.13. Communication performance requirements .................................................22

2.14. System configuration....................................................................................24

2.15. Retransmission scheme ................................................................................27

2.16. System reliability and redundancy ...............................................................29

2.17. Security.........................................................................................................30

3. IEC 61850 and wind power ....................................................................................32

3.1. Evaluation perspectives ................................................................................32

3.2. IEC 61400-25 and IEC 61850 ......................................................................32

3.3. The impact of the new standards ..................................................................34

4. IEC 61850 demo system .........................................................................................36

4.1. IEC 61850 system configuration..................................................................36

4.2. Objectives of the demo.................................................................................37

4.3. Demo equipment ..........................................................................................37

4.4. Additional demo equipment .........................................................................39

4.5. Demo system communication design...........................................................40

4.6. PACiS SCE...................................................................................................41

4.7. Bay level IED configuration tools................................................................45

4.8. MiCOM S1 Studio........................................................................................45

4.9. Vampset........................................................................................................46

4.10. WinConfig GOOSE light .............................................................................48

4.11. PCM600 and CCT600..................................................................................49

4.12. Other useful tools .........................................................................................51

VIII

5. Experiences from testing multi-vendor system.......................................................52

5.1. Configuration experiences............................................................................52

5.2. Static or dynamic ICD-file ...........................................................................53

5.3. The use of generic I/O’s ...............................................................................53

5.4. Goose mapping.............................................................................................54

5.5. The debug schema ........................................................................................55

6. Conclusion ..............................................................................................................56

References .......................................................................................................................57

Appendix A .....................................................................................................................61

Appendix B .....................................................................................................................66

IX

GLOSSARY

IEC International Electrotechnical Commission

IED Intelligent Electronic Device

SAS Substation Automation Systems

GOOSE Generic Object Oriented Substation Event

NCIT Non-Conventional Instrument Transformer

CT Current Transformer

VT Voltage Transformer

MU Merging Unit

SCL Substation Configuration Language

EPRI Electric Power Research Institute

IEEE The Institute of Electrical and Electronics Engineering

UCA Utility Communications Architecture

UCA 2.0 Utility Communications Architecture Version two

MMS Manufacturing Message Specification

ACSI Abstract Communication Service Interface

ISO International Organization for Standardization

IP-address Internet Protocol address

PICOM Piece of Information for COMmunication

TCP/IP Transmission Control Protocol / Internet Protocol

VMD Virtual Manufacturing Device

LAN Local Area Network

SCSM Specific Communication Service Mapping

GSE Generic Substation Event

GSSE Generic Substation State Event

CSMA/CD Carrier Sense Multiple Access with Collision Detection

RSTP Rapid Spanning Tree Protocol

GPS Global Positioning System

SNTP Simple Network Time Protocol

IRIG-B Inter-Range Instrumentation Group time code B

PTP Precision Time Control

PnP Plug and play

XML v.1.0 Extensible Markup Language version 1.0

ICD IED Capability Describtion

CID Configured IED Description

SCD Substation Configuration Description

SSD System Specification Description

VPN Virtual Private Network

IDS Intrusion Detection System

TCD Turbine Controller Device

CMD Condition Monitoring Device

1

1. INTRODUCTION

IEC 61850 is relatively new standard, but already it has been considered to

revolutionize the electricity distribution automation world wide. The new standard has

already been demonstrated successfully in several working substations. The IEC 61850

has been considered to replace, not only the substation communication standards, but

communication to the control room as well. Because the standard brings a lot new

practices and concept to the substation automation systems, vast a mount of testing must

be done before full substation automation system with IEC 61850 will become

common.

The IEC 61850 is an international standard, which has been developed with

major manufacturers. The standards main purpose is to bring new common

communication rules to the substation automation, which would replace older

communication standards. The communication rules are set by defining the station bus.

The station bus is defined by giving the data points comprehensive names, which

describe the data points. The standard defines data points in several levels and the most

important level is the logical node level. The standard also defines sets of services,

which operate on the data. More detailed description about the standard is included in

the theory section of this paper in chapter 2.

This thesis constructs from four different parts. The first part introduces the IEC

61850 standard, opens the concepts and introduces some problems and possibilities,

which have emerged during the reading of source material. Second part introduces IEC

61850 and IEC 61400-25 in wind power systems and the next two parts concern the IEC

61850 demo-system. The demo-system is a multi-vendor substation automation system,

which consists of thee protective relays, one voltage regulator and one bay computer.

The first section, concerning the demo-system, describes the demo-system, software and

introduces the software and configuration problems with the software. The second part

introduces the difficulties and problems, which emerged during the configuration work.

2. AN OVERVIEW OF THE NEW SUBSTATION STANDARD IEC 61850

2.1. IEC 61850 purpose and benefits

The development in electric distribution substation automation has not been particularly

fast since the systems have to be highly reliable and the old systems have offered just

that. Since the mixing of several communication standards is difficult, single universal

standard is needed. The substation standard IEC 61850 has already been proven to be

reliable and suitable for the purpose.

Since the emergence of the microprocessor relays, manufacturers have had their

own protocols for communication between IED’s (Intelligent Electronic Device).

Because of the different protocols in multi-manufacturer SAS (Substation Automation

Systems), costly protocol converters have to be used. This solution creates large

amounts of engineering work for system designing, testing and etc. All these reasons

have generated needs for a single universal protocol that satisfies both manufacturers

and the end users. Interoperability between different manufacturers IED’s is a major

factor in developing substation automation. With interoperability all vendors are apple

to provide manufacturer independent system with flexible extensibility and

functionality. The main purpose of the new standard is that products from different

vendors can easily be integrated to one substation infrastructure. This is done by

defining the station bus. [1]

Distribution companies are facing more and more pressure to provide better

quality electricity and one way to do that is to increase data flow and obtain larger

quantities of data from substations in real time. Real time data enables new kind of

calculations for substation monitoring, equipment maintenance, switching schemas and

power flow. IEC 61850 standard is mapped over the ‘state of art’ communication

technology, which enables fast and reliable data transfer. Advanced functionality and

data transfer methods are one step closer to future visions ´Smart Grids´.

IEC 61850 standard has been created to be functionally flexible and expandable.

The standard uses information technology, which support variety of services with

selection of performance requirements. Fast communication between individual IED’s

enables bay to bay communication. With bay to bay communication for example

interlocking can be executed trough communication lines. [1] With IEC 61850 IED’s

are able to communicate with each others, by publishing and subscribing GOOSE

messages. More detailed description about GOOSE messaging in chapter 2.10.

3

IED’s are microprocessor-based devices and microprocessors are becoming

more powerful. One substation has several IED’s and in order to substation automation

works as automated, IED’s have to be able to communicate with each other and in case

of anomalies IED’s should work intelligently together.

One advantage with the IEC 61850 is that it supports NCIT (Non-Conventional

Instrument Transformer) technology. NCIT technology has been developed more in few

years than in fifteen years before the IEC 61850. The NCIT technology has such

benefits compared to conventional CT’s (Current Transformer) and VT’s (Voltage

Transformer) as transient elimination, improved safety and accuracy and reduced

wiring. Some of the NCIT devices are fairly ready and with a MU (Merging Unit),

introduces in the IEC 61850, the implementation is not an issue. [2] The merging units

and sampled value transfer is introduced in chapter 2.7.

The IEC 61850 standard has been designed to cover and map all information

needed for automation in electric substations. All individual data points have a unique

name that simultaneously describes the data point in a way that it can be easily

understood. The standard strives towards more open systems by mapping the

communication and setting data points. The future vision is that all IED’s which fully

supports the IEC 61850 can be configured by third party configuration tool or that the

IED’s can even configure themselves when plugged into a working system.

The organization of all data in IED’s is in major role in IEC 61850. The earlier

protocols did not specify how the data should be organized. They only defined how the

data should be transmitted through the wire. The earlier solutions generate large

amounts of configuration work and in multi-protocol systems the time and effort put in

configuration is multiplied. IEC 61850 reduces configuration work by mapping data so

that all devices whit IEC 61850 should organize data at the same way. By mapping the

data consistently IED’s should be apple to configure themselves. Such interoperability

still lies in the future and mean while the interoperability is achieved by transferring

configuration files between IED configuration tools. More information about SCL and

IED configuration is in chapter 2.14.

2.2. IEC 61850 background

In the early 1990s EPRI (Electric Power Research Institute) and IEEE (The Institute of

Electrical and Electronics Engineering) started to develop a standard to define

substation communications. The project was named as UCA (Utility Communications

Architecture). The first version of UCA focused on communications between control

centres and substation to control centre. EPRI and IEEE started to work UCA 2.0 in

1994, which concentrated mainly on the substation’s communication bus. [3]

Few years later Technical Committee 57 of the IEC started a similar project to

define the station bus, which was named as IEC 61850. In 1997 all three EPRI, IEEE

and IEC united together to create one international standard, which was named IEC

61850, and was published in 2004. The IEC 61850 contains almost all specification

4

from the UCA 2.0 with additional features that offer variety of functionality. [3] The

new standard was created in cooperation with large number of specialists and with

major manufacturer to ensure that the new standard would satisfy its users.

2.3. IEC 61850 content

IEC 61850 has been divided to ten sections. Few large sections have been split into

smaller parts. The whole standard contains total fourteen parts, which are shown in table

1. [4] The first five parts contain general information about the standards concepts and

ideology. The remaining parts contain specific information about SCL (Substation

Configuration description Language) MMS (Manufacturing Message Specification)

services, data mapping, Abstract Communication Service Interface (ACSI), and testing.

Part one introduces the new standard by giving rough picture about the other

parts, concepts and benefits of the standard. Part two contains only glossary. Third part

gives basic requirement for substation automation for example references to

redundancy, automatic recovery, and data integrity requirements. Most of these

requirements are given as references to other IEEE, ISO, and IEC standards, since these

requirements already exist and there is no need to define them again. Part four contains

specifications and general information from development of individual IED to full

system engineering, about component life cycle determination, and about quality

assurance. Part five contains more specific information about the methods and concepts

behind the standard. It also defines requirements for performance and interoperability.

The sixth part is about SCL and configuration exchange between IED’s and engineering

tools. [1]

Section seven is the most important section and it consists of four parts, which

are called 61850-7-1, 61850-7-2, 61850-7-3, and 61850-7-4. Part 7-1 provides an

overview of the communication architecture and interaction between IED’s. This part

also describes relationships between other parts of whole IEC 61850 and defines how

interoperability can be obtained. Part 7-2 defines the ACSI (Abstract Communication

Service Interface) and its services. More detailed information about ACSI is in chapter

2.8. Part 7-3 continues to define the communication. This part specifies the abstract

common data classes and data attributes. The last and the fourth part define the data

classes and logical node classes. The definitions of common data classes, data attributes,

data classes, and logical node classes will be explained later in this document. [1]

The parts 8-1 and 9-1 map the concrete communication. The part 8-1 maps the

time-critical and non time-critical message services to the MMS (Manufacturing

Message Specification, ISO 9506) and to ISO/IEC 8802-3 frames. The 9-1 specifies the

mapping of the sampled value transfer and introduces the concept of merging unit. [6, 7]

The last section of the standard part ten specifies the testing for conformance. It

consists of the right techniques for testing IED’s performance and for testing the

implementations. [8]

5

Part 1 Introduction and overview

Part 2 Glossary

Part 3 General requirements

Part 4 System and project management

Part 5 Communication requirement for functions and devise models

Part 6 Substation automation system configuration description language

Part 7-1 Basic communication structure for substation and feeder

equipment – Principles and models

Part 7-2 Basic communication structure for substation and feeder

equipment – Abstract communication service interface (ACSI)

Part 7-3 Basic communication structure for substation and feeder

equipment – Common data classes

Part 7-4 Basic communication structure for substation and feeder

equipment – Compatible logical node classes and data classes

Part 8 Specific communication service mapping (SCSM) – Mapping to

MMS (ISO/IEC 9506 Part 1 and Part 2)

Part 9-1 Specific communication service mapping (SCSM) – Serial

unidirectional multidrop point to point link

Part 9-2 Specific communication service mapping (SCSM) – Mapping on a

IEEE 802.3 based process bus

Part 10 Conformance testing

Table 1: The fourteen parts of the IEC 61850 standard and headings [4]

2.4. IED modelling

Individual IED’s are connected to the network by one network address. One physical

device can be defined by one or many logical devices. Multiple logical devices are used

to separate functions in single physical device, which acts as a proxy server or as a

gateway for other logical devices in it. The device virtualization is done this way to

make configuration and whole system easier to comprehend. A modern protective relay

has functions for example for protecting, controlling and for communication. The

functions are easier to manage when they are hierarchically classified. This subject is

covered more detailed later in this chapter. [9]

6

Logical nodes are construct from data classes, each of which contains data

attributes. The standard defines concepts and some rules for physical devices and for

logical devices, but from logical nodes to data attributes the definition are stricter. [10]

There are 355 different data classes which can be divided into seven categories. These

categories are: system information, physical device information, measurands, metered

values, controllable data, status information, and settings. The figure 1 illustrates the

IED modelling levels. [3] The data classes are very generic and have to be used very

carefully. For this reason the data classes are still refined in 61850-7-2 to define the

Common data classes and in 61850-7-3 to define Compatible data classes. Common

data classes have sets of predefined attributes and compatible data classes have in

addition some predefined attribute values and semantics of the values. [10]

Figure 1: IED modelling data levels. The IED’s data model is build by combining

the building blocks. [10]

The data point reference constructs in the same way as the IED is modelled.

Figure 2 shows an example of data point reference. The reference maps the data to

understandable form, instead of an index number. The information can be understood

without additional decoding aid. By using the IEC 61850 mappings in setting software,

monitoring software and in all such systems, the naming systems are universal and

easily understood. When browsing manually the IED data, the individual parts of the

reference line hierarchically place the information in the device and the data is

Physical Device

Logical Device

Logical Node

92 different pre-

defined and

extensible

Data Classes

355 different

Data attribute

One physical device can contain one or

several logical devices

Logical nodes are the main building block

that define the device

Logical devices virtualizes the physical

device

Describes the structure and type of the

data

7

displayed in computers screen as a tree model. An example of the data organization tree

is shown in figure 3. [11]

This model also creates easy way to refer to individual objects. Each object is

named by its place and path in the information tree. The first part of the name of the

object, from right to left in figure 2, is the name of the device. The name of the device in

figure 2 is Relay1. The name of the device can be selected freely, which means that the

user can use those device names that he has become familiar with. The second part

signifies the logical node in which the object is. The first letter in the logical node part

signifies the group of the node. The logical node groups are shown in table 2. In this

case (figure 2) X signifies switchgear and the remaining letters (CBR1) circuit breaker

one. Logical nodes can be included with a reference number. This way the first circuit

breaker can be indentified with XCBR1 and the second one as XCBR2. Because the

basic communication is mapped over MMS-protocol, the separation mark is defined to

be ´$´. [11]

Figure 2: IEC 61850 object name structure [11]

Figure 3: A data organization example from Omicron IED Scout tool

Relay1/XCBR1$ST$Pos$stVal

Logical Device

Logical Node

Functional Constraint

Data

Attribute

8

Functional constrain is there to group individual attributes. It specifies which

services can be used to access the following data. Individual attributes have predefined

functions and therefore they are grouped be their functionality. In IEC 61850 software it

is common that the functional constrain is used also to organize the information. In

figure 2 the functional constraint (ST) stands for status attributes. There are functional

constraints for description attributes (DC), substituted value attributes (SV), measurands

(MX), extended definition attributes (EX) and several other, which are listed in the

61850-7-2 part. The data part gives understandable name to the data. Data elements are

named by their functionality in the systems. In figure 3 Pos determines the position of

the circuit breaker and the attribute stVal contains the value of the status. [10, 9]

Logical node Groups Group

Designator

System Logical Nodes L

Protection functions P

Protection related functions R

Supervisory control C

Generic references G

Interfacing and Archiving I

Automatic control A

Metering and Measurement M

Switchgear X

Instrument Transformer T

Power Transformer Y

Further power system equipment Z

Sensors S

Table 2: Logical node Groupings [10]

9

2.5. Logical node concept

Logical devices are defined by logical nodes. The logical nodes describe the functions

and functional interfaces. A function may be constructed from multiple logical nodes

and the logical nodes can be located in different physical devices. Then the function is

called distributed. The logical nodes are linked by logical connections, which are

independent of the physical connections with the use of Ethernet solutions. The standard

pre-defines 92 logical nodes, but the logical node group is extensible which means that

manufactures are not bound to already existing nodes. The standard defines rules for

creating new logical nodes and common data classes. The rules for creating new objects

have been defined to preserve interoperability. [9, 1]

The logical node concept is in major role in the whole standard. The logical

nodes are the basic objects that exchange information and the “backbone” in modelling

real devices. The logical nodes contain some mandatory predefined sets of data objects

with specific data attributes. All these concepts have a logical structures and strong

semantics related to real substation automation devices and tasks. The information

contained in logical nodes is exchanged by services with well-defined rules and

performance requirements. [10]

Free allocation of functions means that any function may take place in any

device that supports IEC 61850 standard. This is achieved with definition of LN

(Logical Nodes) and PICOM (Piece of Information for COMmunication). PICOM is

used for transferring information between two logical nodes. It describes the logical

connection between two logical nodes and it contains also the information to be

transmitted, attributes for message performance requirement and possibly other

requirements. PICOM can not be used in multicast or broadcast procedures, because it

uses addresses for point-to-point communication. [12]

The definition of the PICOM concept is illustrated in figure 4. The control and

report services are a part of the interface of a logical node, which are mostly used in

normal operation. Substitution service enables to replace a data value with fixed one.

Get and set service is for reading and writing data set values. Dir and definition is for

reading the data directory information. [10]

Figure 4: PICOM concept [10]

10

Functions are tasks that are performed by substation automation. Functions are

built from logical nodes, which change data with each other. IEC 61850 defines that

only logical nodes are used to exchange data, and all functions must have one or several

logical nodes. The GSE (Generic Substation event) and the sampled value service

communication do not use PICOM’s. GSE (GOOSE and GSSE) messages are sent to

many IED’s simultaneously in the internal network (peer-to-peer communication). GSE

messages are specially used for fast operation when substation event occurs and

therefore GSE message can not contain as much information as defined in PICOM

concept. [12, 10]

2.6. IEC 61850 communication protocols

The IEC 61850 uses a protocol stack based on MMS, TCP/IP and Sampled Value

transfer. Manufacturing Message Specification (MMS) is an international standard

(ISO9506) and it was chosen because it supports the standards complex naming system

and services. With MMS the mapping is easier to understand since the objects are

named by their functionality, not by index and register numbers. MMS is specially

chosen because of its Virtual Manufacturing Device (VMD) model. MMS also allows

IED’s to provide client and server functions at the same time. [13]

The specification in MMS defines the rules for communication, which are:

message sequencing over the network, message formatting and encoding and MMS

layer interaction between other layers of the OSI-model. Simply MMS defines

communication messages sent between IED’s with the VMD-model. The VMD-model

defines the objects that are contained in a server, the services that the client can use to

access and manipulate the objects and the behaviour of the server when a client sends

service requests. [13]

Open System Interconnection Reference Model (OSI-model) is an abstract

description of designing network protocols. Basically OSI-model divides the network

architecture into seven layers: Application (layer 7), Presentation (layer 6), Session

(layer 5), Transport (layer 4), Network (layer 3), Data-link (layer 2) and Physical layer

(layer 1). The first three layers are referred as application function and the last four as

connectivity function. [6] In the OSI-model the MMS belongs to the application

functions (layers 5-7). Sampled values and GOOSE messages have not been mapped

into MMS, but straight into Ethernet layer, because they are considered as time critical

messages and can not contain lots of binary data. The GOOSE and Sampled values will

be covered mo detailed in chapter 2.12. Layers three and four consists of TCP/IP

protocols and layers one and two consists of Ethernet protocol. [14] The IEC 61850

protocol stack is shown in figure 5.

11

Figure 5: IEC 61850 protocol stack [14]

2.7. Physical communication

All functions in substation automation can be divided into three levels: process, bay,

and station level functions. The figure 6 illustrates the typical physical allocation of

substation automation devices. The process level contains devices such as: circuit

breakers, current transformers, etc. These devices are generally hardwired to bay level

and the transferred data basically consists of binary and analogue input or output

information such as voltage and current transformer outputs and trip controls from the

protective relay. The interface between the process level and the bay level is indicated

in figure 6 with numbers four and five. At the process level may also be IED’s, such as

intelligent sensors and actuators. Process level IED’s are connected to process bus

usually based on LAN technology. The future visions are that the all process level

devices would be connected to the process bus, so that no hardwiring will be needed.

[12]

12

Figure 6: Communication and interfaces between the substation automation levels

[12]

The bay level consists of protection, monitoring, and control units such as

protective relays and voltage regulators. With the IEC 61850 GOOSE messaging the

bay level devices are able to communicate between different bays. The bay to bay

communication is called horizontal communication and is shown in figure 6 as interface

eight. Currently a modern microprocessor relay has multiple functions in one device.

Usually one modern relay performs all needed monitoring, protection and controls

concerning a single bay unit. The interface three illustrates the communication between

different function inside an individual IED. In a substation, until the process level IED’s

will become common, the bay level devices communicate trough hardwiring to process

level and with IEC 61850 to the station level. The IEC 61850 supports free allocation of

different function in substation, but yet it has not changed substation automation much.

The remote protection functions are outside the scope of the IEC 61850. [12]

The station level typically consists of the station computer, station workplace,

alarm unit and features, database and remote communication. Usually most of station

level function has been integrated in the station computer. In large substations the

station level functions are distributed to several station computers to achieve better

performance in the automation. There has been discussion also to use the IEC 61850 in

communication to the control room and between substations, but currently they are

outside the scope of the IEC 61850. [12]

13

There are three basic topologies for physical communication implementation:

bus topology, ring topology, and star topology. [12] Each topologies has its advantages

and disadvantages, but by modifying and mixing these topologies, it possible to find the

best solution for every substation type. [15] More about bus topologies in chapter 2.8.

The physical communication can be accomplished by different methods. The standard

does not require a specific physical interface. For example wireless solutions are

possible.

Nowadays station bus is used to transfer information between IED’s, but in the

future it can be seen that the process level IED’s are emerging and process bus will be

used more to transfer time-critical messages. Before primary substation equipment

become intelligent devices, the signal outputs can first be sent to a MU (Merging Unit).

The main task for a merging unit is to collect only voltage and current values. The MU

is an IED, which collects the analogue signals and provides them in digitalized and in

standard packet form for the protection and control IED’s through Ethernet based

communication lines. The standard part 61850-9-1 introduces the sampled value

transfer over unidirectional multidrop point to point link, which is mapped straight to

Ethernet layer in similar manner as GOOSE messages. The figure 7 illustrates the use

the MU. The IEC 61850 introduces that the MU should contain logical nodes TVTR

(Voltage Transformer) and TCTR (Current Transformer). By using the merging unit the

traditional copper wiring can be reduces significantly. The merging can installed closer

to the current and voltage transformers and the information from the MU can be

distributed to all other IED’s trough the station bus. [16]

Figure 7: Example for the use of merging unit [8]

14

2.8. ACSI (Abstract Communication Service Interface)

The IEC 61850 defines the ACSI, because the MMS, GOOSE or Sampled Values do

not themselves include naming conventions that support electric substation

communication. The ACSI can be also mapped to other protocols, thus the standard

needs only a partly update to map the ACSI over state-of-the-art technology.

The ASCI provides a virtual image of the substation. The virtual image is

generated with the use of the classification approach. The virtual system does not only

provide a virtual image, but it also provides real data real-time from the physical

devices. The whole system with all of its information can no be seen from every single

computer, but visibility of individual attributes can be modified. The diverse access

schemes can be used to provide or restrict the particular devices visibility. Basic

information about the IEC 61850 substation network security is discussed in chapter

2.17. [10]

The adoption of abstraction technique is one of the most significant features in

the IEC 61850 standard. The abstraction involves that objects are independent of

underlying protocols, which means that abstraction technique isolates the information

models and services from the on-the-wire protocol. Compared to earlier protocols used

in substation automation the abstraction has powerful benefits. The abstract definition

means that the description focuses on aspects on what the services are indented for

instead of describing how the services are build. [17]

The abstract definition in IEC 61850 services means that only aspects that are

visible and accessible over network are modelled. This is the reason for hierarchical

class model. The abstraction in ACSI has a second meaning, which is that the device

cooperation is only conceptual and the concrete solution are defined in the SCSM’s

(Specific Communication Service Mapping). Therefore the ACSI is independent of the

underlying communication system. This way the standard can easily be adapted to the

state-of-the-art communication technology in the future. [18]

The ACSI describes communication between server and client. It provides

interfaces for: real-time data access and retrieval, device control, event reporting and

logging, publisher/subscriber, self-description of devices, data typing and discovery of

data types, and for file transfer. The ACSI provides interfaces also for substation event

distribution (GOOSE and GSE) and for transmission of sampled values. [18]

The figure 8 shows a concept model for reporting and logging. The data, that is

wanted to reported, is grouped in to data sets. The data sets should be well chosen to fit

to specific needs. The reporting needs also triggering option (TrgOps), which define the

situation when the corresponding data set is reported or logged. The triggering option

dchg is set to true or enabled, each time a single data attribute changes it value, the full

data set is transmitted from the IED. The qchg option means that the data set is

transmitted when a quality of an attribute changes. The standard defines that the

messages can be sent as buffered or unbuffered. The buffer means that the message stay

in the memory until it is ensured that the message is received by the client. Usually the

15

buffered messaging is the preferred method, because it prevents message losses. Data

sets are used also to set up GOOSE messages, but since the GOOSE message itself and

GOOSE services are limited, the subscriber has to be configured to receive the

messages. [10]

Figure 8: Reporting and logging concept schema [10]

2.9. MMS (Manufacturing messaging specification)

Currently the IEC 61850 abstract services (ACSI) defined in 61850-7-2, 61850-7-3 and

61850-7-4 are mapped over MMS, apart from GOOSE and sampled value transfer. The

part 61850-8-1 defines how the ACSI services, concepts and objects are mapped to

MMS services. An instance of ACSI server class is mapped to MMS virtual

manufacturing device (VMD) object, which is the part that enables the monitoring and

control services. The table 3 show services which has been mapped to represent IEC

61850 ACSI objects. [6]

16

MMS Object IEC 61850

Object

MMS Service in use

Application Process

VMD

Server Initiate, Conclude, Abort, Reject, Cancel,

Identify

Named Variable

Objects

Logical Nodes

and Data

Read, Write, InformationReport,

GetVariableAccessAttribute

Named Variable List

Objects

Data Sets GetNamedVariableListAttributes,

GetNameList, DefineNamedVariableList,

DeleteNamedVariableList, Read, Write,

InformationReport

Journal Objects Logs ReadJournal, InitializeJournal,

GetNameList

Domain Objects Logical Devices GetNameList, GetDomainAttributes,

StoreDomainContents

Files Files FileOpen, FileRead, ObtainFile,

FileClose, FileDirectory, FileDelete

Table 3: The MMS service mapping within the SCSM of IEC 61850-8-1 [6]

The MMS uses the seven layer OSI-model, which has been introduces already in

chapter 2.6. The MMS takes the layers 7-5 and the TCP/IP layers 4 and 3, which is

shown in figure 9. The communication is based on client/server relations and devices

are identified by the devices IP addresses. As discussed earlier the physical device acts

as a proxy server to all logical devices in the same IED and with use of Ethernet the

devices can physically locate anywhere in the network. [6]

The logical devices are mapped to MMS Domain objects and for each logical

device there shall be one MMS domain. The logical nodes are mapped to MMS

NamedVariable objects and other ACSI objects are mapped similarly. This way the

MMS object-oriented modelling support the ACSI and naming conventions based on

substation automation. The MMS is fairly complicated protocol, so detailed description

of the MMS is outside the scope of this paper. [7, 19]

17

Figure 9: IEC 61850 service message types. [6]

2.10. GSSE, GOOSE and Sampled Values

There are two different GSE (Generic Substation Event) communication systems in IEC

61850. GSSE (Generic Substation Event) is an extended version from the earlier UCA.2

version for transmitting substation events. GOOSE is newer and more flexible system

for transmitting data-sets and therefore the GOOSE has become more used in new

applications. The difference between GOOSE and GSSE is that GOOSE supports

analog, binary and integer value data types and GSSE supports only fixed binary event

status type. Both GOOSE and GSSE use multicast services to send substation event

messages. [20] The most important aspect about that GOOSE is can be used for

horizontal communication between bay level IED’s. The GOOSE is feature is a major

benefit compared to earlier substation automation standards, because the GOOSE is

ideal for fast messages transmitted trough the network. With the GOOSE for example

the interlocking, auto-reclosing, inter-tripping, and trip signals are faster to implement.

[22]

GOOSE is mapped straight to Ethernet layer to provide fast real-time operation

and it is used to implement traditional protection schemas such as interlocking, tripping

circuit breakers and status indications. All these services are high priority services for

example a circuit breaker trip command must be delivered within 4 milliseconds and

with GOOSE it is possible to deliver such messages even faster. The GOOSE is a

18

flexible tool, because it can serve different applications that have different types of

performance requirements and it can use various data types. [20]

SV (Sampled Value) messages are used to transfer digitalized measured values.

The measured values are sampled from a continual stream of analogue metering with a

predefined rate. This task can be done for example by an intelligent instrument or by a

merging unit. The frequency of the sampling rate can be freely selected to be suitable

for the individual target. For protection purposes sometimes the sampling rate and value

limits has set so that nuisance alerts can be reduced. As seen in figure 5 the

transmission of SV has also been mapped directly to the Ethernet layer.

GSE and SV messages are both mapped directly to the Ethernet layer, because

they are designed to provide fast communication. This solution ensures that the

transferred communication packets have minimum amount of information. Both

messaging systems have also strict performance requirement, which is explained in

chapter 2.13.

For a substation automation engineer working with IEC 61850 it is important to

understand the mechanisms in GOOSE service, because it is one main feature of IEC

61850 compatible relays. When a substation event occurs and one or several data-

attributes change their state, the publisher transmission buffer is updated. The local

service “publish.reg” transmits the changes values to the publisher transmission buffer

combined with a GOOSE message. Next the specific mapping services will update the

subscriber buffer automatically. The subscriber receives the new values and may

forward the message appropriately. The mechanism of the GOOSE service is shown in

figure 10 below. [21]

GOOSE service has to follow a retransmission scheme, which ensures that

messages are received when using multicast transmission. Because the GOOSE is

mapped directly to the Ethernet layer, it does not have built in services to insure

message delivery, such as in TCP/IP communication. Retransmission scheme is

explained in chapter 2.15. [21]

19

Figure 10: GOOSE service mechanism [18]

2.11. Substation bus topologies

The solution for substation bus is widely researched topic. Since Ethernet provides

flexible base for the bus, and the IEC 61850 series does not require a specific type of

solution, the different solution has to be tested and discussed for redundancy,

performance, disturbance and network security. Different topologies have different

advantages and disadvantages. Some topologies are better for performance and some for

redundancy. Often the availability and reliability requirement demand for a ring type of

bus topology, but in some cases the star type is acceptable. For example in small and

non important destination, where no real redundancy is required and multiple Ethernet

switches would cost too much, start topology is justified. [21]

A simple bus topology is a solution, where the IED are directly connected to the

bus without Ethernet switches or repeaters. When operation without switches, some

kind of collision detection must be used, and it can be achieved with IEEE 802.3 based

CSMA/CD (Carrier Sense Multiple Access with Collision Detection). Since bus

topology does not support priority tagging, the network overloads easily in larger

substations when a substation event occurs. This type solution often does not provide

enough redundancy, availability or reliability. To meet the standard requirements,

almost in all cases, Ethernet switches with priority tagging are required. [20]

The ring topology consists of switches or repeaters that link together to join

IED’s, station PC, server etc. Benefit of the ring topology is its reliability, because fault

isolation and recovery are easy to implement. If one communication wire is faulty the

communication still works, but the topology changes to star topology and second fault

20

in the communication is fatal. Ring topology support long communication wires, since

the messages are repeated at every switch or repeater. Usually IED’s that support ring

topology are equipped with repeaters. Without priority tagging and Ethernet switches

the transmission of important messages may be delayed, because the switches route all

communication to the same wires that connects the ring. A simple example of ring type

communication architecture is shown in figure 11. [20]

In star topology the station computer, server etc. are connected to Ethernet

switch, which connect to switches below, towards the process bus. Since IED’s are

connected via one or more switches to the station computer, and if one switch in the

path to the station computer fails, messages can not be delivered. With star topology the

network does often meet performance requirements, but compared to ring topologies it

has poor reliability. [20]

Figure 11: Simple examples of star (left) ring (right) type communication

architectures [22]

Usually mixed approaches are used in substation projects to meet the standards

requirement, to lower communication system costs etc. In cascaded star topology a set

of IED’s are connected to one switch and several switches are connected together to

form a cascade structure. The station computer etc. devices are connected to one of the

cascaded switch. The amount of parallel switches is limited by delay in every switch

and this type topology does not provide good reliability if one switch fails. Reliability

can be achieved by connecting the cascaded switches by the end switches in a loop via

one extra switch connected to the station level devices. This type of solution is called a

star-ring topology. By creating a ring structure, it is possible that the messages would

circulate in the loop forever, since normal Ethernet switches do not support loop

structures. Therefore managed switches should be used. Managed switch uses an RSTP

21

(Rapid Spanning Tree Protocol) which is defined in standard IEEE 802.1w. Compared

to other topologies the star-ring topology is more expensive and complex, but it often

offers the needed performance and reliability. [15, 20]

2.12. Time Synchronization

Because the substation events have strict performance requirements the time

synchronization has important role in IEC 61850. For the purpose of organisation of

substation events, the time tags of the events must be coherent. With the IEC 61850 a

vast amount of information is available in a fast rate and in order to organize for

example events from several IED’s in a database, the time source must be able to

provide coherent time to all the IED’s. When a substation event occurs the event

information has to be organized in the storages in the same order as they are published.

This way the right sequence of event can be restored and right decisions and calculation

can be made. [23]

The standard defines five different classes for time synchronization. First two T1

and T2 is defined for normal event tagging, which are shown in table 4, and rest T3, T4,

and T5 are for instrument transformers, which are shown in table 5. The P1, P2, P3 in

table 5 means that the raw data is used for protection and control purposes and M1, M2

and M3 are for metering purposes. The sampling rates for metering are high due to

monitoring for harmonics. [12]

Time performance

class

Accuracy

(ms)

Purpose

T1 ±1 Event time tagging

T2 ±0,1 Time tags to support point on wave

switching

Table 4: Time synchronization accuracy requirements for control and protection

events [12]

Time performance class Accuracy (µs) Reference rate (Samples/s)

T3 ±25 P1 480

P2 960 T4 ±4

M1 1500

P3 1920

M2 4000

T5 ±1

M3 12000

Table 5: Time synchronization accuracy requirements for instrument

transformers [12]

22

The IEC 61850 states that the time synchronization method using LAN should

be SNTP and other method are outside the scope of the standard. The common methods

to synchronize distributed clocks in LAN’s are NTP (Network Time Protocol) and

SNTP (Simple Network Time Protocol), which can achieve accuracies in the range of

millisecond. Radio signals and GPS (Global Position System) can be used also to

implement time synchronization. It is theoretically possible to achieve high precision

synchronization with the GPS, but such system would be very expensive compared to

LAN solutions. [23]

The problem with conventional solution with SNTP is that it is only able to

provide accuracy about 1 millisecond, which is not enough for raw data sample values

and for merging units. One solution is to use IRIG-B. The IRIG-B means the standard

Inter-Range Instrumentation Group time code B. The IRIG-B is not a time source itself,

but it need an external time source for example a GSP clock, and thus it needs extra

wiring. Since the automation does not work properly without time synchronization, the

system has to be redundant. In the case of IRIG-B the external time sources have to be

doubled or an alternative time source could be a SNTP master. [24, 15]

The PTP (Precision Time Control) described in IEEE 1588 standard has been

developed to meet these requirements. With PTP it is possible achieve less than one

microsecond accuracy with the distributed clocks through Ethernet. The PTP has been

developed with aims for accuracy in the microsecond range, minimum requirements for

system performance, low administration efforts, use via Ethernet with multicast

capability and specification as an international standard. PTP is becoming popular

solution not only in substation automation, but in all automation which needs time

synchronization. [23]

2.13. Communication performance requirements

Different message types have different performance requirements. The performance

requirements are defined as requirements for allowed message transfer time. The

transfer requirements are supported by time tags and time synchronization. The

performance requirements are independent of the substation size, because the

requirements are defined per message. [11] The IEC 61850 has specified few types of

performance requirements shown in table 6. Figure 5 shows the types which message

types and performance requirements each application uses. [20]

The 1A type message has the most strict requirements and it is used for trip

indication, interlocking and for protection logic. The 1B type is for messages which

have less strict performance requirements. The type 2 is time-tagged, but the message

content has less performance requirements than the type 1 messages. The type 2

message may alternatively include one measurement value. The type 3 is used for

complex messages which may be equipped with a time-tag. The type 3 requirement is

used for example in messages such as normal event handling messages or in non-

electrical related Measurands. The type 4 is intended to be used for raw data transfer

23

from digital instrument transformers and transducers. Type 5 is used for file transfer and

type 6 is defined for synchronization purposes. Because the time synchronization used

for variety of services and applications, different classes are required. The time

synchronization is discussed in more detail in chapter 2.12. [12]

Type Application Performance

Class

Requirements

(Transmission

Time)

P1 10 ms 1A

Fast Messages

(Trip) P2/P3 3 ms

P1 100 ms 1B

Fast Messages

(Other) P2/P3 20 ms

2 Medium Speed 100 ms

3 Low Speed 500 ms

P1 10 ms 4 Raw Data

P2/P3 3 ms

5 File Transfer ≥1000 ms

6 Time

Synchronization (Accuracy)

Table 6: Message type performance requirements [20]

IEC 61850 defines three different event types that need dedicated time

allocation. In first scenario time tag is needed when an event is created by IED’s

internal calculation. In second scenario a change of a binary input creates an event that

needs time tagging. And in third scenario an event is created by a change in an analogue

input. In the second and third scenario the delays must be considered and the times shall

be locally corrected. The time correction should be accurate as possible and the

correction should be added to the message before transferring, not at the receiving end.

The whole transfer time consists of the communication processing times at both ends

and the time that it takes to transfer the message from source to sink. The time between

IED’s includes the time on the wire and times consumed in routers and other devices.

Because the performance requirements are independent of the systems physical network

implementation, the individual systems performances must always be tested, before it

can be stated that the system meets the requirements. [12]

24

2.14. System configuration

The IEC 61850 defines the ‘language’ on the communication wire in substation

automation. Because the IED’s are attached to automation system, the devices have to

have some information how to communicate with other devices in the substation. Some

configuration must be done before the devices work together as designed. It is possible

that the devices would, after connected to the system, retrieve the system configuration

information automatically. The standard services already support this, but since the

standard is relatively new, such interpretability is difficult to implement. Because the

IED’s interoperation is far from supporting PnP (Plug and play), it is important to

understand the SCL-language and configuration schemas.

The SCL (Substation Configuration description Language), based on XML

version 1.0 (Extensible Markup Language), is used to describe IED configurations. Its

purpose is to work as a tool for exchanging data concerning IED and SAS descriptions

between IED configuration tools, and a system configuration tools. The standard

introduces three distinctive steps in designing the SAS, which are: specification SAS

functionality, description of IED’s capabilities, and description of SAS. In the first step

the system is specified allocating the logical nodes to needed functions and equipment.

The second part involves mainly pre-configuring the individual IED’s, fixing the logical

nodes. In the third step the pre-configured IED’s are bound to the processes and the

communications is set. Communication configuration between IED’s concerns

describing subnetworks, communication access points and connections between logical

nodes. [25]

Between logical nodes are the logical links, which are created by the means of

subnetworks. Subnetworks are joined together by access point, which are physical ports

or logical addresses of an IED. Logical node that acts as a client uses the address

information of an access point to connect to logical node that acts as a server. In the

same subnetwork all access points can communicate with each other using the same

protocol. In some cases the SCSM (Specific Communication Service Mapping) may

create some variation to this and allow mixing of higher-level protocols. [25]

One logical device may have only one access point, but one access point may be

used by several logical devices. A client logical node may use several access points to

connect to different subnetworks, but usually a switch controller logical node acts as a

client to retrieve the data and provide it as a server. Routers allow a client to access a

server in another subnetwork, but those services that do not use the networking layer, do

not have access to other subnetworks. The GSE, sampled values, and time

synchronisation messages do not use the networking layer, but they posses a specific

addresses. Therefore they are not allowed to access other subnetworks through routers.

[25]

The configuration involves exchange of four different SCL files. All four files

use different extensions to avoid mixing of the files. The files are usually referred by

25

their extensions, which are: ICD (IED Capability Description), SSD (System

Specification Description), SCD (Substation Configuration Description), and CID

(Configured IED Description). The SCL-file extensions are described in table 7. Each

file must also contain a version and revision number. Since the configuration usually is

done with configuration tool from different manufacturers, the SCL files must strictly

follow the SCL rules defined in IEC 61850-6 to ensure interoperability. [25]

.SSD

Describes the single line diagram of the

designed substation and the logical nodes

which are required

System specification tool →

System configuration tool

.ICD Describes the capabilities of an IED IED configuration tool →

System configuration tool

.SCD Contain the communication information of the

substation, all IED’s and describes substation

System configuration tool →

IED configuration tools

.CID Contains the individual IED’s communication

configurations. Describes the initiated IED

IED configuration tool →

IED

Table 7: SCL-file extension descriptions [25]

The ICD file is used to describe the capabilities of individual IED. It contains

section for the IED description, needed data type templates, logical node type

definitions, and it may also contain optional substation section and section for default

addresses. The optional substation section predefines the binding of logical nodes in

distributed function. The ICD file is used to transfer data from IED configuration tool to

the system configuration tool. [25]

The SSD file is used to describe the system in basic single line diagram. It

contains single line diagram of the logical nodes, needed data type templates, and

logical node type definitions. The SSD file is used to transfer data from system

specification tool to system configuration tool. [25]

The SCD file is used to configure the data exchange. This is done by bounding

the IED’s to individual process functions, to primary equipment, and to the access

points. The SCD file contains every IED in the system, section for communication

configuration, and a description of the substation. The file is used to transfer data from

system configuration tool to IED configuration tool. [25]

The CID file is used to describe and instantiate an IED to the system. It contains

the address of the IED and the specified names used in the system. The CID file is

transferred from IED configuration tool to the IED, and it is basically stripped down

26

version of the SCD file. The SCD file contains all information concerning system

configuration and a CID contain only data concerning the IED. [25]

The standard defines that IED, which has been configured to work also as a

server, must be able to produce ICD file or accompanied with one. It must also be able

to consume an SCD file. It is not mandatory that IED’s can perform these tasks

independently, but the tasks can as well be performed with the help of engineering tools.

The SCL allows manufacturers to create small private parts, for the devices and tools

internal use, into the SCL files, which can only be interpret or possibly modified with

the manufacturers tool. All other tools can only regard them, but private part should not

be deleted, but kept along for future use. The private parts should not be used to

describe information which is required for full interoperation. [25]

The figure 12 illustrates the exchange of SCL-files between the different

configuration tools. At first the ICD-files are retrieved from the IED configuration tool

or directly from the IED’s. The system is first designed with the system specification

tool and the SSD-file and the ICD-files are transferred to the system configuration tool.

The ICD-files and the SCD-file is used to with the station computer configuration and

finally the configured CID-files are used to configure the IED’s. Different

manufacturers have slightly different approaches to the configuration tool. Four

different configuration tools for substation automation configuration could be

considered to be too many and a common solution is to integrate some of the tools. For

example the system specification tool, system configuration tool and station controller

configuration tool are sometimes integrated to one tool. The configuration of an

substation automation system starts from defining the substation in a single line diagram

and ends to the individual IED configuration.

27

Figure 12: An example substation configuration schema with SCL files [26]

2.15. Retransmission scheme

Because GOOSE is mapped straight to the Ethernet layer and it does not use the

addressing layer, it does not use device addresses but a network address and therefore

messages are sent as a multicast. In multicast communication model a protective relay

detects a fault and sends a GOOSE message as a multicast to the network. Other relays

inside the network receive the GOOSE and duplicate it to the same network. This

creates architectural challenges when transferring messages between substations. This

means that the system must be able to handle message loss, duplicated messages,

delayed messages and loss of connection. [20] The retransmission schema, shown in

figure 13, ensures that message is received by the subscriber. GOOSE messages are sent

constantly to the network. If an substation event occurs and the status of a data point

changes, the GOOSE messages are sent more rapidly.

28

T0 Retransmission in stable conditions

(T0) Retransmission in stable conditions may be shortened by an event

T1 Shortest retransmission time after the event

T2, T3 Retransmission times until achieving the stable condition time

Figure 13: Basic schema of the GOOSE retransmission concept [6]

To ensure dependable protection IEC 61850-8-1 part specifies a scheme for

retransmission. The retransmission scheme is also a good way to check that the

communication lines are healthy. The check is performed when a substation event

occurs and GOOSE is sent by an IED. In configuration each GOOSE is given max time

value (mt), which is illustrated as T0 in figure 13, and the name of the data set, which is

to be sent. Max time means the time between retransmission. After the first GOOSE has

been sent, a new message is sent when the max time expires or an element in data set

changes. If an element in data set has been changed the time of transmission (tot), which

is illustrated as T1 in figure 13, is very short. At first the new data set is sent frequently

(new message after every 4 milliseconds) and after a few first retransmissions the time

of transmission (tot) increases gradually until it reaches the configured max time value

(mt). [20]

Every GOOSE message is also included with time to live value (ttl), which is

calculated by the message publisher. The time to live (ttl) value is a multiplied value of

the time of transmission (tot). It is multiplied by two when time of transmission (tot)

equal the max time and multiplied by three when time of transmission is something else.

The time to live value (ttl) is multiplied, in for to avoid unnecessary alarms caused by

small delays. Because the time to live predicts when the next message will be sent,

every message subscriber can be used to monitor the health of the communication lines.

The subscribers calculate time to wait (ttw), which is calculated based on the time to

live (ttl). If the time to wait expires, the subscriber thinks that the communication line

must be out of order and changes its logic as has been configured. [20]

29

2.16. System reliability and redundancy

When talking about substation automation, redundancy is an obvious concern. It is vital

for substation automation that the systems are endlessly reliable. Since microprocessor

technology added with state-of-the-art communication technology creates complexity to

the hardware and software, the redundancy should be ensured in every level and in

multiple ways. Large high voltage substations have commonly two parallel protection

systems and other solution that create redundancy and reliability. In lower voltage

where parallel systems are not used, the IEC 61850 offers other means towards more

reliable systems. This is done by modelling redundancy in different levels of the system:

IED internal, communication system level, and application level. Usually redundancy

has been mainly issue of the amount of components and parallel systems in the

substation.

Internal IED redundancy depends only from the manufacturers and it is outside

the scope of the standard. Basic solution to improve redundancy in communication level

is to select a switch based ring structure for the station bus. This solution offers

reliability if one switch fails. In application level the IEC 61850 has a lot to offer, since

redundancy can modelled straight to the functions. Application level redundancy is

modelled in SCL, by naming each IED individually, providing additional subnetworks,

and linking logical nodes. [25]

IEC 61850 series defines that a substation shall be able to operate even if one

component in the substation automation system fails. This requirement is referred as

‘graceful degradation’ in the standard. Redundancy is only one way to add reliability,

but should also be added with great care. [27] With IEC 61850 the reliability of the

system often depends on the reliability of the network solutions. This generates a lot of

requirements for the Ethernet switches and for the used network structure.

Modern Ethernet switches are IED’s themselves, which can be configured. An

Ethernet switch has multiple ports that connect individual IED’s and forms a network of

IED’s. A switch uses MAC-addresses (Media Access Control) to transmit common

messages. It talks to all connected IED’s simultaneously. If a message is received, it

examines the MAC destination of the message and sends it to the one port that connects

to the destination IED. GOOSE-messages do not use destination addresses, so an

Ethernet switch sends a received GOOSE to all other ports apart the port from the

message input port. [20]

When a substation event occurs, messages are generated constantly. The

network traffic increases rapidly and the possibility of a message collision escalates.

Message collision generates delays and in the worst cases message failures. The

message delays are generated from the time that it takes a switch to process a message.

This is called latency delay. The delay may be longer if the message can not be sent,

because another is being sent, then the message waits in the memory for its turn to be

sent. [20]

30

As mentioned before in communication performance requirements chapter 2.13,

different message types have different performance requirements. And since GOOSE

message have strict performance requirements, the transmission of GOOSE messages

has to be ensured. One solution for this is to use VLAN (Virtual Local-Area Network).

VLAN can be used to divide physically connected network to needed network segment,

which reduces overall network traffic. Second solution is to use priority tagging. Each

message has a tag that signifies the importance of the message, and in case of backlog,

the message with higher priority is sent first. When designing a system, it must be noted

that most modern microprocessor relays support eight different levels of priority tags,

but all switches do not. [20]

For a redundant communication network the LAN should be looped or there

should be multiple connections between access points. The RSTP (Rapid Spanning Tree

Protocol), used by an Ethernet switch, detects the fault connection wire and reconfigures

the topology. RSTP itself does not provide redundancy against a switch. In critical high

voltage substation the system costs are not an issue and full redundancy of the network

is justifiable. Then system can be provide with to identical and parallel networks, which

can also be connected to together by IED’s that have two Ethernet ports. New

generation relays have two Ethernet ports that work simultaneously, connected to two

different networks. [20]

The Ethernet switches are in major role in concerning the networks reliability.

With priority tagging the performance of the messages can be achieved and with loop

support the messages do not circulate in the network ring. Since the switches are locate

in the substation, they are affected by electromagnetic, electric and magnetic fields, the

casing of the switch must be done and tested properly and support for fibre optics

should be considered. Since performance and reliability are major issues the costs of the

switches should not be the first constrain. [20]

2.17. Security

This chapter provides just a thin picture about the security of the substation network

with IEC 61850. The standard does not contain security solutions in itself. The aspect of

cyber-security is outside the scope of the standard, and therefore it is mainly up to

manufacturer and distribution companies to consider their communication solution and

system protection.

Since IEC 61850 relies on state-of-the-art communication protocols, it confronts

such security issues as intrusion attacks. Ethernet provides some security on its own

against malicious intruders, but such technologies for cyber protection as IP-routing,

firewall, VPN (Virtual Private Network) and IDS (Intrusion Detection System) is

needed to ensure secure operation outside the substation. IEC 61850 provides itself

some security in form of access control, but to ensure private and secure system, more

security protection should be provided. [28]

31

Firewalls, IDS’s etc. focus on individual devices on a network and slow down

communication due to operation times. The problem is that the firewalls, intrusion

detection software has to be applied carefully, since the real-time operation

requirements are strict. This point orientated security is conventional and common.

Other point of view is to apply the security via software “agent” that plugs into existing

network in a transparent manner. The agent software would not be attached to a single

point, but would perform active security analysis. The protection could be implemented

through strategically placed routers. [29]

Other functions need demand more secure operation than others. It shall be

noticed that, encrypting messages leads to longer processing times and such high-

priority messages as interlocking messages between substations must be fast, but still

secured. Therefore using encryption must be evaluated carefully with the help of

experts. IEC working group 57 is working on this problem and IEC/TR 61850-90-1 is

expected to be published at 2010.

Usually distribution companies use their own communication solutions, which

are not directly accessible from outside the system. A fairly common solution is to have

electric cables, which have optic fibre in the same cable. This way the system can be

build so that the networks in the substations are not accessible from the outside network.

The only access point from the outside networks would be routed from the control

station, and thus the security could be implemented centralized.

32

3. IEC 61850 AND WIND POWER

3.1. Evaluation perspectives

This section of the thesis evaluates the IEC 61850 standards impacts and possibilities in

wind power system. The purpose of this section is not to give detailed description of the

IEC 61400-25, but to evaluate which kind of impacts does the IEC 61850 concepts have

to the wind power systems. The evaluation is focused in wind power markets and the

state of wind power systems in Finland. The evaluation is not inclusive, but a short

summary of the IEC 61850 benefits to wind power systems from a substation

automation system vendors perspective. Although the evaluation only considers

Finland’s situation, the evaluations apply to global situation in some extend.

Wind power is aggressively growing branch globally, which is consequence of

strong politic efforts to reduce carbon oxide emissions. In Finland on 6 November 2008

the Government approved a new Climate Change and Energy Strategy, which stated

that the goal to produce 6 TWh electricity with wind power annually. This amount of

annually produces energy corresponds to 2000 MW of installed wind power depending

on the placements of the wind power plants. A feed-in-tariff is introduced to enforce

these targets. [30, 31] These targets forecast a rabid development in wind power

segment, since at May 2009 Finland had only 144 MW of installed wind power attached

to the national power grid. [32]

3.2. IEC 61400-25 and IEC 61850

IEC 61850 has been extended to support monitoring, information exchange and control

of wind power plant. The extended version is called IEC 61400-25 and the focus of it is

in the communication between the actors such as SCADA systems and wind power

plant components. Information concerning substations and feeders the IEC 61400-25

relies on IEC 61850. [33] The application section of the IEC 61400-25 covers all

components which operate a working wind turbine, such as meteorological system,

electrical system and management system including mechanical systems in wind power

generation. The IEC 61400-25 is an obvious addition after the IEC 61850, because the

possibility for distributed protection, monitoring and controlling is beneficial in wind

power systems. IEC 61850 could be used as it is in wind power systems, but since the

IEC 61850 does not cover the additional equipment needed for monitoring and

controlling wind power plants, it can not be used to for all data generated from a wind

power plant. The IEC 61400-25 has been divided into six different parts, which are

shown in table 8. [34]

33

Parts Title Description

1 Overall description of principles

an models

Overview of models and crucial

requirements and basic principles

2 Information model The description of common process data,

meta-data and configuration data

3 Information exchange model Service models to get, set and subscribe to

wind power plant information

4 Mapping to communication

profiles

Mapping for web services, MMS and other

profiles

5 Conformance testing Specifies techniques of testing

implementations

6 LN classes and Data classes for

Condition Monitoring

Defines information models for additional

condition monitoring systems

Table 8: The six parts of the IEC 618400-25

The IEC 61400-25 only extends the IEC 61850 to fit for the communication in

wind power plants. Figure 13 shows an example of the allocation of functions and parts

of the two standards in a wind power application.

Figure 13: An example of modelling a wind power system with the IEC 61400-25

and IEC 61850 [34]

34

3.3. The impact of the new standards

The IEC 61400-25 has been designed to support the needs of wind mill maintenance.

The wind power plant owners want to increase the responsibility in the maintenance and

operation of the wind mills. Previously the manufacturers have provided maintenance

services for fault-correction and preventive maintenance, which causes relatively high

costs to the owners. The IEC 61400-25 supports more accurate information and more

sophisticated maintenance. [34] Secondly the new standards offer all the benefits of IEC

61850: interoperability, fast communication, easy access to relevant data due to the

clever semantics and benefits to system design etc. Wind power plants require seamless

supervisory and IEC 61850 and IEC 61400-25 offer just that.

The maintenance is in major role, because it creates lot of variable costs to the

owner. In wind power plant the variable costs are fairly stable apart from the

maintenance costs. With sophisticated maintenance supervision non-scheduled and

fault-correcting maintenance can be reduced. With flexible possibilities to implement

communications, it is possible that the wind mill manufacturers supervise the system for

maintenance purposes and the owners operate and supervise the mill at the same time.

[35]

Since IEC 61400 and IEC 61850 are relatively new addition to the IEC

standards, primary equipment measurement units with compatible communications are

still not generalized in markets. Some kind of transition devices would be needed,

before intelligent primary devices emerge to the markets. Similar devices as MU, which

offer information in digitalized form, would be TCD (Turbine Controller Device) and

CMD (Condition Monitoring Device) in wind power systems. The TCD would gather

measurements concerning the turbine and the CMD would gather information

concerning condition of the devices. All gathered information is then offered forward in

IEC 61850/61400-25 compatible form. The TCD and CMD may also exchange

information between each other. [35]

Wind power turbines are continuously growing in size. In today’s markets the

largest unit size about seven megawatts. Lager unit sizes demand more complex

solutions and therefore seamless communication is vital. Larger mills need fast and

reliable communication for example in the, most common type of wind turbine,

horizontal axis turbine the drive train faces great forces and is expensive to repair.

Because the properties of the wind can not be predicted with sufficient accuracy, the

individual wind mill unit needs fast automation, which enables more optimized

production. Because the IEC 61850 and IEC 61400-25 offer a single interface for wind

mill application, substation communication with all additional equipment the full

automation should be fairly simple to implement. [35]

Although projects done with the new standards are mainly only demonstrations,

the demonstrations have been mostly successful and show the potential of the new

standards. The new standards are useful especially in wind farms, since they offer

interoperability between different manufacturer’s devices and therefore the wind farms

35

owner can easily build new wind mill units among the old ones and change equipment

as they see fit. This increases the lifespan of older systems, since all equipment does not

have to be changed. [35]

The new standards offer one communication solution for all equipment in wind

mills so multiple different protocols and systems can be avoided. Since the standards are

extensible and independent of communication implementation, they support future

state-of-the-art technology as well. The IEC 61850 and 61400-25 have so many

advantages to the communication solution used today, that it is obvious that the new

standards will become common. The only drawback is that the standards are relatively

new and the systems and devices are still suffering from small interoperability issues.

Systems with the new standards are still mainly in demonstration phase or systems are

only partially implemented with the new standards. For full systems more testing and

practical experience is needed. Compared to wind power automation systems that have

been installed, the new standard brings more organized solution. Previously the

provided automation systems have been mixed solution with separated entities. The new

standards offer all information within one package and in addition they offer much more

added value to the supervisor and to the wind mill owner. [35]

The windmills have also problems concerning electrical protection. The

common problems are that a windmill feeds an island network, which is undesirable

situation due to safety reasons, earth faults can not be detected by the protection relays

in wind mills and the protection has poor selectivity due to difficulties in fault location.

Also from a maintenance point of view the traditional protection relay inside every wind

mill is an issue especially if the windmills are located offshore. Because the IEC 61850

supports free allocation of the hardware the automation and measurements can locate in

different locations. The trip signal from other bays with GOOSE could help to prevent

the wind mills to feed an island network. Merging units could used to send

measurement values between substations to calculate fault locations for better

selectivity. IEC 61850 also enables various other protection schemas and functionality

for maintenance. [36, 37]

The new standards are ideal for protection in wind mill application, because the

standards are fully independent of physical location of the protection devices. The new

standards are not only beneficial in wind power application, but in all distributed

electricity generation. The most beneficial function in the IEC 61850 is the fast GOOSE

messaging system, which enables fast communication without hardwiring. The IEC

61850 and IEC 61400-25 do not themselves define all models for distributed generation,

but a new part named IEC 61850-7-420 has been designed to meet the requirement of

distributed energy recourses. The IEC 61850-7-420 was released in March 2009 and it

is outside the scope of this paper.

36

4. IEC 61850 DEMO SYSTEM

4.1. IEC 61850 system configuration

The IEC 61850 substation automation system configuration differences from earlier

conventions. The configuration order of an SAS goes from larger entities to more

detailed and not other way around. The configuration begins from defining the basic

system architecture such as voltage level, the amount of incoming and outgoing feeders,

protocol to SCADA and etc. The next step includes the selection of functions, which are

needed to define the protection, control and information acquisition schemas. The IED’s

should be selected parallel with the function defining. The following list is a conceptual

list for IEC 61850 system configuration. It works as a simplified check list for the

information needed for the system configuration.

A conceptual list for the information needed in IEC 61850 automation systems

configuration:

- Configuration training for the IED specific software

- Basic architecture of the system

o Voltage level

o All the devices which are connected to the IEC 61850 communication

bus

� Feeder automation

� Transformer protection

� Voltage regulation

� Motor protection

� Generator protection

� Station computers

� Gateways

� Other physical equipment

- Communication protocols to SCADA

- Functions based on the IED’s and protection, control and information

acquisition schemas

- The communication architecture and settings

o Local Area Network design

o IED’s TCP/IP settings

� IP-addresses

� Network names

� Network Mask

37

o GOOSE configurations

� GOOSE identifications

� Horizontal and vertical GOOSE communication

- Signal list to map SCADA objects

- SCL-files for communication configuration

- IEC 61850 object lists for IED’s

o MICS-lists

o PICS-lists

o Additional lists

4.2. Objectives of the demo

The main objective of the demo project is to test a substation automation system with

IEC 61850. The system includes equipment from multiple vendors and the goal is to test

the interoperability. The equipment is detailed below in table 9. The aim is to participate

with a working demo system to International Exhibition of Electricity,

Telecommunications, Light and Audio Visual fair at 3.-5.2.2010. The fair is arranged

every second year and it is one of the larges and most important fair in Scandinavia.

The demo system was build for educational purposes for engineers at UTU Elec

Oy. Another purpose of the demo system is to investigate interoperability and to get

knowhow to configure and set up working multi-vendor systems with IEC 61850. The

demo-system was built and configured mainly in Ulvila at UTU Elec Oy’s office and

during few weeks at Areva T&D Oy’s office at Frankfurt am Main.

4.3. Demo equipment

The demo equipment was selected with the help of the corresponding device

manufacturers. All software to configure the IED’s was also provided by the

manufacturers. Because Areva T&D is one of the financiers of this thesis, the station

computer and a protective relay was selected from the Areva’s product family. All the

selected devices are listed in table 9. The equipment was also selected by UTU Elec’s

needs in substation projects and by the equipment manufacturers importance in the

Finnish substation automation markets.

38

The demo equipment IED Configuration software

Substation computer

AREVA MiCOM C264

(Areva) system combined

RTU gateway, alarm unit,

voltage controller etc

PACiS SCE v.4.56.9.6

AREVA MiCOM P139 MICOM S1 Studio

v.3.1.1

VAMP VAMP52 Vampset v.2.2.15 Protective relays

ABB REF615 PCM600 v.2.2 and

CCT600 v.4.1.0.1

Voltage regulator

A-Eberle Reg-DA

WinConfigGOOSElight

v.6.56 and REG-PED PE

Loader v.1.3

Table 9: The selected devices for the IEC 61850 demo-system

The figure 14 shows a simplified model of the IED’s in the demo substation.

The protective relays simulate a single bay each and the voltage regulator simulates

information received from a single transformer. The figure 14 also includes

configuration information, which is explained in chapter 4.4.

Figure 14: A description of the demo equipment

Areva T&D

MiCOM C264

IP: 10.10.10.1

Name:

C264T1

Areva T&D

MiCOM P139

IP: 10.10.10.2

Name: P139T2

A-Eberle REG-DA

IP: 10.10.10.3

Name: REGDAT3 PC/SCADA

VAMP

VAMP52

IP: 10.10.10.4

Name:

VAMP52T4

ABB

REF615

IP: 10.10.10.5

Name: REF615T5

Goose

Goose

Goose

Goose/

MMS

Goose/

MMS

IEC

60870-

5-101

Goose/

MMS

Goose/

MMS

39

4.4. Additional demo equipment

The main purpose of the demo system is to give configured examples to UTU Elec Oy.

For this reason the configurations inside the IED’s are more inclusive than can be

exhibited (See Appendix A). Almost all configurations are shown in SCADA, but all

can not be tested or exhibited with the planned demo equipment.

In the demo system the protective relays have only one analog measurement

input voltage, which is the zero voltage Uo. The voltage transformer is simulated by a

transformer output 115 Vac. The zero voltage can be adjusted from 0 Vac to 115 Vac

with a single phase Variac (Variable autotransformer). The knob of the Variac is

mounted in the front panel of the case. The assembled and finished demo system is

show in figure 15.

Figure 15: Ready IEC 61850 demo-system equipment mounted in a wooden box

The switchgear is simply simulated by remanence relays, which have two

change-over contacts with a memory, thus they work as a real circuit breaker. Open

pulse from an IED output change the position of the contacts and the contacts must

remain in the changed position. The positions of the remanence relays are used to signal

the state of the switchgear to the IED. All simulated circuit breakers can be controlled

from the SCADA and from the HMI’s of the IED’s.

The C264 has an integrated Ethernet switch, but because it has only four RJ45

connections and two connection for fibre optic cable and one RJ45 connection is used

by the C264 itself, an additional switch must be used. The additional switch used is a

basic Ethernet switch with priority tagging support. Such switch could not be used in

C264 P139

REF615 VAMP52

REG-DA

Power on/off

Variac

Voltage display

40

real substation application for the reason explained in chapter 2.16, but in the demo-

system those issues do not cause problems.

4.5. Demo system communication design

The first steps, before starting the real configuration, include the defining of the signal

list and the learning process how to use the configuration programs. For the demo-

system the signal list was defined by Pasi Lauri from UTU Elec Oy. The list includes

the SCADA addresses mapped to data-attributes with the wanted data type. The signal

list is added to the appendix A.

To help the configuration the data sets for MMS and for GOOSE transmissions

should be defined before starting configuration. In the demo-system the data sets was

not defined completely before starting configuration. Only data sets for GOOSE was

defined, because all the devices come with preconfigured data sets for MMS

communication and those were used, since the amount of MMS communication is not a

issue in a small demo-system.

To understand the configuration programs it is important to understand at least a

basic philosophy behind the IEC 61850. Since the programs are depending on the

implementation solutions based on the manufacturer’s concepts from the IEC 61850, all

configuration programs have different approaches to configuration. It is easier for the

configuration engineer to understand why everything is done as they are done if he

understands the IEC 61850 concepts.

The next step is to select the IP-addresses, network mask and Network names for

basic communication. For GOOSE communication has to be defined at least the

Application ID’s and GOOSE identifiers. In the demo-system the setting were defined

as shown in table 10 and table 11.

IP-address Network Name Network Mask

Areva C264 10.10.10.1 C264T1 255.255.255.0

Areva P139 10.10.10.2 P139T2 255.255.255.0

A-eberle REG-DA 10.10.10.3 REGDAT3 255.255.255.0

VAMP VAMP52 10.10.10.4 VAMP52T4 255.255.255.0

ABB REF615 10.10.10.5 REF615T5 255.255.255.0

Table 10: Basic TCP/IP communication settings for the demo-system

41

APPID (Hex) Identifier

Areva C264 0001 C264T1

Areva P139 0002 P139T2

A-eberle REG-DA 0003 REGDAT3

VAMP VAMP52 0004 VAMP52T4

ABB REF615 0005 REF615T5

Table 11: Basic GOOSE communication settings for the demo-system

The network mask 255.255.255.0 defines that the all devices that have the first

three numbers common belong to the same network and that the last number in each

IED’s IP-address can selected freely between numbers 0-255. Additional settings for

GOOSE communication are the MAC-address, VLAN-ID, VLAN-priority,

Configuration Revision, Minimal time, Maximal time and the used data set. The

recommended MAC-address in GOOSE transmission is defined in the standard and it is

01-0C-CD-01-00-00. The recommendations for VLAN-ID is zero and for VLAN-

priority four. The configuration revision is the number of the GOOSE configuration

version in individual IED. The minimal time is the maximal response time when event

occurs and the maximal time is the time between GOOSE transmissions without data

changes [38]. The data set, which has been set to send via GOOSE, has limitations

concerning the amount of attributes. The naming of the setting attributes and can change

between different manufacturers. The needed information is also dependent of the used

configuration software.

After the IP-addresses have been set correctly to all devices, the connections to

the station computer C264 can be tested. Apart from the VAMP52, all devices in the

demo-system can be configured via the Ethernet (RJ45) port. The VAMP52 can be

easily configured via USB (Universal Serial Bus) port in front panel of the device. With

the USB cable attached to the VAMP52’s front panel and one Ethernet cable attached to

the bus via Ethernet switch all can be configured simultaneously with a single computer.

All that needs to be done is to connect auxiliary voltage supply to all the devices and

connect the devices to the same network via Ethernet switch. The REG-DA voltage

regulator was attached via optic fibre cables to the integrated switch in C264 bay

computer.

4.6. PACiS SCE

The PACiS SCE is a high level configuration tool, which is used to configure MiCOM

station computer for the communication between IED’s and station computer,

communication to remote station and for the station computers functions. The SCE can

not be compared with the other tools demonstrated in this work, since it is much more

42

complex tool than the others. The configuration is still fairly simple, but due to

interoperation problems between the manufacturers implementations the configuration

becomes more time consuming.

The MMS and the vertical GOOSE communication are depending on the

configuration in the C264 bay computer and the IED that is communicating with the

C264. The horizontal GOOSE communication between the voltage regulator and the

protective relays does not concern the C264 configuration. Since the demo-system has

only four IED’s in the bay level which communicate to SCADA via C264, there is no

need for additional gateway device. The PC which runs the SCADA simulator is

directly attached to the C264 via a serial port.

First step to start configuration of the MiCOM C264 bay computer with the

PACiS SCE is to import the ICD-files of the bay level devices. The imported files are

first validated to ensure that the ICD-files are compatible with the used SCL-schema

and after that the SCE maps file content to the configuration. The imported ICD-file is

used to map the IEC 61850 objects, which will be used to map the wanted data to the

SCADA link. The IEC 61850 mappings are attached to a generic IED, which stands for

in the PACiS SCE all the other devices than the C264. The generic IED’s are stored as

templates and have to be selected to the working configuration.

The working configuration has three different main sections, which are shown in

figure 16 in the middle screen. The three main sections are Site, SCS and Graphic. The

Site section represents the physical substation, where each device is mapped into virtual

bays. In the SCS section are all the generic IED’s with their IEC 61850 mappings. The

client server relations and SCADA configurations are also accomplishes in SCS section.

In the Graphic section the MIMIC’s for the C264 can be defined. Also larger graphics

for example for a PC can be defined in the Graphic section. Figure 16 shows the

interface of PACiS SCE software. The left side screens in the figure are for inserting

object to the working configuration in the middle and right side is basically for setting

configuration values.

43

Figure 16: Example picture from the PACiS SCE configuration tool [39]

After the generic IED has been attached to the working configuration in the SCS

section the needed signals from the designed signal list has to be transferred to the

virtual bays in the Site section. All signals can be named freely within limitations of the

name length. The wanted signal from the IEC 61850 mapping has to be selected with

the use of the corresponding manufacturer manuals. The signals for every device are

defined in the MICS (Model Implementation Conformance Statement) list and usually

the signals are explained more clearly and detailed in some additional document.

Basically the selected signal has to be linked to the virtual bay, named, linked to

SCADA and given the right SCADA address. At first the full configuration has to be

created from scratch, but after the first configuration, the created models can be saved as

templates and used in following projects.

After the configuration is finished and the check function gives no errors the

configuration must be saved as a “read only” version included with a configuration

version number. The check function is an important part of the PACiS SCE. The SCE is

included with a set of configuration rules and the check function gives outputs if some

configuration is not according to the rules. The read only version has to be converted to

a running configuration to the C264 bay computer. The configuration is converted with

a Generation function in the PACiS SCE. The generated file has to be transferred to the

C264 with software, which is called the computer maintenance tool. The C264 can have

to configuration files in it. One is a stand by file and the other is the running

configuration file. The file can be transferred with the maintenance tool via Ethernet

remotely. The transferred file sets itself as the stand by file and does not disturb the

44

running configuration. The stand by configuration can be switched with the running

configuration with the maintenance tool as well. After a file switch the computer boots.

The maintenance tools view for file switch is show in figure 17.

The PACiS SCE has functionality, which enables faster configuration. It is

possible to create templates from earlier configurations. The templates can be

constructed from the configuration by selecting the wanted entities. This way an

engineer can select a part from the configuration, which he needs. When the amount of

the finished configurations increases, the configuration time is shortened vastly.

Individual substation automation projects usually have lot of similarities, so it is

obvious that the template approach saves a lot of configuration work. The template

approach also reduces the risk of configuration errors, because the templates usually

have been tested in earlier projects.

Figure 16: C264 Computer Maintenance Tool data base setting view [40]

When all the bay level devices has been added to the generated configuration

and the basic communication setting has been set correctly for every device, the

connections between the station computer and bay level devices can be checked for

example from the C264 HMI. If any communication link is broken a led is on in the

front panel of the C264.

The PACiS SCE is relatively large program and learning process take a long

time, because the C264 versatile device and all configurations can be done with the

SCE. To help the configuration the PACiS SCE is equipped with a check function

which checks the entire configuration for configuration errors and warnings. The check

allows the configuration engineer to start configuration before fully mastering the

45

detailed configurations done with the SCE. The error and warning outputs have been

explained in the SCE and more detailed in the PACiS SCE technical guide.

4.7. Bay level IED configuration tools

The bay level devices were configured with their own configuration tools. All the tools

are relatively easy to use and fast to learn. The tools have lot of similarities, but a lot of

differences as well. Different vendor tools have little bit different focuses. Some tools

focus more to usability when configuring a single relay and some to configuration time

when configuring a large system. The focus of this work is not to compare different

configuration tools, but to document the difficulties that have been occurred in the

process of configuring the demo-system.

Modern substation IED’s are very versatile devices, but the configuration

becomes more complex. The reductions configuration time is considered to be one of

the major benefits of the IEC 61850, but since the standard is new and the softwares are

often based on older versions, the softwares do not always support this. For larger

systems the manufacturers should have some kind of tool for mapping GOOSE

communication. If such tool does not exist, the GOOSE mapping has to be done on

“paper” and transferred manually to each IED, which may be time-consuming task for

large systems and may cause configuration errors.

4.8. MiCOM S1 Studio

The MiCOM S1 Studio is combined from few configuration tools to a single interface.

The ICD-file for the PACiS SCE was received before starting the configuration with the

S1 Studio, but the same ICD-file and the CID-file can also be exported from the S1

Studio. The relay MiCOM P139 ICD-file had already broad predefined set of GOOSE

reports, but also own GOOSE reports could be used and configured. In the S1 Studio

the object names has been made very short, which makes the configuration more time

consuming. Because the names do not fully describe the objects, a manual has to be

used quite often. The solution has the idea that the information is displayed in the

configuration software as the information is displayed in the relays HMI and names

have to be short. But if the objects were fully described when selected, in a additional

window in the configuration program, the configuration would become much faster.

The window could for example include IEC 60617 symbol, ANSI C37-2 name, possible

IEC 61850 name and full description with full sentences. The P139 and the C264 did

not have any interoperation problems, which is clear since the devices are from the

same Areva product family and are fully tested.

The figure 17 shows the main configuration interface of the MiCOM S1 Studio.

On the right side of the figure is shown the configuration interface for IED settings. All

configurations concerning the P139 are possible to do in the setting tool. The setting

tool does not have a matrix application for signal mapping and for logical functions.

46

The MiCOM S1 Studio has a program called IEC61850 IED Configurator, which can be

launched from Tools menu or MCL 61850 files. The IED Configurator is for the SNTP

servers and for GOOSE publisher and subscriber settings, but it does not have the

possibility to modify the data sets. For an individual IED the GOOSE configuration can

be done in the setting tool, but if the system consists even of two bay level IED’s from

Areva product family, the IED Configurator is useful tool for mapping GOOSE and

time server information.

Figure 17: Main view of MiCOM S1 Studio

4.9. Vampset

The Vampset is simple configuration tool for all the configurations in the relay. The

ICD-file could be obtained only from the configuration tool when the IED is connected

to it. The configurations concerning the IEC 61850 objects are simple to modify by

selecting or deselecting the logical node in the configuration menu. In figure 18 is

shown the main view of the Vampset. The left side is navigating in the menus and the

right side is for setting the configurations. The tool is included with a matrix application

fro signal mapping and a logic editor additional logics. The VAMP’s approach to make

configuration simple ensures that the time consumed in configuration is minimal. The

setting menus, which are partly shown in figure 18, describe the functions so well, that

the time consumed with the manuals is minimal. The Vampset is only for setting a

single IED and it does not have the ability to configure GOOSE communication

47

between several relay simultaneously. The GOOSE settings are applied to ICD-files,

and it is possible to configure the relay with a CID-file.

Figure 18: Main view of Vampset configuration tool

The configured ICD-file of the VAMP52 had a small issue with the PACiS SCE.

The file was valid and the IEC 61850 mappings were mapped correctly, but because the

generation process uses the imported ICD-files, the generating process while converting

the file created an overflow error. The error was caused by report control definition in

the ICD-file. Since the demo-system is small only one data set was needed for MMS

reporting, the non-used report control definitions were deleted manually from the ICD-

file. In the appendix B is shown a part of the VAMP52 ICD-file and the deleted lines

are highlighted in red. This way the C264 database could be generated and all

configurations worked correctly. The VAMP’s approach to the ICD-file is to avoid

unnecessary information and keep the SCL files small, which saves time from the

station computer configuration in several stages.

48

4.10. WinConfig GOOSE light

The REG-DA is a voltage regulator and it is more focused device than a modern

protective relay. A voltage regulator does not have to have same kind of levels of

functionality and formability, thus the manufacturer can preconfigure the device more

accurately.

The WinConfig GOOSE light works trough an internet browser. The interface

layout is similar to several other configuration tools. The figure 19 show the main view

opened with Windows Explorer. The left side is for navigation and right side is for

setting the configuration. Trough the web browser the REG-DA can be also monitored

and configured in real time. All configurations can also be done in offline mode. The

ICD-file can be exported from the WinConfig tool, but the file was also offered

beforehand.

The REG-DA voltage regulator was tested for interoperability with the C264

bay computer by AREVA T&D. In the demo-system the REG-DA did not have lot of

signals and because of that the configuration was easy and no real problems occurred.

The only minor problem was that the selected model only supported IEC 61850

communication via optic connectors and at first the communication was not working

due to wrong kind of optic wires. With copper wires such problems would not occur.

Figure 19: Main view of WinConfig GOOSE light configuration tool

49

4.11. PCM600 and CCT600

The REF615 is fully native IEC 61850 IED, which means that the IED has been

designed to without any internal protocol conversion. All configuration objects are

named by the IEC 61850 logical names in the PCM600 and CCT600 configuration

tools, which is a good solution since the IEC 61850 mappings are relatively simple to

understand and unambiguous. Because the IEC 61850 names do not open the meaning

of the functions, the manuals and description lists has to be used quite often. Both

PCM600 and CCT600 are new programs developed to support IEC 61850

communication and both support system configuration. Although the tools are versatile,

the tools are easy and fast to use. The PCM600 and CCT600 tools exchange information

with SCL-files as exhibited in figure 12.

The CCT600 is tool for communication configurations. With the tool it is

possible to modify the IED’s data sets, Report control blocks, and Goose configuration

and create new ones or delete unnecessary ones. The CCT600 can also consume and

modify other vendor’s ICD- and CID-files and add them to the system configuration. It

is also possible to configure other vendors CID-files. This is a very useful feature for

viewing the ICD- or CID-files in a more comprehensive interface. The CCT600 is also

for Gateway configurations, but since it was not included in the demo system, it is

outside the scope of this paper. The figure 20 shows an example view of the CCT600

tool.

Figure 20: Main view of CCT600 system configuration tool

50

The PCM600 is a simple tool for e IED’s settings configurations. The figure 21

shows an example view of the PCM600 tool. The default view is similar to other IED

setting software. The right side is for navigation, the left side is for object properties and

the middle is for matrix tool and for parameter setting window. The PCM600 is not

enough to set up an IED for a working system, since it does not have the possibility to

configure GOOSE communication. The IED ICD-file has to be exported from the

PCM600 and imported to CCT600. The data set for GOOSE has to be created and

communication configured correctly. The GOOSE settings can be transported to

PCM600 by exporting the SCD-file from CCT600 and importing it to PCM600.

Figure 21: Main view of PCM600 IED configuration tool

In the demo-system the REF615 had few interoperation problems with the C264.

The first problem was that the REF615 ICD-file, included with report control block

definitions, did not import to the PACiS. The problem was caused by a missing report

control block definition: Report ID (rptID). The problem was solved by adding the

attribute to the ICD-file with the CCT600 tool. Second problem was that the full ICD-

file, with all description from REF615, created an error during configuration generation

with PACiS SCE. This problem was fixed by deleting unnecessary logical nodes and

report settings with the CCT600 tool. The third problem was that, the devices did not

exchanged MMS read and write services. The connection was established between the

devices, but the devices did not exchange MMS services. The problem was not solved

during the configuration of the demo-system. Since GOOSE communication did not

have any problems, the whole REF615 communication was executed with GOOSE.

51

4.12. Other useful tools

Because the standard is new and the IEC 61850 devices do not always interoperate as

planned, some debugging tools are necessary. There is some free software available in,

which are useful. The following introduces few software tools, which were used for

debugging and tracing problem spots during the configuration of the demo-system.

MMS-Etherreal tool is useful tool for reading MMS and GOOSE messages from

the Ethernet bus. The MMS-Etherreal tool is free software and can be freely

downloaded from the internet. The tool is useful for reading and debugging the

communication between devices. By connecting a Ethernet hub, which simply copies all

incoming messages to all of its ports, between two IED’s, the communication between

the devices can be copied to an external port for example for an PC’s Ethernet port. The

GOOSE messages can be read with an Ethernet switch as well, since the GOOSE

messages are sent as multicast.

The windows operating system’s ping-tool is useful for checking the Ethernet

connection between the IED and the PC. If connection is missing between a

configuration tool and an IED, the communication settings and communication wires

should be checked.

The Omicron IED scout tool has a free version, which can be used for opening

SCL-files and for monitor status changes in an IED. The Omicron IED scout tool only

needs the IP-address of the IED to read the IEC 61850 mappings from the IED. With

the tool the status changes inside an IED can be read by updating the attribute. The tool

is very useful in situations when a status is changed in bay level device, but is not

updated to the SCADA. If the status change can be read with the IED scout from the

bay level device the configuration problem is with the gateway device.

52

5. EXPERIENCES FROM TESTING MULTI-VENDOR SYSTEM

5.1. Configuration experiences

Because the standard is new and differences relatively radically from earlier standards,

the devices with IEC 61850 still suffer from small issues. Naturally the IED’s from

same manufacturer do not have interoperation problems, but the configuration of a

multi-vendor substation automation system involves lot of problem solving. This entire

chapter includes experiences gained during the demo-system configuration and suggests

some improvements. Most of the problems are already introduces in chapter four. All of

the problems that occurred during the configuration were not significant, but the

debugging takes time, since the devices do not have specially designed tools for

debugging interoperation problems.

All devices in the demo system need their own configuration tools. Learning to

use all configuration tools takes a lot of time and effort. The manuals for the IED’s by

themselves consist several thousand pages. The demo-system includes five different

devices and total of eight different configuration tools from which six main tool are

described in chapter four.

The demo system, described more detailed in chapter 4.2, has one bay computer,

three protective relays and one voltage regulator. The relays and the regulator

communicate with MMS and GOOSE to the bay computer. The first step when starting

this kind of configuration is to import the ICD-files to the bay computer tool. There are

different approaches with manufacturers how the ICD-file can be obtained. Usually it is

possible to have the ICD-file before the IED, but in some it is only possible to have the

ICD-file from the devices configuration tool after the devices existing configuration has

been downloaded to the tool. In the first case the ICD-file can be considered to be static

and in the second case the ICD-file can be considered to be dynamic. Both solutions

have their benefits and disadvantages.

It is also useful to keep in mind the difference of the ICD and CID-file, since

manufacturers have a little bit different approaches with these files. The content of the

files vary, because the IED’s are usually preconfigured by the manufacturer up to some

point. For this reason the difference between an ICD and a CID-file is indistinct.

Sometimes it is useful to use the CID-file instead of the ICD-file, because in some cases

the basic ICD-file does not include all needed information for the IED that acts as a

client.

53

5.2. Static or dynamic ICD-file

The largest disadvantage of the static ICD-file is the file size. A static ICD-file contains

all IEC 61850 logical nodes and all other description. Often most of the described

information is not needed and makes configuration more cumbersome. If the ICD-file

describes a complex IED, sometimes the size of the file can cause some problems as

described in chapter 4.10. The processing times for the file also increases when file is

unnecessary large. The processing time includes, in the case PACiS software, validation

and IEC mapping. At first the bay computer configuration tool has to validate the ICD-

file in order to ensure that the imported file valid according to the SCL-schema. The

next step is to process the description and map the IEC 61850 objects. The mapping

stage is a critical point where the MMS-communication is defined to the bay computer

and if manufacturers have slightly different perceptions about the standard, some

problems may occur.

A dynamic ICD-file is usually easier to import to the system and the problems

spots are easily discovered, because the point of the dynamic file is to keep the file as

simple as possible to avoid problems caused by file size or complexity. The only

problem in this kind optimization is that it emphasized the importance of planning the

working system before IED configuration. If the system plans are done carelessly and

some functions or logical nodes has to be added to the system, a new ICD-file with the

added function has to be imported to the system. Usually this means reconfiguration

work in several different steps. The VAMP52’s ICD-file is by default fairly empty, and

needed logical nodes has to be first added to the working configuration before the ICD-

file should be exported from the VAMPSET.

The best solution for the ICD-file would be a predefined dynamic file that can be

modified easily by the IED’s configuration tool. The ICD-file should be able to be

modified with IED configuration tool, because it ensures that the IED has exactly the

same IEC 61850 description than the ICD-file which is consumed by other tools. This

way the ICD-file can be modified due to interoperation problems with a simple

interface. The possibility of a modification error would be reduced, since the

configuration engineers would not have to manually modify the files.

5.3. The use of generic I/O’s

The standard allows the manufacturers to use the logical node GGIO, which stands for

generic process I/O. The GGIO is intended to be used in the situation when an input or

output is not covered by the standard. In the current IED’s the GGIO is used relatively

much to map different information. The use of GGIO’s has its benefits and drawbacks.

If GGIO a logical node is used without a prefix, it does not have any logical meaning,

because the logical node GGIO does not signify a corresponding logical function. The

general use of the GGIO is not recommended, because it is not what the standard

intended. Usually the GGIO’s are mapped to represent actual free inputs or output in the

54

device. The manufacturers use the GGIO also to map virtual signals of an IED, which

then can be used for example for internal logics. Because the standard does not describe

all specific information that manufacturers want to transmit, the GGIO has become a

sort of a dump logical node, instead of creating new logical nodes, which would

describe the function more accurately.

The GGIO is useful in situations when an IED’s input or output function is not

the intended type that has been designed for the system. Different manufacturer’s

protective relays use the same logical nodes, but the attributed are not always the same

type. For example to change setting croup the attribute can be singlepoint control,

doublepoint control or multi point control. To keep the control commands consistent for

every device, sometimes GGIO has to be used, because it is the only way to get the data

point in right type to SCADA. In the demo system the GGIO’s had to be used in several

points, because in some cases the signal could not be modified correctly at the bay

computer. One solution would be to map the signal as defined in IED’s, and to keep the

SCADA commands consistent, map the signals as designed at the SCADA end.

The GGIO’s importance may reduce after process level IED’s become more

common. This means that the amount of physical inputs and outputs will reduce. All

connections are virtual connections, which communicate through the common

communication line. The second version of the IEC 61850 standard has more

predefined logical nodes, which should strengthen the proper use of the standard.

5.4. Goose mapping

To configure few GOOSE messages for a small system is not an issue, but for larger

system some kind of configuration tool to configure all devices in the working system is

necessary. Since GOOSE configuration is at least partly up to the device user, the

manufacturers can not preconfigure the GOOSE communication to IED’s completely.

To use interlocking between IED’s within a large system each IED has to be aware of

the GOOSE configuration in other IED’s. GOOSE messages are published constantly to

every port in the same network, the subscribing IED has to be configured to read the

message from the dataflow and use it as designed.

In the demo-system the GOOSE messaging system was successfully

demonstrated by sending the GOOSE signals to the bay computer from the other IED’s.

Two instances of residual overvoltage trips were sent from the protection IED’s and

shown with LED’s in the bay computer. The GOOSE data-sets did have the content

defined in the signal list in the appendix A, but only the residual overvoltage instances

were used in the demo-system. Horizontal GOOSE was not demonstrated, because

every device did not support the ability to show the received GOOSE in the devices

front display leds.

55

5.5. The debug schema

The figure 22 shows the debug schema that actualized during the demo-system

configuration. The figure 22 states that the ICD-files can be exported from the IED

configuration tool for PACiS SCE. Error or configuration fault may lead to

reconfiguration in the C264 bay computer configuration or in the IED’s configuration.

Sometimes the error correction had to be done manually altering the ICD-file with

XML-editor. If some correction was done to the ICD-files, it meant for a modification

in the C264 configuration, which adds the time consumed with configuration

significantly.

Figure 22: A simplified IEC 61850 demo-system debug schema. The green lines

illustrate the flow of ICD-files. The blue lines illustrate the flow of C264

configuration file. The red lines illustrate error or the need of reconfiguration. The

error correction can be done in several places depending on the problem. The back

line illustrates a running configuration.

P139 REF615 REG-DA VAMP52 IED’s

IED Configuration tools

MiCOM S1

Studio

PCM600 GOOSElight

Vampset

CCT600

PACiS SCE

Computer

maintenance tool

ICD-files

Or

C264

Configuration

not working as

designed

System not working as

designed

C264 Station computer

XML-editor

56

6. CONCLUSION

The new international substation standard IEC 61850 is reforming substation

automation. Technologies such as TCP/IP, Ethernet and low-cost high-performance

computers have enabled a new kind of approaches for substation automation. Since the

limitation of the bandwidth no longer exists, vast amounts of data can be moved through

the station bus. The standard offers predefined communication with predefined

functionality, compatibility between different manufacturers and less hard wiring and

several other benefits. The most crucial benefit is that the standard supports substation

automations future needs.

The new standard has a lot of benefits compared to earlier solutions, but because

of the differences to earlier solutions, the standard is suffering from small

implementation issues. The small issues do not affect how the devices work in systems

constructed from one manufacturer’s IED’s. In multi-vendor system the devices, which

has not been tested for interoperability, in great probability will have compatibility

problems. The amount of small implementation issues will undoubtedly decrease and

more serious problems should disappear in time after the manufacturers get more

experience and expertise. The amount of interoperation problems suggests that the

standard may allow too much implementation freedom for the manufacturers. An

additional standard which would list all know issue areas and offer solution, could

ensure better interoperability. Such standards are already in use in other industries,

which need standardization for interoperability.

The IEC 61850 is praised to improve several aspects in substation automation.

One aspect is to make configuration easy and less time consuming. The configuration

time is an important benefit of the IEC 61850, but it has not yet been realised, because

of the interoperation problems. While working with the demo-system, the time

consumed in debugging the compatibility error was several times over the actual

configuring device time. The devices, which had been tested before together, were easy

and quick to add in the working system, but with every device which had not been

tested, problems were encountered. Most of the problems were caused by the SCL-files

during the bay computer configuration, except one problem with MMS communication,

which was not solved during this work. During the demo-system configuration mainly

ICD-files were used, but most likely other SCL-files would cause similar problems if

they were used in multivendor-system configuration. GOOSE communication worked

without any real problems between the devices, which good for the success of the

demo-system, because the GOOSE communication was in major role in the demo.

57

REFERENCES

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

[2] Tholomier, D. Chatrefou, D. 2008. IEC 61850 Process Bus - It is Real! [Used:

5.10.2009] Available at: http://www.pacw.org/fileadmin/doc/WinterIssue08/protection_61850_winter08.pdf

[3] Proudfoot, D. 2002. UCA and 61850 for dummies. Siemens Power

Transmission & Distribution.

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

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

[6] IEC 61850-8-1. 2004. Communication networks and systems in substations –

Part 8-1: Specific Communication Service Mapping (SCSM) – Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3. IEC. 133 p.

[7] IEC 61850-9-1. 2003. Communication networks and systems in substations – Part 9-1: Specific Communication Service Mapping (SCSM) – Sampled values over serial unidirectional multidrop point to point link. IEC. 29 p.

[8] IEC 61850-9-2. 2004. Communication networks and systems in substations – Part 9-2: Specific Communication Service Mapping (SCSM) – Sampled values over ISO/IEC 8802-3. IEC. 28 p.

[9] Mackiewicz R. Technical Overview and Benefits of the IEC 61850 Standard for

Substation Automation. 8 p. [10] IEC 61850-7-1. 2003. Communication networks and systems in substations –

Part 7-1: Basic communication structure for substation and feeder equipment –

Principles and models. IEC. 110 p.

[11] Baigent, D. Adamiak, M. Mackiewicz, R. 2004. IEC 61850 Communication

Networks and Systems In Substations: An Overview for Users, SIPSEP

Monterrey, Nuevo León, México Miércoles. [Used: 28.7.2009] Available at:

http://www.sisconet.com/downloads/SIPSEP%202004%20IEC%2061850%20P

anel%20Presentation%20-%20SISCO.ppt

58

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

[13] Overview and Introduction to the Manufacturing Message Specification (MMS).

[Used: 29.7.2009] Available at: http://www.sisconet.com/downloads/mmsovrlg.pdf

[14] Brand, K-P, Senior Member, IEEE. The Standard IEC 61850 as Prerequisite for

Intelligent Application in Substations.

[15] Tarlochan, S. Mitalkumar G. Palak P. 2008. Implementation Issues with IEC 61850 Based Substation Automation Systems. Fifteenth National Power Systems Conference (NPSC), IIT Bombay, December 2008.

[16] Lars Andersson, Klaus-Peter Brand, Dieter Fuechsle. 2008. Optimized

Architectures for process bus with IEC 61850-9-2. Cigre Session 2008. [17] Ozansoy, C. Zayegh, A. Kalam, A. 2009. Object Modeling of Data and DataSets

in the International Standard IEC 61850. IEEE Transactions on power systems, Vol. 24, No. 3, July 2009. pp 1140-1147.

[18] IEC 61850-7-2. 2003. Communication networks and systems in substations –

Part 7-2: Basic communication structure for substation and feeder equipment – Abstract communication service interface (ACSI). IEC. 171 p.

[19] Schwarz, K. Introduction to the Manufacturing Message Specification (MMS,

ISO/IEC 9506). [Used: 2.3.2010] Available at:

http://www.nettedautomation.com/standardization/ISO/TC184/SC5/WG2/mms_

intro/

[20] Hou, D. Dolezilek, D. Schweitzer Engineering Laboratories, Inc. IEC 61850 – What It Can and Cannot Offer to Traditional Protection Schemes [Used: 3.8.2009] Available at: http://www.selinc.com/WorkArea/DownloadAsset.aspx?id=3546

[21] Zhang, L, X. Nair, N-M, C. 2008. Testing Protective Relays in IEC 61850

Framework. 2008 Australasian Universities Power Engineering Conference

(AUPEC'08).

[22] Brand, K-P. Janssen, M. The specification of IEC 61850 based substation automation systems.

[23] Dreher, A. Mohl, D. Precision Clock Synchronization - The Standard IEEE

1588. [Used: 4.8.2009] Available at: http://www.pes-psrc.org/h/HTF1_Presentation_1_1588_Skendzic.pdf

59

[24] Kasztenny, B. Whatley, J. Udren, E. Burger, J. Finney, D. Adamiak, M. 2006. IEC 61850 - A Practical Application Primer for Protection Engineers. [Used: 20.2.2010] Available at: http://www.gedigitalenergy.com/multilin/pr/GaTech/2006/IEC61850_Practical_Application_Primer_Protection_Eng.pdf

[25] IEC 61850-6. 2004. Communication networks and systems in substations – Part

6: Configuration description language for communication in electrical substation

related to IEDs. IEC. 144 p.

[26] Goraj, M. Herrmann, J. 2007. Experience in IEC 61850 and possible improvements of SCL language. [Used: 1.10.2009] Available at: http://www.sisconet.com/downloads/GE_E_2007.pdf

[27] Andersson, L. Brand, K-P. Brunner, C. Wimmer, W. 2005. Reliability investigations for SA communication architectures based on IEC 61850. Presented as Paper 604 in the Poster Session at 2005 IEEE St.Petersburg PowerTech, June 27-30, St.Petersburg, Russia.

[28] Skendzic, V. Moore, R. Extending the Substation LAN Beyond Substation Boundaries: Current Capabilities and Potential New Protection Applications of Wide-Area Ethernet.

[29] Coates, G. Hopkinson, K. Graham, S. Stuart H. Kurkowski, S. 2008.

Collaborative, Trust-Based Security Mechanisms for a Regional Utility Intranet. IEEE Transactions on power systems, Vol. 23, No. 3, August 2008. pp 831-844.

[30] Syöttötariffityöryhmän loppuraportti, Ehdotus tuulivoimalla ja biokaasulla

tuotetun sähkön syöttötariffiksi, Pupliched: November 2009, Publications of the Ministry of Employment and the Economy, Energy and Climate, Available at: http://www.tem.fi/files/25308/TEMjul_59_2009_energia.pdf

[31] The Finnish Wind Power Association. briefing 15.6.2009. [Used: 24.9.2009]

Available at: http://www.tuulivoimayhdistys.fi/tiedotteet

[32] Wind energy statistics in Finland. [Used: 24.9.2009] Available at:

http://www.vtt.fi/proj/windenergystatistics/index.jsp

[33] Schwarz, K. 2004. IEC 61850, IEC 61400-25, IEC 61970: Information models

and information exchange for electric power systems. [Used: 24.8.2009]

Available at: http://nettedautomation.com/download/Paper_IEC61850_Distribu

tech_2004-02-10.pdf

[34] Johnsson, A. Højholt, L. Use of IEC 61400-25 to secure access to key O&M

data. [Used: 24.9.2009] Available at:

http://www.eow2007proceedings.info/allfiles2/170_Eow2007fullpaper.pdf

60

[35] Schwarz, K. 2004. Advanced Condition Monitoring of Primary Equipment with the Standard Series IEC 61850 AND IEC 61400-25. [Used: 23.9.2009] Available at: http://www.cepsi2008.org/CEPSI2008/files/oral/26/full_paper_karlheinz_schwarz.pdf

[36] Hunt, R. Cardenas, J. Muthukrishnan, V. McGinn, D. 2010. Wind Farm

Protection Using an IEC 61850 Process Bus Architecture. [Used: 20.5.2010] Available at: http://www.dtechspeakers.com/etc/medialib/distributech/documents.Par.88688.File.dat/Sample%20Manuscript.pdf

[37] Lauri, P. 2010. UTU Elec Oy. E-mail 19.5.2010 [38] ABB, REF615 manual, IEC 61850 - 615 series Engineering Guide. [39] Areva, PACiS SCE System Configuration Editor Technical Guide. [40] Areva, MiCOM C264/C264C Bay Computer Technical Guide

61

APPENDIX A - Signal list for the IEC 61850 demo-system

C264

Signal Areva

Type Bay Computer SPS 1001 Position/Event Din1 0/1

SPS 1002 Position/Event Din2 0/1

SPS Count active power pulses Di3

SPS Count reactive power pulses Di4

Goose Led4 Show goose

Goose Led5 Show goose

Goose Led6 Show goose

Goose Led7 Show goose

Goose Led8 Show goose

Goose Led9 Show goose

Goose Led10 Show goose

Goose Led11 Show goose

Goose Led12 Show goose

Goose Led13 Show goose

Goose Led14 Show goose

Goose Led15 Show goose

Goose Led16 Show goose

MV 1030 Voltage Uo C264

MV Disp2 Voltage Uo P139

MV Disp2 Voltage Uo VAMP52

MV Disp2 Voltage Uo REF

MV Disp2 Voltage Uo 7SJ62

MV Disp2 Voltage U REG DP

SPS/MV Disp1 Alarm Di1 C264

SPS/MV Disp1 Alarm Di2 C264

SPS/MV Disp1 Alarm Di7 P139

SPS/MV Disp1 Alarm Di8 P139

SPS/MV Disp1 Alarm Di7 REF

SPS/MV Disp1 Alarm Di8 REF

SPS/MV Disp1 Alarm Di7 7SJ62

SPS/MV Disp1 Alarm Di8 7SJ62

SPS/MV Disp1 Alarm Di7 REG

SPS/MV Disp1 Alarm Di8 REG

X/MV Disp3 P139 mimic

X/MV Disp4 VAMP52 mimic

X/MV Disp5 REF mimic

X/MV Disp6 7SJ62 mimic

X/MV Disp5 REG mimic

MV 1031 Active power pulses in Di3

MV 1032 Reactive power pulses in Di4

DPC 1050 Set All Local/Remote LS=1 RS=2 LRE=3

SPC 1051 Send Energy pulses to SCADA=1 (Di3&4)

SPC 1052 All Protection to Main setup=0 Backr s=1

62

P139

Signal Areva

Type Cell terminal relay DPS 1100 Position/Event CB off=1 on=2

DPS 1101 Position/Event Truck Discon=1 Connect=2

DPS 1102 Position/Even Earthing Sw Discon=1 Connect=2

SPS 1103 Position/Event Remote=1 Local=2

SPS 1104 Position/Event Protection Mainsetup=0 Backr=1

SPS 1105 Position/Event ARC Off=0 On=1

SPS 1106 Position/Event Din7 0/1

SPS 1107 Position/Event Din8 0/1

SPS 1108 Position/Event Din9 0/1

SPS 1109 Position/Event Din10 0/1

SPS 1110 Event I> trip=1 off=0

SPS 1111 Event I>> trip=1 off=0

SPS 1112 Event I>>> trip=1 off=0

SPS 1113 Event Iodir> trip=1 off=0

SPS 1114 Event Iodir>> trip=1 off=0

SPS 1115 Event AR Final trip=1 off=0

SPS 1116 Event CT superv. alarm=1 off=0

SPS 1117 Event CBFP trip=1 off=0

SPS 1118 Event Uo> trip=1 off=0

SPS 1119 Event Io>> trip=1 off=0

Goose Goose I> trip=1 off=0

Goose Goose I>> trip=1 off=0

Goose Goose I>>> trip=1 off=0

Goose Goose Goose Uo> trip=1 off=0

Goose Goose Goose Uo>> trip=1 off=0

Goose Goose Goose Di(7) free input

Goose LedXX Show goose

MV 1130 Current L1

MV 1131 Current L2

MV 1132 Current L3

MV 1133 Voltage U12

MV 1134 Voltage U23

MV 1135 Voltage U31

SPS/MV 1136 Residual current Io

SPS/MV 1137 Zero sequence voltage Uo

SPS/MV 1138 Active power

SPS/MV 1139 Reactive power

SPS/MV 1140 Trippint current Iodir> pu

SPS/MV 1141 Tripping Iodir> Uo%

X/MV 1142 Trippint current Iodir>> pu

X/MV 1143 Tripping Iodir>> Uo%

X/MV 1144 Tripping Uo> Uo%

X/MV 1145 Tripping Uo>> Uo%

X/MV 1146 Tripping current I> *In

MV 1147 Tripping current I>> *In

MV 1148 Tripping current I>>> *In

DPC 1150 CB select/execute 0s=1 Cs=2 0CE=3

DPC 1151 Eart Sw select/execute 0s=1 Cs=2 0CE=3

SPC 1152 AR Disconnected=0 Enabler=1

SPC 1153 Protection Main setup=0 Backround setup=1

63

52

Signal VAMP

Type Feeder and motor protection relay

DPS 1200 Position/Event CB off=1 on=2

SPS 1203 Position/Event Remote=1 Local=2

SPS 1204 Position/Event Protection Mainsetup=0 Backr=1

SPS 1205 Position/Event ARC Off=0 On=1

SPS 1210 Event I> trip=1 off=0

SPS 1211 Event I>> trip=1 off=0

SPS 1212 Event I>>> trip=1 off=0

SPS 1213 Event Iodir> trip=1 off=0

SPS 1214 Event Iodir>> trip=1 off=0

SPS 1215 Event AR Final trip=1 off=0

SPS 1216 Event CT superv. alarm=1 off=0

SPS 1217 Event CBFP trip=1 off=0

SPS 1218 Event Uo> trip=1 off=0

SPS 1219 Event Io>> trip=1 off=0

Goose Goose I> trip=1 off=0

Goose Goose I>> trip=1 off=0

Goose Goose I>>> trip=1 off=0

Goose Goose Goose Uo> trip=1 off=0

Goose Goose Goose Uo>> trip=1 off=0

Goose LedXX Show goose

MV 1230 Current L1

MV 1231 Current L2

MV 1232 Current L3

MV 1233 Residual current Io

MV 1234 Zero sequence voltage Uo

SPS/MV 1240 Trippint current Iodir> pu

SPS/MV 1241 Tripping Iodir> Uo%

X/MV 1242 Trippint current Iodir>> pu

X/MV 1243 Tripping Iodir>> Uo%

X/MV 1244 Tripping Uo> Uo%

X/MV 1245 Tripping Uo>> Uo%

X/MV 1246 Tripping current I> *In

MV 1247 Tripping current I>> *In

MV 1248 Tripping current I>>> *In

DPC 1250 CB select/executeB 0s=1 Cs=2 0CE=3

SPC 1252 AR Disconnected=0 Enabler=1

SPC 1253 Protection Main setup=0 Backround setup=1

64

REF615

Signal ABB

Type Feeder protection relay DPS 1300 Position/Event CB off=1 on=2

DPS 1301 Position/Event Truck Discon=1 Connect=2

DPS 1302 Position/Even Earthing Sw Discon=1 Connect=2

SPS 1303 Position/Event Remote=1 Local=2

SPS 1304 Position/Event Protection Mainsetup=0 Backr=1

SPS 1305 Position/Event ARC Off=0 On=1

SPS 1306 Position/Event Din7 0/1

SPS 1307 Position/Event Din8 0/1

SPS 1308 Position/Event Din9 0/1

SPS 1309 Position/Event Din10 0/1

SPS 1310 Event I> trip=1 off=0

SPS 1311 Event I>> trip=1 off=0

SPS 1312 Event I>>> trip=1 off=0

SPS 1313 Event Iodir> trip=1 off=0

SPS 1314 Event Iodir>> trip=1 off=0

SPS 1315 Event AR Final trip=1 off=0

SPS 1316 Event CT superv. alarm=1 off=0

SPS 1317 Event CBFP trip=1 off=0

SPS 1318 Event Uo> trip=1 off=0

SPS 1319 Event Io>> trip=1 off=0

Goose Goose I> trip=1 off=0

Goose Goose I>> trip=1 off=0

Goose Goose I>>> trip=1 off=0

Goose Goose Goose Uo> trip=1 off=0

Goose Goose Goose Uo>> trip=1 off=0

Goose Goose Goose Di(7) free input

Goose LedXX Show goose

MV 1330 Current L1

MV 1331 Current L2

MV 1332 Current L3

MV 1333 Voltage U12

MV 1334 Voltage U23

MV 1335 Voltage U31

SPS/MV 1336 Residual current Io

SPS/MV 1337 Zero sequence voltage Uo

SPS/MV 1338 Active power

SPS/MV 1339 Reactive power

SPS/MV 1340 Trippint current Iodir> pu

SPS/MV 1341 Tripping Iodir> Uo%

X/MV 1342 Trippint current Iodir>> pu

X/MV 1343 Tripping Iodir>> Uo%

X/MV 1344 Tripping Uo> Uo%

X/MV 1345 Tripping Uo>> Uo%

X/MV 1346 Tripping current I> *In

MV 1347 Tripping current I>> *In

MV 1348 Tripping current I>>> *In

DPC 1350 CB select/execute 0s=1 Cs=2 0CE=3

DPC 1351 Eart Sw select/execute 0s=1 Cs=2 0CE=3

SPC 1352 AR Disconnected=0 Enabler=1

SPC 1353 Protection Main setup=0 Backround setup=1

65

REG-DA

Signal A eberle

Type Voltage regulator SPS 900 Position/Event Remote=1 Local=2

SPS 901 Position/Event Man=0 Auto=1

SPS 902 Position/Event Setpoint Mainsetup=0 Backr=1

SPS 903 Position/Event Din2 0/1

SPS 904 Position/Event Din3 0/1

SPS 905 Position/Event Din4 0/1

SPS 910 Event I> trip=1 off=0 (block operation)

SPS 911 Event Regulator fault

SPS 912 Event Tap changer doesn't work

Goose Goose I> trip=1 off=0

Goose LedXX Show goose

Goose Goose Goose Di2

Goose Goose Goose Di3

MV 930 Position of the OLTC

SPC 950 Manual=0 Auto=1

SPC 951 Voltage Lower=1

SPC 952 Voltage Raise=1

SPC 953 Setup Main setup=0 Backround setup=1

66

APPENDIX B -VAMP52 ICD-file debug <?xml version="1.0" encoding="UTF-8"?>

<!--This file is generated using INFO TECH IEC61850 Server Configuration Tool (www.infotech.pl)-->

<SCL xmlns="http://www.iec.ch/61850/2003/SCL" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.iec.ch/61850/2003/SCL SCL.xsd">

<Header id="INFO TECH SCL" nameStructure="IEDName"/>

<Communication>

<SubNetwork name="NONE">

<ConnectedAP iedName="VAMP52T4" apName="P1">

<Address>

<P type="OSI-AP-Title">1,3,9999,33</P>

<P type="OSI-AE-Qualifier">1</P>

<P type="OSI-PSEL">00000001</P>

<P type="OSI-SSEL">0001</P>

<P type="OSI-TSEL">0001</P>

<P type="IP">10.10.10.4</P>

<P type="IP-SUBNET">255.255.255.0</P>

<P type="IP-GATEWAY">0.0.0.0</P>

</Address>

<GSE ldInst="Relay" cbName="gcb1">

<Address>

<P type="VLAN-ID">0</P>

<P type="VLAN-PRIORITY">4</P>

<P type="MAC-Address">01-0C-CD-01-00-00</P>

<P type="APPID">4</P>

</Address>

</GSE>

<GSE ldInst="Relay" cbName="gcb2">

<Address>

<P type="VLAN-ID">0</P>

<P type="VLAN-PRIORITY">4</P>

<P type="MAC-Address">01-0C-CD-01-00-00</P>

<P type="APPID">1</P>

</Address>

</GSE>

</ConnectedAP>

</SubNetwork>

</Communication>

<IED name="VAMP52T4" type="VAMP 52" manufacturer="VAMP Ltd." configVersion="0.0.1">

<Services>

<DynAssociation/>

<GetDirectory/>

<GetDataObjectDefinition/>

<DataObjectDirectory/>

<GetDataSetValue/>

<SetDataSetValue/>

<DataSetDirectory/>

<ConfDataSet max="5" maxAttributes="150"/>

<DynDataSet max="16" maxAttributes="100"/>

<ReadWrite/>

<ConfReportControl max="6"/>

<ReportSettings bufTime="Conf" trgOps="Conf" cbName="Fix" rptID="Conf" datSet="Conf" intgPd="Conf"

optFields="Conf"/>

<GetCBValues/>

67

<GSEDir/>

<GOOSE max="2"/>

</Services>

<AccessPoint name="P1">

<Server>

<Authentication none="true"/>

<LDevice inst="Relay">

<LN0 lnType="LLN0_0" lnClass="LLN0" inst="">

<DataSet name="DS1">

<FCDA ldInst="Relay" prefix="AR1ft" lnClass="GGIO" lnInst="16" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="AR2ft" lnClass="GGIO" lnInst="17" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="AR3ft" lnClass="GGIO" lnInst="18" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="AR4ft" lnClass="GGIO" lnInst="19" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="AR5" lnClass="RREC" lnInst="1" doName="BlkRec" fc="ST"/>

<FCDA ldInst="Relay" prefix="AR5" lnClass="RREC" lnInst="1" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="AR5" lnClass="RREC" lnInst="1" doName="AutoRecSt" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARcft" lnClass="GGIO" lnInst="15" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARcre" lnClass="GGIO" lnInst="13" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARft" lnClass="GGIO" lnInst="14" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARloc" lnClass="GGIO" lnInst="2" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARre1" lnClass="GGIO" lnInst="3" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARre2" lnClass="GGIO" lnInst="4" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARre3" lnClass="GGIO" lnInst="5" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARre4" lnClass="GGIO" lnInst="6" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARre5" lnClass="GGIO" lnInst="7" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARrun" lnClass="GGIO" lnInst="1" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARsh1" lnClass="GGIO" lnInst="8" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARsh2" lnClass="GGIO" lnInst="9" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARsh3" lnClass="GGIO" lnInst="10" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARsh4" lnClass="GGIO" lnInst="11" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ARsh5" lnClass="GGIO" lnInst="12" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="CBFP" lnClass="PIOC" lnInst="4" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="CBFP" lnClass="PIOC" lnInst="4" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="DEF1" lnClass="PTOC" lnInst="9" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="DEF1" lnClass="PTOC" lnInst="9" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="DEF2" lnClass="PTOC" lnInst="10" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="DEF2" lnClass="PTOC" lnInst="10" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="DI01" lnClass="GGIO" lnInst="45" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="DI02" lnClass="GGIO" lnInst="46" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="DI03" lnClass="GGIO" lnInst="47" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="DI04" lnClass="GGIO" lnInst="48" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="DI05" lnClass="GGIO" lnInst="49" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="DI06" lnClass="GGIO" lnInst="50" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="DI07" lnClass="GGIO" lnInst="51" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="DI08" lnClass="GGIO" lnInst="52" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="EF1" lnClass="PTOC" lnInst="4" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="EF1" lnClass="PTOC" lnInst="4" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="EF2" lnClass="PTOC" lnInst="5" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="EF2" lnClass="PTOC" lnInst="5" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="I3pda" lnClass="MMXU" lnInst="3" doName="A.phsA" fc="MX"/>

<FCDA ldInst="Relay" prefix="I3pda" lnClass="MMXU" lnInst="3" doName="A.phsB" fc="MX"/>

<FCDA ldInst="Relay" prefix="I3pda" lnClass="MMXU" lnInst="3" doName="A.phsC" fc="MX"/>

<FCDA ldInst="Relay" prefix="I3p" lnClass="MMXU" lnInst="1" doName="A.phsA" fc="MX"/>

<FCDA ldInst="Relay" prefix="I3p" lnClass="MMXU" lnInst="1" doName="A.phsB" fc="MX"/>

<FCDA ldInst="Relay" prefix="I3p" lnClass="MMXU" lnInst="1" doName="A.phsC" fc="MX"/>

<FCDA ldInst="Relay" prefix="I3pr" lnClass="MMXU" lnInst="2" doName="A.phsA" fc="MX"/>

<FCDA ldInst="Relay" prefix="I3pr" lnClass="MMXU" lnInst="2" doName="A.phsB" fc="MX"/>

68

<FCDA ldInst="Relay" prefix="I3pr" lnClass="MMXU" lnInst="2" doName="A.phsC" fc="MX"/>

<FCDA ldInst="Relay" prefix="IOC1" lnClass="GGIO" lnInst="142" doName="AnIn" fc="MX"/>

<FCDA ldInst="Relay" prefix="IOC2" lnClass="GGIO" lnInst="143" doName="AnIn" fc="MX"/>

<FCDA ldInst="Relay" prefix="IOC3" lnClass="GGIO" lnInst="144" doName="AnIn" fc="MX"/>

<FCDA ldInst="Relay" prefix="IoC" lnClass="MMXU" lnInst="13" doName="A.res" fc="MX"/>

<FCDA ldInst="Relay" prefix="LO01" lnClass="GGIO" lnInst="77" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="LO02" lnClass="GGIO" lnInst="78" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="LO03" lnClass="GGIO" lnInst="79" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="LO04" lnClass="GGIO" lnInst="80" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="LO05" lnClass="GGIO" lnInst="81" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="LO06" lnClass="GGIO" lnInst="82" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="Obj1" lnClass="CSWI" lnInst="1" doName="Pos" fc="ST"/>

<FCDA ldInst="Relay" prefix="Obj1" lnClass="RSYN" lnInst="1" doName="Rel" fc="ST"/>

<FCDA ldInst="Relay" prefix="Obj1" lnClass="RSYN" lnInst="1" doName="AngInd" fc="ST"/>

<FCDA ldInst="Relay" prefix="Obj1" lnClass="RSYN" lnInst="1" doName="SynPrg" fc="ST"/>

<FCDA ldInst="Relay" prefix="Obj2" lnClass="CSWI" lnInst="2" doName="Pos" fc="ST"/>

<FCDA ldInst="Relay" prefix="Obj2" lnClass="RSYN" lnInst="2" doName="Rel" fc="ST"/>

<FCDA ldInst="Relay" prefix="Obj2" lnClass="RSYN" lnInst="2" doName="AngInd" fc="ST"/>

<FCDA ldInst="Relay" prefix="Obj2" lnClass="RSYN" lnInst="2" doName="SynPrg" fc="ST"/>

<FCDA ldInst="Relay" prefix="Obj3" lnClass="CSWI" lnInst="3" doName="Pos" fc="ST"/>

<FCDA ldInst="Relay" prefix="OC1" lnClass="PTOC" lnInst="1" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="OC1" lnClass="PTOC" lnInst="1" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="OC2" lnClass="PTOC" lnInst="2" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="OC2" lnClass="PTOC" lnInst="2" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="OV1" lnClass="PTOV" lnInst="3" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="OV1" lnClass="PTOV" lnInst="3" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="OV2" lnClass="PTOV" lnInst="4" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="OV2" lnClass="PTOV" lnInst="4" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="PS1S" lnClass="GGIO" lnInst="29" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="PS1T" lnClass="GGIO" lnInst="37" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="PS2S" lnClass="GGIO" lnInst="30" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="PS2T" lnClass="GGIO" lnInst="38" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="PS3S" lnClass="GGIO" lnInst="31" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="PS3T" lnClass="GGIO" lnInst="39" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="SG1" lnClass="GGIO" lnInst="135" doName="SPCSO" fc="ST"/>

<FCDA ldInst="Relay" prefix="SG2" lnClass="GGIO" lnInst="136" doName="SPCSO" fc="ST"/>

<FCDA ldInst="Relay" prefix="U3p" lnClass="MMXU" lnInst="4" doName="PhV.phsA" fc="MX"/>

<FCDA ldInst="Relay" prefix="U3p" lnClass="MMXU" lnInst="4" doName="PhV.phsB" fc="MX"/>

<FCDA ldInst="Relay" prefix="U3p" lnClass="MMXU" lnInst="4" doName="PhV.phsC" fc="MX"/>

<FCDA ldInst="Relay" prefix="Uo1" lnClass="PTOV" lnInst="1" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="Uo1" lnClass="PTOV" lnInst="1" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="Uo2" lnClass="PTOV" lnInst="2" doName="Str" fc="ST"/>

<FCDA ldInst="Relay" prefix="Uo2" lnClass="PTOV" lnInst="2" doName="Op" fc="ST"/>

<FCDA ldInst="Relay" prefix="Uo" lnClass="MMXU" lnInst="10" doName="PhV.neut" fc="MX"/>

<FCDA ldInst="Relay" prefix="VI1" lnClass="GGIO" lnInst="137" doName="SPCSO" fc="ST"/>

<FCDA ldInst="Relay" prefix="VI2" lnClass="GGIO" lnInst="138" doName="SPCSO" fc="ST"/>

<FCDA ldInst="Relay" prefix="VI3" lnClass="GGIO" lnInst="139" doName="SPCSO" fc="ST"/>

<FCDA ldInst="Relay" prefix="VI4" lnClass="GGIO" lnInst="140" doName="SPCSO" fc="ST"/>

<FCDA ldInst="Relay" prefix="VO1" lnClass="GGIO" lnInst="97" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="VO2" lnClass="GGIO" lnInst="98" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="VO3" lnClass="GGIO" lnInst="99" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="VO4" lnClass="GGIO" lnInst="100" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="VO5" lnClass="GGIO" lnInst="101" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="VO6" lnClass="GGIO" lnInst="102" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ED01" lnClass="GGIO" lnInst="146" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ED02" lnClass="GGIO" lnInst="147" doName="Ind" fc="ST"/>

<FCDA ldInst="Relay" prefix="ED03" lnClass="GGIO" lnInst="148" doName="Ind" fc="ST"/>

69

<FCDA ldInst="Relay" prefix="ED04" lnClass="GGIO" lnInst="149" doName="Ind" fc="ST"/>

</DataSet>

<ReportControl name="brcbEV1" intgPd="0" datSet="DS1" rptID="BRCB1" confRev="1" buffered="true"

bufTime="0">

<TrgOps dchg="true" qchg="true" dupd="true" period="true"/>

<OptFields seqNum="true" timeStamp="true" reasonCode="true" dataSet="true" dataRef="true"/>

<RptEnabled/>

</ReportControl>

<ReportControl name="brcbEV2" intgPd="0" rptID="BRCB2" confRev="1" buffered="true" bufTime="0">

<TrgOps/>

<OptFields/>

<RptEnabled/>

</ReportControl>

<ReportControl name="brcbEV3" intgPd="0" rptID="BRCB3" confRev="1" buffered="true" bufTime="0">

<TrgOps/>

<OptFields/>

<RptEnabled/>

</ReportControl>

<ReportControl name="urcbEV1" intgPd="0" datSet="DS1" rptID="URCB1" confRev="1" buffered="false"

bufTime="0">

<TrgOps dchg="true" qchg="true" dupd="true" period="true"/>

<OptFields seqNum="true" timeStamp="true" reasonCode="true" dataSet="true" dataRef="true"/>

<RptEnabled/>

</ReportControl>

<ReportControl name="urcbEV2" intgPd="0" rptID="URCB2" confRev="1" buffered="false" bufTime="0">

<TrgOps/>

<OptFields/>

<RptEnabled/>

</ReportControl>

<ReportControl name="urcbEV3" intgPd="0" rptID="URCB3" confRev="1" buffered="false" bufTime="0">

<TrgOps/>

<OptFields/>

<RptEnabled/>

</ReportControl>

<DOI name="Mod">

<DAI name="ctlModel">

<Val>status-only</Val>