ceb5.cepel.br · MARCOS FONSECA MENDES Final Report Modern Automation of Hydroelectric Power Plants: Technologies, System Architectures, Required Technical Skills and Education Post-Doctoral

Modern Automation of Hydroelectric PowerPlants: Technologies, System Architectures,

Required Technical Skills and Education

(Post-Doctoral Research Final Report)

by

MARCOS FONSECA MENDES

National Research UniversityMoscow Power Engineering Institute (MPEI)

MoscowNovember - 2015

MARCOS FONSECA MENDES

Final Report

Modern Automation of Hydroelectric PowerPlants: Technologies, System Architectures,

Required Technical Skills and Education

Post-Doctoral Research accomplished at:National Research University

“Moscow Power Engineering Institute” (MPEI)Department of Electrical Power Stations

Supervisor:Prof. Ph.D. Alexey Valentinovichi Trofimov

This research was carried out with the support of:

Itaipu Binacional

Centrais Eletricas Brasileiras S.A. (Eletrobras)

National Council for Scientific and Technological Development (CNPq)

(Brazil)

MoscowNovember - 2015

Copyright c©2015 Marcos Fonseca Mendes All rights reserved.

No part of this report may be reproduced in any form or by any means withoutprior written permission of the author, except in the case of brief quotationswith appropriate attribution.

This report should be cited in the literature with the following data:

M. F. Mendes, “Modern Automation of Hydroelectric Power Plants: Tech-nologies, System Architectures, Required Technical Skills and Education”,Post-doctoral research report, National Research University - Moscow PowerEngineering Institute (MPEI), Moscow, Russia, November 2015.

For information about this research please contact:

Marcos F. Mendes

Itaipu BinacionalUsina Hidreletrica de Itaipu

Superintendencia de Engenharia - EN.DTAv. Tancredo Neves, 6731

85.866-900 - Foz do Iguacu / PR - BRAZIL

Phone: +55 (45) 3520-3650

E-mail: [email protected]

Biography

Marcos F. Mendes was born in Belo Horizonte – Brazil, where he has beganhis education: Professional Course in Industrial Informatics by FederalCenter of Technological Education of Minas Gerais - CEFET-MG (1989) andGraduation in Electrical Engineering by Federal University of Minas Ge-

rais - UFMG (1996). Then he received his Master’s in Electrical Engineering De-gree (Control, Automation and Industrial Informatics) from the Federal University ofSanta Catarina - UFSC (1999); completed a Specialization in Technical EducationTeaching at CEFET-MG (2000); and received his Doctor of Sciences Degree (Elec-trical Engineering - Power Systems) from the University of Sao Paulo - USP (2011).

Marcos F. Mendes has began his professional carrier (in 1990) working in maintenanceof hardware and development of software, during seven years. He is currently professoron the Electrical Engineering program of the Western Parana State University - Unioeste(since 2001), teaching courses in the area of Control and Automation, and senior engineerat Itaipu Binacional (since 2000), acting in several projects. He has experiences in theareas of Supervision, Control and Automation of power plants and substations.

Marcos F. Mendes is member of: Brazilian Association of Technical Standards - ABNT(CE 03:057.01 of CB-03 - Management and exchange of information associated to powersystems); International Electrotechnical Commission - IEC (WG 18 of TC 57 - Hydroelec-tric power plants - Communication for monitoring and control); and Institute of Electricaland Electronics Engineers / Power & Energy Society – IEEE / PES. He is associated tothe Study Committee B5 (Protection and Automation) of the Council on Large ElectricSystems - Cigre Brazil, and also to the Brazilian Association of Engineering Education -Abenge. He is reviewer of the IEEE Latin America Transactions.

Curriculum and production: http://lattes.cnpq.br/6557258854111396

To my dear mother, Nerea....

Acknowledgments

I am grateful to:

The Itaipu Binacional and Centrais Eletricas Brasileiras S.A. (Eletrobras)for the opportunity and support to realize this research;

The Brazilian National Council for Scientific and Technological Develop-ment (CNPq) for the financial support;

The National Research University “Moscow Power Engineering Institute”(MPEI) for the opportunity to intern in this prestigious institution;

The Prof. Sergey V. Shirinskii, Mrs. Larisa Y. Makarova and Prof.Vladimir N. Zamolodchikov for the support in the procedures and documents;

The professors Alexey V. Trofimov, Yuri P. Gusev and Gvan C. Cho foraccepting me in the department of “Electrical Power Stations”, for the assis-tance during the research and for the friendship;

The Prof. Michael G. Tyagunov and other professors of the departmentof “Non-Conventional and Renewable Energy Sources” for hosting me in thedepartment and for the pleasant coexistence;

The Prof. Sergey N. Vakurov for the excellent lessons of Russian languageand for the good conversations about Russia and Soviet Union;

The members of the Utility Communications Architecture (UCA) and ofthe Technical Committee 57 of the International Electrotechnical Commission(IEC) for creating the IEC 61850 standard, the root of this work;

Last but not least, my beloved wife, Elione, for the comprehension andencouragement. I love you!

Marcos F. Mendes,Moscow, November 2015.

AbstractThe new technologies of computing and data communication, requirements

and users’ needs have generated great changes in the electrical automationsystems. The modern ones are fully digital based on Intelligent ElectronicDevices (IEDs), Ethernet networks and IEC 61850 standard. That standardbrings great conceptual differences relative to past projects and it is becomingwidely used in the electricity sector. Its application is already a reality inelectrical substations, but it is still incipient in hydroelectric power plants.One of the main obstacles is the lack of consolidated architectures.

The main objective of this research is to create a modern architecture ofautomation systems for large hydroelectric power plants. To this effect, inves-tigations and analyses about various aspects of the systems architectures andassociated technologies and tools are carried out. New information modelsand methods (including a structured functional naming) for design and imple-mentation of automation systems are proposed. Concurrently, a constructivecritical analysis of the IEC 61850 standard is realized.

The resultant architecture comprises: diverse stand-alone IEDs associatedto the main parts of the hydro generating unit to realize a distributed au-tomation; structured and standardized data compliant with the IEC 61850standard; two levels of operation; single communication network for automa-tion of the whole power plant; another network for centralized operation; someredundancies; mechanisms for time synchronization and cyber security. Theproposed information models and methods are validated through a case study,and they have been shown to be suitable. Some modifications and extensionsof the IEC 61850 standard are suggested. The approach presented is not closeto the currently practice, but with the existing technologies the implementa-tion of the architecture is feasible using specific hardware and software.

During the examination of the aspects cited above, the necessary subjectsto deal with the modern automation systems were registered. Those infor-mation were used to define a scope of the required technical skills and drivethe education of engineers which will work in the area. Some aspects of theeducational approach and continued education also are addressed.

Keywords: Engineering education; Hydroelectric power generation; IEC61850 standard; Information models; Power plant automation; Substation au-tomation; Supervisory control; System architecture; Technological innovation.

vii

List of Acronyms

ANSI American National Standards InstituteBI Business intelligenceCDC Common Data ClassCID Configured IED DescriptionCT Current TransformeDA Data AttributeDMZ DeMilitarized ZoneDO Data ObjectEMS Energy Management SystemFBD Function Block DiagramFC Functional ConstraintFTP File Transfer ProtocolGoose Generic Object Oriented Substation EventGPS Global Positioning SystemGSE Generic Substation EventGSSE Generic Substation State EventsHGU Hydro Generating UnitHMI Human-Machine InterfaceHPP Hydroelectric Power PlantHSR High-availability Seamless RedundancyICD IED Capability DescriptionIEC International Electrotechnical CommissionIED Intelligent Electronic DeviceIEEE Institute of Electrical and Electronic EngineersIID Instantiated IED DescriptionIOU Input-Output UnitIP Internet ProtocolIPP Itaipu Power PlantIRIG Inter-Range Instrumentation GroupISA International Society of Automationviii

ISO International Standards OrganizationLAN Local Area NetworkLD Logical DeviceLN Logical NodeMMS Manufacturing Message SpecificationMPEI Moscow Power Engineering InstituteMU Merging UnitNCC Network Control CenterNERC North American Electric Reliability CouncilNTP Network Time ProtocolOSI Open Systems InterconnectionPD Physical DevicePDC Phasor Data ConcentratorPIU Process Interface UnitPLC Programmable Logic ControllerPMU Phasor Measurement UnitPRP Parallel Redundancy ProtocolPT Potential TransformerPTP Precision Time ProtocolQoS Quality of ServiceRS Recommended StandardRSTP Rapid Spanning Tree ProtocolRTU Remote Terminal UnitScada Supervisory Control and Data AcquisitionSCD Substation Configuration DescriptionSCL System Configuration description LanguageSED System Exchange DescriptionSNMP Simple Network Management ProtocolSNTP Simple Network Time ProtocolSSD System Specification DescriptionSV Sampled ValueTCP Transmission Control ProtocolUDP User Datagram ProtocolUML Unified Modeling LanguageUTC Coordinated Universal TimeVGB Technische Vereinigung der Grosskraftwerksbetreiber

ix

VLAN Virtual Local Area NetworkVPN Virtual Private NetworkVT Voltage TransformerXML Extended Mark-up Language

x

List of Figures

2.1 Itaipu power plant - powerhouse section general arrangement. . . . . . . . 112.2 Itaipu power plant - sectional view of the turbine-generator set. . . . . . . 13

3.1 Architecture of a first generation automation system. . . . . . . . . . . . . 213.2 Architecture of a first generation automation system with Scada. . . . . . . 223.3 Architecture of a second generation automation system. . . . . . . . . . . . 233.4 Architecture of a third generation automation system - centralized. . . . . 263.5 Process bus and station bus. . . . . . . . . . . . . . . . . . . . . . . . . . . 273.6 Architecture of a third generation automation system - intelligent equipment. 293.7 Architecture of a modern distribute automation system - simplified proposal. 31

4.1 Schematic diagram of the “Middle Bearings (MBear)” system. . . . . . . . 38

5.1 Structure of the solution for description. . . . . . . . . . . . . . . . . . . . 485.2 Conceptual model for description. . . . . . . . . . . . . . . . . . . . . . . . 535.3 Example of HMI object for current measuring. . . . . . . . . . . . . . . . . 57

6.1 Conceptual modelling approach. . . . . . . . . . . . . . . . . . . . . . . . . 686.2 Basic communication networks topologies. . . . . . . . . . . . . . . . . . . 706.3 Structure of the basic entities of the IEC 61850 standard. . . . . . . . . . . 776.4 Ludic nesting of the basic entities of the IEC 61850 standard. . . . . . . . 806.5 Basic conceptual class model of the ACSI. . . . . . . . . . . . . . . . . . . 816.6 Objects names and references syntaxes. . . . . . . . . . . . . . . . . . . . . 836.7 Communication and information interfaces and mappings. . . . . . . . . . 856.8 Generations and transferences of SCL files and associated tools. . . . . . . 92

7.1 Conceptual model for modelling. . . . . . . . . . . . . . . . . . . . . . . . . 1027.2 Scheme for hydroelectric power plants “PowerPlant section”. . . . . . . . . 1057.3 Proposed objects names and references syntaxes. . . . . . . . . . . . . . . . 1067.4 Alternative logical device name composition - product aspect. . . . . . . . 1107.5 Schematic diagram of the “Middle Bearings (MBear)” system with references.117

xi

8.1 Levels of the automation systems (applied to hydroelectric power plants). . 1268.2 Steady states and events of a hydro generating unit. . . . . . . . . . . . . . 1298.3 Distributed automation system model. . . . . . . . . . . . . . . . . . . . . 1378.4 Relationship between the systems and IEDs. . . . . . . . . . . . . . . . . . 1388.5 Conceptual model for automation. . . . . . . . . . . . . . . . . . . . . . . . 1448.6 Logic diagram of the “Middle Bearings (MBear)” system - signals. . . . . 1508.7 Logic diagram of the “Middle Bearings (MBear)” system - main pump. . . 1518.8 Logic diagram of the “Middle Bearings (MBear)” system - turn on pumps. 1528.9 Part of the logic in the “Motor Control Center (MCCen)” system . . . . . . 153

9.1 Conceptual physical architecture of the local control level. . . . . . . . . . 1819.2 Conceptual physical architecture of the centralized control level. . . . . . . 1879.3 Global Fault Tree of the “Middle Bearings (MBear)” system. . . . . . . . 1929.4 Zones and conduits of the proposed physical architecture. . . . . . . . . . . 195

B.1 Schematic diagram of the “Braking (Brake)” system. . . . . . . . . . . . . 246B.2 Schematic diagram of the “Hydraulic Governor (HGov)” system. . . . . . 254B.3 Schematic diagram of the “Intake Gate (IGate)” system. . . . . . . . . . . 261B.4 Schematic diagram of the “Main Transformer (MTraPhA)” system. . . . . 267B.5 Schematic diagram of the “Motor Control Center (MotContCen)” system. 275B.6 Schematic diagram of the “Purified Water (PWater)” system. . . . . . . . 281B.7 Schematic diagram of the “Raw Water (RWater)” system. . . . . . . . . . 284

xii

List of Tables

2.1 Systems of a large hydro generating unit. . . . . . . . . . . . . . . . . . . . 16

5.1 Equipment and devices of the “Middle Bearings (MBear)” system. . . . . 605.2 Names of the binary points of the “Middle Bearings (MBear)” system. . . 625.3 Names of the analog points of the “Middle Bearings (MBear)” system. . . 63

6.1 Specification of data objects for alarms, trips and indications. . . . . . . . 946.2 Specification of times settings for alarms, trips and indications. . . . . . . . 95

7.1 Lengths of (short) abbreviations of the elements for references. . . . . . . . 1087.2 Lengths of the parts of the IEC 61850 references. . . . . . . . . . . . . . . 1087.3 Subsystems of the “Middle Bearings (MBear)” system. . . . . . . . . . . . 1127.4 Logical node classes of the “Middle Bearings (MBear)” system. . . . . . . 1137.5 References of the data objects of the “Middle Bearings (MBear)” system. . 114

8.1 Automation logical node classes of the “Middle Bearings (MBear)” system. 1488.2 References of the automation of the “Middle Bearings (MBear)” system. . 149

9.1 Typical MTTF values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1919.2 Characteristics of the “Process Control Zone”. . . . . . . . . . . . . . . . . 197

A.1 Abbreviations utilized in this report. . . . . . . . . . . . . . . . . . . . . . 236

B.1 Equipment and devices of the “Braking (Brake)” system. . . . . . . . . . . 243B.2 Logical node classes of the “Braking (Brake)” system. . . . . . . . . . . . 244B.3 Subsystems of the “Braking (Brake)” system. . . . . . . . . . . . . . . . . 244B.4 References and Names of the “Braking (Brake)” system. . . . . . . . . . . 245B.5 Equipment and devices of the “Hydraulic Governor (HGov)” system. . . . 247B.6 Logical node classes of the “Hydraulic Governor (HGov)” system. . . . . . 250B.7 Subsystems of the “Hydraulic Governor (HGov)” system. . . . . . . . . . 250B.8 References and Names of the “Hydraulic Governor (HGov)” system. . . . 251B.9 Equipment and devices of the “Intake Gate (IGate)” system. . . . . . . . 255

xiii

B.10 Logical node classes of the “Intake Gate (IGate)” system. . . . . . . . . . 257B.11 Subsystems of the “Intake Gate (IGate)” system. . . . . . . . . . . . . . . 258B.12 References and Names of the “Intake Gate (IGate)” system. . . . . . . . . 259B.13 Equipment and devices of the “Main Transformer (MTraPhA)” system. . 263B.14 Logical node classes of the “Main Transformer (MTraPhA)” system. . . . 264B.15 Subsystems of the “Main Transformer (MTraPhA)” system. . . . . . . . . 264B.16 References and Names of the “Main Transformer (MTraPhA)” system. . . 265B.17 Equipment and devices of the “Motor Control Center (MotContCen)” sys-

tem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268B.18 Logical node classes of the “Motor Control Center (MotContCen)” system. 270B.19 Subsystems of the “Motor Control Center (MotContCen)” system. . . . . 271B.20 References and Names of the “Motor Control Center (MotContCen)” system.272B.21 Equipment and devices of the “Purified Water (PWater)” system. . . . . . 276B.22 Logical node classes of the “Purified Water (PWater)” system. . . . . . . . 278B.23 Subsystems of the “Purified Water (PWater)” system. . . . . . . . . . . . 278B.24 References and Names of the “Purified Water (PWater)” system. . . . . . 279B.25 Equipment and devices of the “Raw Water (RWater)” system. . . . . . . . 282B.26 Logical node classes of the “Raw Water (RWater)” system. . . . . . . . . . 282B.27 Subsystems of the “Raw Water (RWater)” system. . . . . . . . . . . . . . 283B.28 References and Names of the “Raw Water (RWater)” system. . . . . . . . 283

C.1 Specification of the GGIO LN class. . . . . . . . . . . . . . . . . . . . . . . 288C.2 Specification of the HBRG LN class. . . . . . . . . . . . . . . . . . . . . . 288C.3 Specification of the HGTE LN class. . . . . . . . . . . . . . . . . . . . . . 289C.4 Specification of the HITG LN class. . . . . . . . . . . . . . . . . . . . . . . 290C.5 Specification of the HMBR LN class. . . . . . . . . . . . . . . . . . . . . . 290C.6 Specification of the HSPD LN class. . . . . . . . . . . . . . . . . . . . . . . 291C.7 Specification of the HUNT LN class. . . . . . . . . . . . . . . . . . . . . . 292C.8 Specification of the KACP LN class. . . . . . . . . . . . . . . . . . . . . . 292C.9 Specification of the KFIL LN class. . . . . . . . . . . . . . . . . . . . . . . 293C.10 Specification of the SFLW LN class. . . . . . . . . . . . . . . . . . . . . . . 293C.11 Specification of the XCBR LN class. . . . . . . . . . . . . . . . . . . . . . 294C.12 Specification of the ICPB LN class. . . . . . . . . . . . . . . . . . . . . . . 295C.13 Specification of the KBLM LN class. . . . . . . . . . . . . . . . . . . . . . 295C.14 Specification of the KOWE LN class. . . . . . . . . . . . . . . . . . . . . . 296C.15 Specification of the KRLV LN class. . . . . . . . . . . . . . . . . . . . . . . 296C.16 Specification of the KSVV LN class. . . . . . . . . . . . . . . . . . . . . . . 297

xiv

C.17 Specification of the KTWV LN class. . . . . . . . . . . . . . . . . . . . . . 297C.18 Specification of the PLOR LN class. . . . . . . . . . . . . . . . . . . . . . . 297C.19 Specification of the RTIM LN class. . . . . . . . . . . . . . . . . . . . . . . 298C.20 Specification of the SWIO LN class. . . . . . . . . . . . . . . . . . . . . . . 298C.21 Specification of the XCON LN class. . . . . . . . . . . . . . . . . . . . . . 298C.22 Specification of the XMCB LN class. . . . . . . . . . . . . . . . . . . . . . 299C.23 Specification of the XMCU LN class. . . . . . . . . . . . . . . . . . . . . . 299C.24 Specification of the ZDCC LN class. . . . . . . . . . . . . . . . . . . . . . . 300

xv

Contents

1 Introduction 11.1 Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Justifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 General Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.2 Specific Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Organization of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Hydroelectric Power Plants and Hydro Generating Units 102.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Hydroelectric Power Plants - HPPs . . . . . . . . . . . . . . . . . . . . . . 102.3 Hydro Generating Units - HGUs . . . . . . . . . . . . . . . . . . . . . . . . 122.4 Primary and Secondary Systems . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Denomination of the Components and Structure . . . . . . . . . . . . . . . 142.6 Systems of a Hydro Generating Unit . . . . . . . . . . . . . . . . . . . . . 152.7 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Evolution of the Automation Systems and Proposal 193.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 First Generation - Conventional . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 First Generation with Scada in Parallel . . . . . . . . . . . . . . . . 203.3 Second Generation - Numeric . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Third Generation - Modern . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.1 Third Generation - Solution 1 (Present) . . . . . . . . . . . . . . . 253.4.2 Third Generation - Solution 2 (Future) . . . . . . . . . . . . . . . . 28

3.5 Evolution Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.6 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.7 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

xvi

4 Case Study 344.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 Itaipu Power Plant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Dam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.2 Generating Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.3 Control Rooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 Schematic Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4.1 Middle Bearings (MBear) . . . . . . . . . . . . . . . . . . . . . . . 364.5 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.5.1 Simplifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.5.2 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5.3 Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5.4 IEC 61850 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.6 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Description of the Generating Unit 425.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2 Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3 Identification and Modelling Standards . . . . . . . . . . . . . . . . . . . . 445.4 Structure of the Solution for Description . . . . . . . . . . . . . . . . . . . 47

5.4.1 Lowest Level - Points . . . . . . . . . . . . . . . . . . . . . . . . . . 495.4.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.4.3 Data Acquisition Granularity . . . . . . . . . . . . . . . . . . . . . 50

5.5 Proposed Conceptual Model for Description . . . . . . . . . . . . . . . . . 515.5.1 Unified Modelling Language - UML . . . . . . . . . . . . . . . . . . 515.5.2 Class Diagram for Description . . . . . . . . . . . . . . . . . . . . . 525.5.3 Model Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.5.4 Practical Application . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.6 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.6.1 Structure of the System . . . . . . . . . . . . . . . . . . . . . . . . 595.6.2 Names of the Points . . . . . . . . . . . . . . . . . . . . . . . . . . 61


6 IEC 61850 Standard and Communications 666.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.2 Communication Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

xvii

6.2.1 Networks Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 696.2.2 Switched Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.2.3 Virtual Local Area Networks - VLANs . . . . . . . . . . . . . . . . 716.2.4 Redundancy of Communications . . . . . . . . . . . . . . . . . . . . 72

6.3 Cyber Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.4 Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.4.1 Inter-Range Instrumentation Group mod B - IRIG-B . . . . . . . . 756.4.2 Network Time Protocol - NTP . . . . . . . . . . . . . . . . . . . . . 766.4.3 Precision Time Protocol - PTP . . . . . . . . . . . . . . . . . . . . 76

6.5 Basic Entities of the IEC 61850 Standard . . . . . . . . . . . . . . . . . . . 776.5.1 Groups of Logical Nodes . . . . . . . . . . . . . . . . . . . . . . . . 80

6.6 IEC 61850 Conceptual Data Model . . . . . . . . . . . . . . . . . . . . . . 806.7 IEC 61850 Objects Names and References . . . . . . . . . . . . . . . . . . 82

6.7.1 Definition of the Names . . . . . . . . . . . . . . . . . . . . . . . . 846.8 IEC 61850 Communications Services . . . . . . . . . . . . . . . . . . . . . 84

6.8.1 Generic Substation Event Model . . . . . . . . . . . . . . . . . . . . 866.8.2 Sampled Value Model . . . . . . . . . . . . . . . . . . . . . . . . . . 866.8.3 Manufacturing Message Specification - MMS . . . . . . . . . . . . . 87

6.9 IEC 61850 Configuration Language . . . . . . . . . . . . . . . . . . . . . . 876.9.1 Substation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.9.2 Product Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.9.3 Communication System Model . . . . . . . . . . . . . . . . . . . . . 886.9.4 Complete Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.10 IEC 61850 SCL Files and Tools . . . . . . . . . . . . . . . . . . . . . . . . 896.10.1 System Specification Description - SSD . . . . . . . . . . . . . . . . 896.10.2 IED Capability Description - ICD . . . . . . . . . . . . . . . . . . . 896.10.3 System Configuration Description - SCD . . . . . . . . . . . . . . . 906.10.4 Configured IED Description - CID . . . . . . . . . . . . . . . . . . 906.10.5 Other SCL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.10.6 IEC 61850 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.11 IEC 61850 Modifications Proposal . . . . . . . . . . . . . . . . . . . . . . . 926.11.1 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.11.2 Alarms, Trips and Indications . . . . . . . . . . . . . . . . . . . . . 936.11.3 Logical Node Basic Functions . . . . . . . . . . . . . . . . . . . . . 956.11.4 Modification of LN Classes . . . . . . . . . . . . . . . . . . . . . . . 966.11.5 New Logical Nodes Classes . . . . . . . . . . . . . . . . . . . . . . . 96

6.12 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97xviii

7 Modelling of the Generating Unit 997.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.2 Proposed Conceptual Model for Modelling . . . . . . . . . . . . . . . . . . 100

7.2.1 Hydroelectric Power Plants Functional Structure . . . . . . . . . . . 1007.2.2 Class Diagram for Modelling . . . . . . . . . . . . . . . . . . . . . . 1017.2.3 Hydroelectric Power Plants Scheme . . . . . . . . . . . . . . . . . . 104

7.3 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.3.1 IEC 61850 Standard References Modification . . . . . . . . . . . . . 110

7.4 Practical Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.5 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.5.1 Logical Devices and Logical Node Classes . . . . . . . . . . . . . . 1127.5.2 Logical Nodes and References . . . . . . . . . . . . . . . . . . . . . 1147.5.3 Schematic Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167.5.4 ICD file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187.5.5 Summary of the Characteristics of the Modelling . . . . . . . . . . 119


8 Generating Unit Automation 1228.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1228.2 Automation Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 1238.3 Levels of the Automation System . . . . . . . . . . . . . . . . . . . . . . . 1248.4 Control Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

8.4.1 Modes of Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278.4.2 Location of Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

8.5 Steady States of the Hydro Generating Unit . . . . . . . . . . . . . . . . . 1288.6 Automation Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

8.6.1 Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308.6.2 Alarms and Trips . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1308.6.3 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318.6.4 Starting Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318.6.5 Stopping Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328.6.6 Logical Nodes for Secondary Functions . . . . . . . . . . . . . . . . 132

8.7 Intelligent Electronics Devices . . . . . . . . . . . . . . . . . . . . . . . . . 1338.8 Standards for Programmable Controllers . . . . . . . . . . . . . . . . . . . 134

8.8.1 IEC 61131 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . 1348.8.2 IEC 61499 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . 135

8.9 Distributed Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136xix

8.9.1 Distribution of Systems in IEDs . . . . . . . . . . . . . . . . . . . . 1378.10 IEC 61850 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398.11 Logics of Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

8.11.1 Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1408.11.2 Generating Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.12 Conceptual Model for Automation . . . . . . . . . . . . . . . . . . . . . . . 1428.12.1 Automation Variables . . . . . . . . . . . . . . . . . . . . . . . . . 1438.12.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

8.13 Implementation of the Automation Logics . . . . . . . . . . . . . . . . . . 1458.13.1 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

8.14 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1488.14.1 Logical Devices and Logical Nodes . . . . . . . . . . . . . . . . . . 1488.14.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498.14.3 Logical Diagrams for Automation . . . . . . . . . . . . . . . . . . . 1498.14.4 Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155


9 Automation System Architecture 1589.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1589.2 Reliability and Safety Theory . . . . . . . . . . . . . . . . . . . . . . . . . 160

9.2.1 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619.2.2 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619.2.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629.2.4 Failure Rate and other Indexes . . . . . . . . . . . . . . . . . . . . 1629.2.5 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629.2.6 Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1639.2.7 Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 1639.2.8 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1649.2.9 Fault Tree Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

9.3 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1669.4 Intelligent Electronic Devices - IEDs . . . . . . . . . . . . . . . . . . . . . 1679.5 Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

9.5.1 Station Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . 1709.5.2 Operation Workstations . . . . . . . . . . . . . . . . . . . . . . . . 1719.5.3 Historian Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1719.5.4 Other Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1729.5.5 Redundancy of Computers . . . . . . . . . . . . . . . . . . . . . . . 173

xx

9.6 Communication Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 1739.6.1 Networks Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . 1749.6.2 Control Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1759.6.3 Operation Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

9.7 Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1769.8 Local Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

9.8.1 Process and Unit Levels . . . . . . . . . . . . . . . . . . . . . . . . 1779.8.2 Station Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1799.8.3 Redundancy of Communications . . . . . . . . . . . . . . . . . . . . 1809.8.4 Proposed Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 180

9.9 Centralized Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1849.9.1 Main Interconnections . . . . . . . . . . . . . . . . . . . . . . . . . 1849.9.2 Integration with Other Systems . . . . . . . . . . . . . . . . . . . . 1859.9.3 Proposed Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 186

9.10 Reliability Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1909.10.1 Reliability of the Case Study . . . . . . . . . . . . . . . . . . . . . . 1909.10.2 Global Unavailability . . . . . . . . . . . . . . . . . . . . . . . . . . 191

9.11 Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1939.11.1 Security Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

9.12 Critical Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1999.13 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

10 Technical Skills and Education 20410.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20410.2 Aspects of the Profession . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

10.2.1 The Engineer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20610.2.2 Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20710.2.3 Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20710.2.4 Species . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20810.2.5 Sides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

10.3 Curriculum Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20810.3.1 Initial Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 20910.3.2 Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20910.3.3 Professional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21010.3.4 Specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21210.3.5 Non-Technical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21510.3.6 Critical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

xxi

10.4 Experimental Teaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21710.4.1 Laboratory Lessons . . . . . . . . . . . . . . . . . . . . . . . . . . . 21710.4.2 Internships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

10.5 Standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21810.6 Continued Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

10.6.1 Corporate Education . . . . . . . . . . . . . . . . . . . . . . . . . . 22010.7 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

11 Conclusions and Recommendations 22311.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22311.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

11.2.1 Description and Modelling . . . . . . . . . . . . . . . . . . . . . . . 22411.2.2 IEC 61850 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . 22511.2.3 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22911.2.4 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 23011.2.5 Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23111.2.6 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

11.3 Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

A Abbreviations 236A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236A.2 Abbreviations Utilized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236A.3 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

B Case Study of Other Systems 242B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242B.2 Braking - Brake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243B.3 Hydraulic Governor - HGov . . . . . . . . . . . . . . . . . . . . . . . . . . 247B.4 Intake Gate - IGate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255B.5 Main Transformer / Phase A - MTraPhA . . . . . . . . . . . . . . . . . . . 262B.6 Motor Control Center - MotContCen . . . . . . . . . . . . . . . . . . . . . 268B.7 Purified Water - PWater . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276B.8 Raw Water - RWater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282B.9 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

C IEC 61850 Issues 286C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286C.2 Clarifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

xxii

C.2.1 Logical Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286C.2.2 Human Machine Interface - IHMI . . . . . . . . . . . . . . . . . . . 287

C.3 Pattern of Logical Nodes Classes . . . . . . . . . . . . . . . . . . . . . . . 287C.4 Modified Logical Node Classes . . . . . . . . . . . . . . . . . . . . . . . . . 287

C.4.1 Generic Process I/O - GGIO . . . . . . . . . . . . . . . . . . . . . . 287C.4.2 Generator Shaft Bearing - HBRG . . . . . . . . . . . . . . . . . . . 287C.4.3 Dam Gate - HGTE . . . . . . . . . . . . . . . . . . . . . . . . . . . 288C.4.4 Intake Gate - HITG . . . . . . . . . . . . . . . . . . . . . . . . . . 288C.4.5 Mechanical Brake for the Generator Shaft - HMBR . . . . . . . . . 289C.4.6 Speed Monitoring - HSPD . . . . . . . . . . . . . . . . . . . . . . . 289C.4.7 Hydropower Unit - HUNT . . . . . . . . . . . . . . . . . . . . . . . 289C.4.8 Air Compressor - KACP . . . . . . . . . . . . . . . . . . . . . . . . 290C.4.9 Filter - KFIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291C.4.10 Supervision of Media Flow - SFLW . . . . . . . . . . . . . . . . . . 291C.4.11 Circuit Breaker - XCBR . . . . . . . . . . . . . . . . . . . . . . . . 293C.4.12 Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

C.5 New Logical Node Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 294C.5.1 Conventional Panel Board Interface – ICPB . . . . . . . . . . . . . 295C.5.2 Braking Lifting Monkey – KBLM . . . . . . . . . . . . . . . . . . . 295C.5.3 Oil-Water Heat Exchanger – KOWE . . . . . . . . . . . . . . . . . 296C.5.4 Relief Valve – KRLV . . . . . . . . . . . . . . . . . . . . . . . . . . 296C.5.5 Solenoid Valve – KSVV . . . . . . . . . . . . . . . . . . . . . . . . 296C.5.6 Three Way Valve – KTWV . . . . . . . . . . . . . . . . . . . . . . 296C.5.7 Lockout Relay - PLOR . . . . . . . . . . . . . . . . . . . . . . . . . 296C.5.8 Timer – RTIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296C.5.9 Water in Oil Sensor - SWIO . . . . . . . . . . . . . . . . . . . . . . 297C.5.10 Contactor - XCON . . . . . . . . . . . . . . . . . . . . . . . . . . . 297C.5.11 Miniature Circuit Breaker - XMCB . . . . . . . . . . . . . . . . . . 299C.5.12 Motor Control Center Unit - XMCU . . . . . . . . . . . . . . . . . 299C.5.13 Direct Current Converter - ZDCC . . . . . . . . . . . . . . . . . . . 300C.5.14 Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

C.6 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300C.7 Other Comments and Suggestions . . . . . . . . . . . . . . . . . . . . . . . 300

C.7.1 Conceptual Class Models . . . . . . . . . . . . . . . . . . . . . . . . 300C.7.2 Technical Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300C.7.3 Missing Information . . . . . . . . . . . . . . . . . . . . . . . . . . 301

C.8 Edition 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301xxiii

C.8.1 Elementary Functions . . . . . . . . . . . . . . . . . . . . . . . . . 301C.8.2 Logical Nodes Classes for Equipment or Devices . . . . . . . . . . . 301C.8.3 Groups of Logical Nodes . . . . . . . . . . . . . . . . . . . . . . . . 302C.8.4 Groups S and T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

C.9 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

D SCL Files 306D.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306D.2 Middle Bearings System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

xxiv

Chapter 1

Introduction

“The man was born to learn, to learn as much as the life allows.”Joao Guimaraes Rosa (1908-1967)

1.1 Theme

The electricity is important to all branches of economic activities and faces a growingdemand. The Hydroelectric Power Plants (HPPs) are important uninterrupted sources ofelectricity. The Brazil is the second country with the largest installed capacity of hydro-electric power in the world. In 2013, the hydroelectricity accounted for 64% (equivalentto 391 TWh) of the Brazilian electricity matrix [1]. Therefore, the automation of HPPs[2] [3] is a topic of great relevance for the country.

The automation of HPPs are realized by “electrical automation systems”, or simply“automation systems”1. In the context of this work they are the real-time autonomoussystems responsible for the supervision, command, control and other automation func-tions (note that, electrical protection2 and advanced monitoring3 are not included). J.A. Jardini [4], C. A. V. Cardoso [5] and M. F. Mendes [6] list the basic functions andcomponents of the electrical automation systems for HPPs. A more rigorous definition,characteristics and details about electrical automation systems are presented in the nextchapters.

1In other kind of industries normally it is referred as “process control systems”. Besides, some authorsin the electricity area call the “automation system” of “control system”, when the protection functionsare not included.

2Electrical protection basically involves the detection of faults and abnormal events and then theisolation of the respective equipment to minimize equipment damages and to avoid human harms.

3Monitoring involves tracking the current state of equipment and estimating the tendencies to assessthe equipment operation. Decisions regarding operation and maintenance can be made based on thosetendencies.

Chapter 1. Introduction 2

The new technologies of computing and data communication, the new requirements forinterconnected power systems and the new users’ needs have generated large changes inthe electrical automation systems. Therefore, it is necessary to understand those changesand innovations to define the best ways to put into practice the new technologies. Thenew technologies are beginning to be applied not only in new installations, but also inmodernization of old HPPs [7] [8].

The conventional automation systems (generally concentrated, or centralized, imple-mented using electromechanical relays and traditional copper cabling) have been replacedby modern ones, using Intelligent Electronic Devices (IEDs) and communication networkswith optical fibers [9] [10]. For now, IEDs are microprocessor based automation device(a formal definition is presented in the Chapter 6 “IEC 61850 Standard and Communica-tions”). A paradigm for modern systems is the IEC 61850 “Communication networks andsystems for power utility automation” standard [11] [12], published by the InternationalElectrotechnical Commission (IEC).

The IEC 61850 standard is the result of a valuable work of standards bodies, manu-facturers and utilities for the standardization of electrical automation systems. It bringsgreat conceptual differences relative to past projects. That standard enables distributedsystems heavily based on IEDs and data communication networks. Thus, some function-ality may be performed closer to the process, this means that the intelligence is comingto the lower levels of the hierarchical architecture of the automation system. Nowadays,that arrangement is possible due to the communication and processing capacity of theinvolved devices.

The possibility of using any data of the process anywhere in the automation system(at various hierarchical levels) allows a different automation approach, with great flexibil-ity. However, the transmission of all process data through communication networks is achallenge in critical real-time systems, such as the systems for automation of HPPs (andsubstations). For achieve all necessary functions in that distributed approach, the systemarchitecture is more complex, especially for large Hydro Generating Units (HGUs).

That new approach is already a reality in electrical substations and has evolved [13] [14][15] [16], but it is still incipient in HPPs [7]. For example, an in-house survey conductedin Brazil in the last months of 2013 with five major (worldwide) manufacturers and threelarge companies of projects showed that none of them is providing full IEC 61850 compliantsystems for HPPs. On the other hand, the utilities are interested in applying the IEC61850 standard in HPPs to achieve the benefits already obtained in substations and tofollow the technological advancements.

Almost all academic works and applications done based on the IEC 61850 standardare for substations, mainly for protection systems. Initially, the scope of the standard


(released in 2004) was just electrical substations4. In 20075 it was included the partIEC 61850-7-410 “Basic communication structure - Hydroelectric power plants - Com-munication for monitoring and control” [18] relating to hydraulic power generation [19].Therefore, the IEC 61850 standard already involves HPPs for a long time, but currentlythere are still no relevant practical applications in this field. One of the main obstaclesis the lack of consolidated architectures for the automation system, besides the lack ofmethodologies for design and implementation of them.

The present research is about a new architecture of automation systems for largeHPPs based on the IEC 61850 standard6. The basic idea of the proposed architectureis introduced in the Chapter 3 “Evolution of the Automation Systems and Proposal”(at Section 3.6, illustrated on the Figure 3.7). The proposed approach is to use oneindependent IED for each part of the automation system associated to the main parts ofthe HGU. 7. Proprietary protocols are not considered. All the necessary data models andmethods are addressed.

Improvements regarding the distribution of automation functions are proposed in theresearch. The first distributed systems (not compliant with the IEC 61850 standard) hadlittle interaction among devices. This means that there was low cooperation to realize thefunctions and each physical device was limited to its own resources. Currently, the IEDscan have great interaction among then, so that parts of functions belonging to differentdevices may participate concurrently on the automation and share a lot of data.

Various technical aspects related to automation and systems architectures are ap-proached to draw conclusions and to develop a modern reference model of architecture.All developments of the research are focused on the logical and physical architectures andalso in the utilization of “information models”.

In this research, information models are created to deal with different subjects re-garding the automation system. The information models contain, beyond the data, themeaning of the data. Strictly speaking, “an information model is a representation ofconcepts, relationships, constraints, rules, and operations to specify data semantics fora chosen domain of discourse” [20]. That approach allows proposing solutions withoutgoing into details of the implementation of the automation system. Thus, the solution ismore conceptual and it can be used for diverse developments and implementations. Themain idea is to create a common framework to share the data from the specification until

4Initially the IEC 61850 standard was named “Communication networks and systems in substations”.5The second edition of the IEC 61850-7-410 extension [17] was published in 2012.6The research has considered only the published documents of the IEC 61850 standard. Possible

developments in the standard achieved during this study were not considered. The sources of informationare mainly the documents of the second edition (or edition 2.0).

7In this research those parts are called “systems”, as explained in the Chapter 5 “Description of theGenerating Unit”.


the implementation of the automation system.The research is limited to the automation of the HGUs (turbines-generators sets), other

existing automations in HPPs are not addressed or not studied into details. For example,the joint control functions8 are out of the scope of this work. The off-site control centers(from the viewpoint of the IEC 61970 “Energy management system application programinterface (EMS-API)” standard [21]) are also not addressed, but only cited. The researchis restricted to automation technologies and not to equipment technologies. Besides,the studies are restricted to the technical aspects. The managerial, administrative andfinancial aspects are not considered. The protection and monitoring functions are alsoout of the scope.

The focus of this research is the automation of the HGU. The new technologies ofelectromechanical equipment are not addressed. Evidently, those technologies should beconsidered in the new facilities and modernizations. The modern equipment can increasethe efficiency, reduce the costs and be better for the environment.

One of the concerns of the research are the data modelling related to the automationsystems. The modern systems have a huge amount of data, thus suitable data models arenecessary. It is proposed a structured design based on entity relationship models createdin this research.

Similarly to the IEC 61850 standard proposal, the models created in this researchdo not have the purpose of standardize the architecture or functions of the automationsystems, but to serve as a reference. Besides, the instances presented in this report canvary according to the application and adopted philosophy (traditions within the utility).

Defining a single architecture for modern automation systems of HPPs (specifically forHGUs) is not the intention of this work. The imposition of a unique architecture would beignoring the specifics of each installation and also the full extension of the technology. Theaim is to discuss and conclude about a lot of aspects regarding the system architectureand technologies to present as result a reference model, methods and some guidelines.That reference model does not pretend to be complete or perfect. It should be adaptedto meet the needs of each installation and the philosophies of operation and maintenanceof each utility.

During the examination of the aspects cited above, the required subjects to deal withthe modern automation systems are registered. That information is used to define ascope of the required technical skills and drive the education of professionals, specificallyengineers, which work in the area. Some aspects of the education also are addressed.

8The functions of the joint controls are used to regulate the total active power of the plant, through the“Automatic Generation Control” - or simply AGC, and to regulate the output voltage (busbar voltage) orreactive power, through the “Automatic Voltage Control” - or simply AVC. They are known as “secondaryregulations”. This research includes only the “primary regulations”.


1.2 Justifications

The IEC 61850 standard is becoming a “de facto” standard and it is being graduallyincreasingly adopted in the worldwide electricity sector, mainly in the substations. Thatis a motivation to apply the standard also in the HPPs. However, for its application inHPPs, new hardware and software are still needed, which require studies and researches.

Currently, the studies of IEC 61850 architectures for HPPs are embryonic. Thus, theresults of this research can contribute to the technological advancement in the automationof HPPs, applied in the construction of new installations or in the modernizations of theexisting ones (practice that is growing in Brazil).

Often the new automation systems are based on the past projects. To achieve the fullpotential benefits of the new technologies (including the IEC 61850 standard) changesin the traditional approach of electrical automation systems should be considered. Thetraditional existing architectures should be revised, because the modern architectures mustbe really new. The modern automation systems can have very different characteristicsand resources compared to the previous systems. The technological advances on recentdecades can provide considerable benefits. Unfortunately, some of them not too easilyobtained.

A comprehensive typical system architecture could be used as reference for utilitiesand manufacturers to realize new automation systems for HPPs. With the present post-doctoral research, it is intended to facilitate the elaboration of new automation systemsarchitectures to get best results and benefits for the operation and maintenance of HPPs.Besides, it is expected that using solutions similar to the proposed here, the utilities canhave (standardized) uniform solutions which could be provided by diverse manufacturers.It is important to note that, as the research also has an academic character, some practicalconsiderations are necessary for real implementations.

Besides all, the research also deals with the education and developments (trainings) ofengineers in the electrical automation area. That is important for the electricity industryand for advances in the area. The education in the area of electrical power systems (in-cluding automation) is getting attention lately due to the restructuring and deregulationof the energy markets, new sources of energy and the lack of specialized workforce.

1.3 Objectives

The objectives of the present post-doctoral research are defined as follows.


1.3.1 General Objective

The general objective is to elaborate a reference model of automation system archi-tecture for large HPPs (large HGUs) based on the IEC 61850 standard considering thetechnologies, distribution of functions, availability, performance, safety and security, andalso to assess the technical skills required for engineers to work with that kind of systemand the associated education.

1.3.2 Specific Objectives

To support the creation of the above cited automation system architecture for HPPs,the following specific objectives were defined:

1. to analyze the evolution of the automation systems of HPPs and their architectures;

2. to identify the diverse aspects related to HPPs automation;

3. to study some specific standards related to HPPs automation;

4. to verify the suitability of the current published edition of the IEC 61850 standardfor automation of HPPs9;

5. to define a methodology to apply the IEC 61850 standard in the design and imple-mentation of automation systems for HPPs;

6. to created conceptual models for description, modelling (including functional nam-ing) and implementation (including logics) of automation systems for HPPs;

7. to study the communication systems for modern automation of HPPs;

8. to study the availability, performance, safety and security of modern automationsystems for HPPs;

9. to realize a case study as proof of concept of the proposed methods and models;

10. to identify some of the necessary technical skills for engineers to work with modernautomation systems of HPPs.

9The intention is to verify if the models (and services) of the IEC 61850 standard are enough torepresent the primary and secondary systems of a typical large HGU, meeting the usual requirements.


1.4 Methodology

According to the general objective, this research is exploratory, since a problem cur-rently little studied is examined. Nowadays there is no knowledge of a broad and deepstudy of automation systems for HPPs based on IEC 61850 standard and, in addition,there are important issues to be clarified.

Literature surveys of similar applications in electrical substations and specific topicswere realized to provide inputs to a comprehensive analysis of the new system for HPPs.The approach of the work is a combination of qualitative and quantitative researches.

The information were obtained from secondary sources: technical documents anddrawings, books, theses, dissertations, articles (from journals and congresses), etc. Doc-uments about IEC 61850 automation of HPPs are not too common. Thus, documentsabout the IEC 61850 standard applied for automation of electrical substations have beenused. That literature review has been conducted during the first months of the research.It is distributed throughout the chapters of this report.

The technical procedure of the research was based on the case study of the Itaipu powerplant [22] [23]. Investigations of the main aspects of the automation system architecturewere done to meet the requirements of that plant, in a way to well know the subject.

Some chapters of this report provide theoretical fundamentals and developments ofmethods for the design of an electrical automation system. To make the things moreclear and to present the results of the methodology, a few chapters also include examplesof applications that are structured as a case study. Thus, the case study is distributedamong those chapters. In the present situation, it is understood that this is the best formof organization instead to include a single chapter containing the whole case study. Thescope of the case study is introduced in the Chapter 4 “Case Study”.

Due to the practical interests, this research can be classified as applied. It is expectedthat the results will be transformed into concrete actions during the modernization of theItaipu power plant and also they will serve as an aid for works in other HPPs. Therefore,the research can also be seen as a normative research, which is seeking to standardize anoptimal solution to a given problem.

The research has been carried out in the department “Electrical Power Stations” atthe “National Research University - Moscow Power Engineering Institute (MPEI)”, atMoscow, Russia. The Russian Federation has large HPPs (in 2013 it had the fifth largestworldwide hydroelectric generation installed capacity [1]) and relevant education, experi-ences and developments in the area.


1.5 Organization of the Report

The firsts chapters of the report deal with the logical architecture and them there is achapter to deal with the automation and another one about the physical architecture.

The Chapter 2 “Hydroelectric Power Plants and Hydro Generating Units” introducesthe HPPs and the HGUs. Besides are presented some concepts and definitions about thesecondary systems of HGUs and also some nomenclatures, used in the development of thework. That chapter list the diverse systems existing in a large HGU, the systems thatwill be automatized.

The Chapter 3 “Evolution of the Automation Systems and Proposal” briefly describethe historical evolution of the automation systems for HPPs (including the future ones).The description is guide by the typical architectures of different epoches. The systems arecompared with each other and a critical analysis is presented. The evolution is importantto understand the proposal and its differences relating to the other solutions.

The Chapter 4 “Case Study” introduces the case study. In fact, as already cited, thecase study is developed along many chapter of this report. The purpose of the case studyis also to present the results obtained from the application of the methods and modelsdeveloped in the specific chapters.

The following chapters present parts of the theoretical foundations and the proposedsolutions.

In the Chapter 5 “Description of the Generating Unit” it is created a conceptualmodel for description of automation systems of HPPs. That description is used as basefor the modelling. Great part of the data information foundations used in the researchare introduced in this chapter. At the end of the chapter, the description part of the casestudy is accomplished.

The Chapter 6 “IEC 61850 Standard and Communications” presents a review of somenecessary concepts and definitions of the IEC 61850 standard and about communicationsystems, including topologies, time synchronization, cyber security. Some considerationsto apply the IEC 61850 standard in HPPs, including modifications, are introduced orcited in that chapter.

In the Chapter 7 “Modelling of the Generating Unit” it is created a conceptual modelfor modelling of automation systems of HPPs. The modelling is realized according tothe IEC 61850 standard. Some new specifications (not contained in the standard) to thepurpose of HPPs modelling are developed in that chapter (and detailed in the appendix).Methods for functional naming, including a descriptive names (strings) and referencenames (mnemonic) are proposed. At the end of the chapter, the modelling part of thecase study is accomplished.


The Chapter 8 “Generating Unit Automation” deal with the automation. It presentssome concepts and definitions and also some points of standards for automation systems.After that, a conceptual model to implement the logics of automation is created. At theend of the chapter, the automation part of the case study is accomplished.

Finally, the Chapter 9 “Automation System Architecture” concludes the logical ar-chitecture and presents the proposed physical architecture for the automation system oflarge HPPs. Each aspect of the architecture is addressed and some necessary conceptsare introduced. A briefly analysis of cyber security and availability are developed. At theend of the chapter, a critical analysis of the obtained architecture is accomplished.

The Chapter 10 “Technical Skills and Education” deal with the technical skills and ed-ucation of engineers to work with modern automation systems of HPPs (and substations).The chapter is based on the concepts and developments of the previous chapters. Themain idea is to identify the main subjects necessary in the graduation (bachelor degree)programs of electrical engineering and in continued education.

The Chapter 11 “Conclusions and Recommendations” presents the conclusions of theresearch and also suggestions for future works. Besides that chapter is restricted to generalconclusions, each chapter also presents specifics concluding remarks at the end.

The report also contains the following appendixes:

• A “Abbreviations”: it contains abbreviations used in the systems, subsystems andreferences presented in the report;

• B “Case Study of Other Systems”: it contains case study parts of other systems ofthe HGU;

• C “IEC 61850 Issues”: it contains critical analyzes of the IEC 61850 standard,including suggestions of improvement (most of them applied in this research);

• D “SCL Files”: it contains the SCL files create during the research.

Chapter 2

Hydroelectric Power Plants andHydro Generating Units

“Energy and persistence conquer all things.”Benjamin Franklin (1706-1790)

2.1 Introduction

In this chapter some concepts and definitions about the HPPs and HGUs are intro-duced. Those information are used along the report.

2.2 Hydroelectric Power Plants - HPPs

A “hydroelectric power plant”1, also referred as “hydroelectric station”, is an indus-trial facility whose purpose is to generate electricity taking advantage of the hydroelectricpotential of rivers. It includes buildings, other civil works, electromechanical equipment,electronic (analog and digital) devices, diverse kinds of cables, auxiliaries systems, ancil-lary facilities.

The power generation is associated with the amount of water available and the nethead. The net head is the difference between the headwater level and the tailwater levelminus the penstock losses. The greater the fall and water flow, the greater the potentialfor the generation of electricity.

The Figure 2.12 shows a section of the main dam and powerhouse of the Itaipu powerplant, in which can be seen the water levels.

1In this report, the term “hydroelectric power plant” is represented by the abbreviation HPP.2Adapted from an internal document of the Itaipu Binacional.

Chapter 2. Hydroelectric Power Plants and Hydro Generating Units 11

Figure 2.1: Itaipu power plant - powerhouse section general arrangement.

This example of HPP utilizes Francis turbines (the runner of the turbine can be clearlyseen in the bottom of the Figure 2.2). The Francis turbines are the first radial-inflowhydraulic turbines which became widely used [24]. They have the highest efficiencies ofall kind of hydro turbines. Besides, the Francis turbines can cover a wide range of heads.

In the upper part of the main dam, at upstream, there are water inlets with protectivegrids. In the water entries there are service intake gates for emergency closing, and insome cases also there are maintenance gates (also called “stop-logs”). From the entries,the water is conveyed to the turbines by penstocks. They end in the spirals casings. Then,the water passes through the stay vanes and wicket gates (which control the water flow),and reaches the runner of the turbine, where the hydraulic power is transformed intomechanical power. After passing through the turbine, the water goes down to the drafttube and goes into the river by the tailrace, at downstream.


2.3 Hydro Generating Units - HGUs

A “hydro generating unit”3 consists of one turbine, one generator (synchronous ma-chine) and peripheral auxiliaries systems (or set of equipment). The HGU converts me-chanical power into alternating current power.

Among the systems or peripheral equipment can be cited the speed governor andthe voltage regulator (excitation system); the electrical auxiliaries: transformers, circuitbreakers, disconnectors, etc. and the mechanical auxiliaries: bearings, brakes, pumps,compressors, pipes, etc. In the Figure 2.1 can be seen the generating unit (in the blackbox). A “zoom” of this part is presented below.

The Figure 2.24 presents a cross section of the turbine-generator set of a typical HGUof the Itaipu power plant, identifying the major components. C. A. V. Cardoso [5] presentsa similar figure including details of instrumentation. Note that, the turbine (driving ma-chine) is mechanically coupled to the generator (synchronous machine) through a shaft.Thus, the turbine transfers the kinetic energy of the water to the generator, which trans-forms it into electrical energy. The bearings support and guide the turbine-generatorset.

The main parts of the generator are: stator, rotor, heat exchangers and the set ofslip rings and brushes. In the Itaipu power plant the stator windings are cooled usingdemineralized water (here called “purified water”) as cooling medium [23] [25]. Thatsolution is applied because one of the power limiting factors of the generators is themaximum temperature of operation. Thus, with this cooling system it is possible toachieved a much higher power.

The terminals at the output of the generator are connected to step-up power transform-ers (identified in the Figure 2.1). They can be single-phase or three-phase transformers,according to the rated power of the generator and other characteristics. The outputs of thepower transformers by their turn are connected to conventional or gas insulated electricalsubstations, integrated to the HPP. Those substations have the switchyard equipmentnecessary for the transmission of the electrical energy through the transmission powerlines.

The step-up power transformer of the HGU, in this research denominated “main trans-former” (some authors use the term “unit transformer”), can be referenced as a normalsubstation power transformer. It is not considered part of the HGU. Besides, there is notalways a one-to-one relationship between HGUs and those transformers.

In the HPPs also there are power sources for the auxiliaries services. Those sources3In this report, the term “hydro generating unit” is represented by the abbreviation HGU.4Adapted from an internal document of the Itaipu Binacional.


Figure 2.2: Itaipu power plant - sectional view of the turbine-generator set.

usually are a derivation of the high voltage busbars or from the terminals of the generators,which pass through step-down power transformers and voltage regulators. Besides, alwaysthere are alternative power sources for emergency situations. They can be provided bydiesel generators and/or by the power grid (dedicated transmission lines).

2.4 Primary and Secondary Systems

As mentioned above, the typical equipment of HPPs are turbines, generators, powertransformers, and so on. All those equipment, including the switching equipment of thestep-up substations, compose the “primary system”, which is the infrastructure of thepower plant. The primary system generate, transforms and dispatch the electricity. Themechanical auxiliary equipment such as pumps, compressors, main valves, etc. also arepart of the primary system.


In this research it will be considered the primary system of an existing HPP. Note that,this approach does not lose generality. In fact, a green field situation is more advantageous.

The primary system is complemented by “secondary systems” that include all devicesused to supervise, command, control, monitor and protect the HGU and the periph-eral equipment. Usually the protective functions and monitoring are considered specificapplications, therefore they are dealt separately. Remember that, the protection andmonitoring are not directly examined in this research. So, in this report, they are notincluded in the automation system, as stated in the Chapter 1 “Introduction”.

The elements of the secondary systems are instrument transformers5 (some authorsconsider that the instrument transformers belong to the primary system), other sensors,actuators, electromechanical relays, IEDs, conventional control panels, ProgrammableLogic Controllers (PLCs)6, protective relays, computers, data communication networkdevices, etc.

The functions of the secondary systems can be divided into application and systemfunctions. The “application functions” refer to supervise, command, control, protectand monitor the primary equipment and the electricity grid. The “system functions”are related to the secondary system itself, for example, to monitor the devices that arerunning applications and to provide the communications. The focus of this research arethe application functions.

The secondary systems are typically powered with direct current. Rectifiers provideelectricity for those systems and also for battery banks, which are used in case of powersupplying failure (alternating current) of the auxiliary service.

2.5 Denomination of the Components and Structure

To identify the components of the process, the following denominations are consideredin this report:

• Hydro Generating Unit: as presented in the Section 2.3, the hydro generatingunit, or simply HGU, is the turbine, generator and all associated peripherals systems(or auxiliaries systems). In the context of this research, the HGU is the plant (orprocess) to be automatized and controlled;

5Instrument transformers are devices that convert the high voltage and currents into instrumentationlevel voltages and currents: Voltage Transformers (VTs) or Potential Transformers (PTs) and CurrentTransformers (CTs). They can be “conventional” or “non-conventional” (the last one some times referredas “modern” or also “electronic”).

6In fact, in this research the PLCs are considered IEDs.


• Systems: are the well defined parts of the HGU which perform specific functions(typically at limited physical location). All systems are needed for the proper oper-ation of the HGU, including the systems that provide the auxiliary services. Thus,in this context, the turbine and the generator also are considered systems;

• Equipment: are the main compound items of the systems. Thus, in the prac-tice, the equipment are assemblies of mechanical and/or electric and/or electroniccomponents;

• Devices: are the parts associated (connected) to the equipment7. In the context ofthis research, they are components that perform some process automation function,including indications, measurements and actuations. They can be field devices asso-ciated to interfaces (inputs and outputs) and to a quite few pre-defined processing.

Note that, this nomenclature also defines a hierarchical structure, in a decreasingorder: HGU, systems, equipment and devices.

This structure is applied here to model the HGU (from the automation standpoint)using the data classes defined in the IEC 61850 standard [11]. It is made in two steps:first the process is described (in the Chapter 5 “Description of the Generating Unit”) andthem it is modelled according to the IEC 61850 standard (in the Chapter 7 “Modellingof the Generating Unit”).

The description and modelling of the process (the HGU) are very important, since theengineering of the secondary systems are based on the results of those activities.

2.6 Systems of a Hydro Generating Unit

Considering the hierarchical structure defined in the last section, the higher level insidethe HGU is the systems level. This section list the main systems of a typical large HGU.That is the first step for development of the logical architecture of the automation system.

The main equipment of large HGU do not varies from one to other installation. How-ever the way to group those equipment in systems can be different. This research proposesa definition of the systems of a HGU (according to definition of “system” introduced inthe Section 2.5) from the automation point of view.

The Table 2.1 presents the systems stated in this research for composing a large HGU.The table also presents the abbreviations8 of each system, which are used for identification

7Apart from the devices, the equipment can have other parts.8Those abbreviations were defined in this research (they are different of the ones used in the IEC

61850 standard).


(or reference) purposes along the research. The secondary systems are not presentedin the table (disregarding the regulators of speed and voltage: the “Electronic Governor(EGov)” and “Voltage Regulator (VReg)” systems, respectively).

Table 2.1: Systems of a large hydro generating unit.System Abbreviation

Braking (and Lifting) BrakeElectronic Governor (load/speed regulator) EGovExcitation (field current) ExcitGenerating Unit GenUnitGenerating Unit Bay (in the substation) GUBayGenerator GenGenerator Fire (detection and fighting) GFireHydraulic Governor (servomotor) HGovIntake Gate IGateLower Bearings (turbine / guide) LBearMain Transformer - Phase A MTraPhAMain Transformer - Phase B MTraPhBMain Transformer - Phase C MTraPhCMiddle Bearings (combined) MBearMotor Control Center MotContCenPurified Water (stator bars cooling) PWaterRaw Water (cooling) RWaterTransformer Fire (detection and fighting) TFireTurbine TurUpper Bearings (generator / guide) UBearVoltage Regulator (excitation) VReg

Note that, it was considered that the main step-up transformer of the HGU is in fact abank of three single-phase transformers (there are three systems in the table). In the caseof only one three-phase main transformer, there is only one system as: “Main Transformer(MTra)”.

The “Generating Unit Bay (GUBay)” system contains the circuit brakes of the HGUand their associated disconnectors. That system is represented here to be included inthe description, modelling and automation, but it is considered that it belongs to theautomation system of the substation (and not to the automation system of the HGU).Note that, according to the substation configuration in one bay can be connected morethan one HGU, thus the “Generating Unit Bay (GUBay)” system can be common for twoHGUs.

The “Intake Gate” system could be an “Inlet Valve” system according to the type ofturbine (here it is considered Francis).


Note that, some related parts of the HGU are divided into two systems as, for ex-ample, the “Electronic Governor” and the “Hydraulic Governor”. They could be seen asonly one system “Turbine Speed-Load Governor” containing the electronic (controller) andthe mechanical (hydraulic: servomotors, tanks, pumps, valves, etc.) parts of the turbinespeed-load governor.

Another example of division are the “Voltage Regulator” and “Excitation” systems.They also can be seen as only one system containing the electronic intelligence (thecontroller) and the controlled rectifiers (cubicle of thyristors, transformers, field circuitbreaker, and associated equipment and devices) of the generator field excitation.

For the purposes of this research, the definition of systems is flexible. For example, ifnecessary, a third system can be defined for the last example specific for the transformersand associated equipment and devices. Thus, the systems would be, for example: “VoltageRegulator”, “Bridges of Excitation” and “Transformers of Excitation”.

The consequences of the hypothetical modifications shown above as examples are vis-ible in next chapters of this report.

Some authors use different names for the same systems listed in the table. For example:sometimes the “Lower Bearings” and “Upper Bearings” are called “Turbine Bearings” and“Generator Bearings”, respectively; part of the “Hydraulic Governor” is called “High PressureOil”; the “Fire (detection and fighting)” systems (“Generator Fire (detection and fighting)”and “Transformer Fire (detection and fighting)”) are called “Fire Protection”.

In this research, the definition of systems9 is very important. All descriptions of theprocess (done in the Chapter 5 “Description of the Generating Unit”) are based on thatdefinition. Besides, it will define how the small functions that provide a “image” of theprocess are distributed (done in the Chapter 7 “Modelling of the Generating Unit”). Andthen, the results of those activities are used for the design of the automation system.

In addition to the systems listed in this chapter, the HPPs have other systems forauxiliaries services as, for example [22] [23]: lighting; communications; alternating currentsupplying; direct current supplying; emergency generators; cold water; potable water;compressed air; (other) fire detection and fighting; drainage; ventilation; air conditioning;sewer. The automation of those systems are not addressed in this research.

9That is the first approach to define the typical systems of a large HGU. After the modelling of theprocess and preliminary automation design, it can be concluded that the list should be changed (creatingnew systems or grouping or splitting some already defined systems).


2.7 Concluding Remarks

The HPPs are complex installations. They contain knowledge of diverse areas of theelectrical, mechanical, civil and computing engineerings.

The HGUs are complex dynamic systems. The intelligence to supervise, commandand control the HGUs are in the automation systems. The engineering of the automationsystems is based on the equipment of the HGU and on the requirements of operation andmaintenance. Thus, an important issue is the good knowledge of the equipment of theHGU (including the devices) and their functions.

The functional requirements are needed to define the relationships among differentparts of the automation system (defining the interfaces between the parts and also betweenthe primary and secondary systems) and the roles of each one of those parts. Those issuesare discussed along this report.

This chapter have introduced the HPPs and HGUs and created a hierarchical structurefor denomination of the components of the HGUs until the level of field devices. Besides,the systems (instances) that compose a typical large HGU, names and abbreviations forreference (which are used along the research) have been defined.

Chapter 3

Evolution of the AutomationSystems and Proposal

“Scientific knowledge is in perpetual evolution;it finds itself changed from one day to the next.”

Jean William Fritz Piaget (1896-1980)

3.1 Introduction

The electrical automation systems have evolved considerably in recent years [26] [27][28] [29]. The main reasons were the development of hardware and software technolo-gies associated with those systems and the users needs [30] [9] [6]. This developmentculminated in the IEC 61850 standard [11].

Over the years, the controlled process (the HGU) remains practically the same, withunchanged basic automation requirements [6]. The new requirements are, in general, re-garding the process information. The primary equipment were little modified, but therewas a great evolution of the secondary systems. The conventional technology, electrome-chanical, passed through the numerical (digital) technology coming to the actual modernsystems. The modern systems are fully digital with communication networks and with atendency to be based on worldwide convergent standards. The latest novelties are mainlyapplied to the process level, but also extend to the unit (bay) and station levels.

This chapter presents in brief this evolution illustrating the typical systems architec-tures. The simplified architectures of different ages are presented. To study the historicalperspective is important to understand the evolution. At the end, it is presented the ideaof the proposal for a new system architecture of modern automation systems, using thecurrent technologies. This idea is the guideline to the development of this research.

Chapter 3. Evolution of the Automation Systems and Proposal 20

As stated in the Chapter 1 “Introduction”, the protection functions are out of thescope of this research. Here it is considered that the automation system includes thedata acquisition, supervision, commands and the control functions. Thus, the protectionsystem is rough and ready represented separately in the figures presented in this chapter.

The “off-site” control level (introduced in the Section 8.3) is not represented in thefigures. It is out of the scope of the research (in spite of the fact that nowadays itsimplementation is similar to the centralized control implementation). Anyway, referencesto this level are done in some parts of this report.

The figures and the analyzes presented in this chapter are in the context of HPPs (andnot in the context of electrical substations). A few references to substation are made (tocomment about similarities and differences).

3.2 First Generation - Conventional

The first generation of automation systems for HPP (and substations), the “conven-tional”, belongs to the ancient past. It was based on electromechanical relays (discretecomponents) and parallel pairs of copper wires1 for communication.

The Figure 3.1 shows a simplified architecture of a first generation automation system.All communications (among equipment, automation devices and also with the control

rooms) are hardwired. Thus, the automation systems of this generation have a lot ofcabling. The connections are made using different types of cables and they are labor in-tensive. Besides, there other disadvantages for example: high costs, difficult maintenance,electromagnetic interferences.

The definition of each level of this figure can be seen in the Chapter 8 “GeneratingUnit Automation” (Section 8.3), but it is not so important now.

Note that, the figure does not define the panel boards. The focus is on the functionsand technologies. The panel boards are particularly ways to implement the systems.

3.2.1 First Generation with Scada in Parallel

The implementation of a Supervisory Control and Data Acquisition (Scada)2 system[31] next to a conventional automation system was a way to apply partially the technologyof the second generation (presented in the next section) in an existing first generationsystem [32].

1Sometimes the term “hardwired” is used to refer to this kind of connection.2An Energy Management System (EMS) integrated to the Scada system is possible.


Figure 3.1: Architecture of a first generation automation system.

In that case, a digital system for supervision and control is installed “in parallel” tothe conventional devices (electromechanical relays, etc.). The digital system utilizes theinfrastructure of the existing system, therefore, the new system is not autonomous. Thisis an indirectly mode to modernize the conventional system, including new supervisory,command and control functions3.

The Figure 3.2 shows a simplified architecture of a first generation automation systemwith a Scada system in parallel.

The data acquisition is preformed by Remote Terminal Units (RTUs) [31]. The au-tomation continues conventional (based on electromechanical relays), but the Scada sys-tem can supervise and send commands to the process through the Scada HMI. Note that,in this example the local HMI and the conventional central HMI were kept. The last onecan be used as a backup during fails of the Scada system.

The Scada system presented in the figure is a very simplified approach. A completeScada architecture example belonging to that generation can be seen in: [33], [34] and [32].

3In fact, the primary control functions are implemented in the conventional system.


Figure 3.2: Architecture of a first generation automation system with Scada.

The Itaipu power plant currently has that configuration (except the two last HGUs fromthe 2000 decade, identified by 9A and 18A [35], which have digital automation systemsand are connected to the Scada system through gateways, using the same protocol of theRTUs).

3.3 Second Generation - Numeric

The second generation of automation systems, the “numeric”, belongs to the recentpast (it starts on end of the 1980 decade). It is based on multifunction numeric4 (digital)devices and communications with a central controller through serial connections. Thereare a variety of communication protocols, often proprietary, for this purpose. The mul-tifunction devices and the serial communication have simplified the wiring. Besides, thecommunication interfaces become to be standardized.

4Some times that generation, here called “numeric”, is also called “digital’. However it can be confusedwith the third generation, some times also referred as “digital” (or “full digital”).


The Figure 3.3 shows a simplified architecture of a second generation automationsystem.

Figure 3.3: Architecture of a second generation automation system.

The PLC is a microprocessor based programmable control device5. It concentrate allthe logics of automation and some control functions.

The communication of this generation is based on point-to-point connections. Initiallythe communications between the PLC and the “Remote I/Os” were serial. There areseveral standards (yet available) on the market (for example the RS - RecommendedStandard - serial communications together other protocols), most of them are incompatiblewith others. Besides, as normally the serial communications have low speed, the possiblearchitectures and applications were limited. They are normally limited to master/slaveschemes. Thus, the automation systems have continued to evolve.

Some connections have evolved to data communication networks. First in the level ofthe computers (as shown in the figure) and them the communications between the PLC

5From the Chapter 6 “IEC 61850 Standard and Communications” the PLC also is called IED


and the “Remote I/Os”. Over the years the “Remote I/Os” become more intelligent, withmore processing capacity and memory, but normally those resources are not too used(generally only the data acquisition and communications care fully used).

The second generation can be subclassified according to the aspects cited above.

3.4 Third Generation - Modern

The third generation is classified in this research as “modern”6. That generation issometimes referred as “digital” (although the second generation also apply digital devices).Some authors refers to substations that use this technology as “digital substations” or“fully digital substations” [36]. So, by analogy, a power plant with this technology can becalled “fully digital power plant”.

The third generation of automation systems belongs to the present days (since the2000 decade); and to the near future. It is based on IEDs – digital devices (more compactand integrated) – and the communications are done through networks, usually usingoptical fibers. The networks also replace the cabling for the process communications.The standard Ethernet is the most used to implement the networks infrastructures andthe IEC 61850 standard is the most used to realize the communications (at least in theelectrical substations).

According to EPRI [28], “recent multifunctional IEDs provide higher performance,reduction in operating cost, reduction in size, increase in efficiency and improvement inrobustness in the existing substations”. The EPRI [28] also affirm that the IEC 61850standard presents a series of advantages. This subject is discussed in the Chapter 6 “IEC61850 Standard and Communications”.

As almost all connections in this generation are through data communication networks,the need for auxiliary relays contacts and reserve contacts is eliminated (no need engi-neering, devices, documentation, etc.). On the other hand, normally are foreseen extrainputs and outputs in the digital devices for spare purposes and future applications.

Another characteristic of the third generation is that some conventional sensors (andactuators) are replaced by non-conventional ones, with embedded intelligence. The signalsof those instruments are digital and time-synchronized using Global Positioning System(GPS) time signaling. The most prominent technology are the optical instrument trans-formers (non-conventional CTs and VTs) [37] [38] [36]. In its report [28], the EPRI

6The term “modern” has the problem of being related to a contemporary situation: what is classifiedas modern today may not be anymore in a few years. However, this term is used in the literature andthere is no one that better characterizes the technology. Therefore it is used in this report to refer toelectrical automation systems of the third generation - applying the IEC 61850 standard.


describes a series of future sensors, most of then using optical communications or opticalprinciples. It is believed that in the future the equipment will have those kind of intel-ligent sensor (and actuators) integrated so that they will be “intelligent equipment” (or“smart equipment”).

Another prominent technology for data acquisition are the Phasor Measurement Units(PMUs) [39] [40]. However, nowadays this technology has applications practically onlyin substations (wide-area protection and control on interconnected power systems). Thesynchrophasors are used together steady state power flow analysis tools.

A few applications of PMUs are specific for HPP. One example is presented by H.V. Pico et al. [41]: analysis of very low frequency oscillations in hydro-dominant powersystems. Other example of application are the state estimators (in the Scada system).Anyway, considering the characteristics of that technology (high data rates and low la-tency), certainly new applications will be developed for HPP as, for example, applicationsto assist the real time operation. The technology also can be used associated to the datafault recorders (for triggers and continuous recording).

The IEC 61850 standard together the new sensors and actuators can make great impacton the automation systems architecture. This standard allows the replacement of the oldhardwired interfaces by communication links with the intelligent sensors and actuators (orintelligent equipment). The IEC 61850 standard in fact allows innovative interconnectionsamong those new apparatus and diverse IEDs of different manufacturers.

Although the third generation of automation has some well defined concepts, as processbus and station bus (introduced below), the system architecture is not unique. The IEC61850 standard and associated reports present some architectures for substations andthere are a lot of works (presented in conferences and journals) including architectures forsubstation. Considering the HPP there are few works on this theme.

Following are presented two probable approaches of architectures for HPPs. They arebased on the IEC 61850 standard and electrical substation architectures.

3.4.1 Third Generation - Solution 1 (Present)

The Figure 3.4 shows a possible simplified architecture of a third generation automa-tion system utilizing a centralized approach.

This is the actual solution. Nowadays some vendors are working to provide solutionsbased on this architecture. Normally not a full IEC 61850 solution.

In this architecture the data of the equipment are available through Input-OutputUnits (IOUs) [42] [43] and Merging Units (MUs) [44] [45] [46] [47] [36]. The IOUs issometimes referred as Process Interface Unit (PIU) and also sometimes there are two


Figure 3.4: Architecture of a third generation automation system - centralized.

devices for separation of signals: “Process Interface Analog”, or simply PIA, and “ProcessInterface Binary”, or simply PIB.

MUs are devices for interface between the instrument transformers and the automation(and protection) system. They merge the sampled data of currents and/or voltages. Infact, the IOUs and the MUs are considered IEDs of process. Thus, the IOU functionand the MU function may be combined in only one physical device. That kind of deviceacquires and converts the signals from the primary devices of the equipment into digitaldata and transmit them in raw data packets through the process bus (introduced below).

The IOUs presented in the figure are used only for interface. They have a similarfunction of the “Remote I/Os” of the second generation (presented in the Section 3.3 atthe Figure 3.3). The difference is that now the data are exchanged using the data modelsof the IEC 61850 standard. Those IOUs (or IEDs) are dedicated hardwired devices whichhave the “Logical Nodes”7, or simply LNs, representing the equipment. Thus, the IOUsshould realize the communications mappings, besides the data acquisition. Regarding the

7The “Logical Node” concept is introduced in the Chapter 6 “IEC 61850 Standard and Communica-tions”.


old devices, a new software layer is necessary.As can be seen in the figure, the IEC 61850 standard defines two communication

networks. The “station bus” [11] [48] is the data communication network that connectsthe station level and the bay level. The “process bus” [11] [44] is the data communicationnetwork that connects the bay level and the process level.

Basically the process bus replaces hardwired connections by connections through com-munication networks. It includes the instrument transformers (VTs and CTs) that con-tinuously transmits data over the process bus and any upstream devices that wish to usethe data for protection, automation, control or monitoring can get the data, if connectedin the communication network.

Thus, according to IEC 61850 standard, the devices which interact with the primarysystem equipment are on the process bus and the devices of the operators (workstations,for example) are on the station bus. The Figure 3.5 illustrates those buses. The represen-tation shown in the figure is logical (not physical). Note that, some devices can belong toboth buses.

Figure 3.5: Process bus and station bus.

The IEC 61850 standard [48] [44] [49] has specific communication services mappingsfor transmissions of events, sampled values and other messages (that subject is presentedin the Chapter 6 “IEC 61850 Standard and Communications”), though those buses.

In the case of the electrical substations, generally the architecture is simpler. Eachbay8 has one IED for the automation (and normally another one for the protection). Inthe practice some solutions have included dedicated IEDs for inputs and outputs (theIOUs presented in the Figure 3.4) to reduce the conventional cabling [16]. That is an oldidea, already used before the IEC 61850 standard (using an input/output IED, with othername, sending the switchyard apparatus signals through optical fibers utilizing proprietary

8In some cases, there is one IED for each circuit breaker (isolators) and associated disconnectors.


protocols).For the substations the IEC 61850 standard suggest the existence of “Breaker IEDs”,

or simply BIEDs, and “Switch IEDs”, or simply SIEDs, to host the data models (morespecifically the boundary LNs9 - see the Chapter 6 “IEC 61850 Standard and Communi-cations”.) of those equipment (circuit-breakers and switch disconnectors). However, theIEC 61850 standard does not make any reference to similar IEDs for HPPs.

Note that, despite the distributed data acquisition, the processing is centralized. Theautomation is executed by only one device (two in case of redundant systems).

The IEC 61850 standard also allow an architecture without a process bus. In thiscase, all data models are in one IED (there is no IOUs). Architectures with more IEDsand hardwired communication among them also are possible. Those architectures are notshown in this report.

3.4.2 Third Generation - Solution 2 (Future)

The architecture with intelligent equipment is the future solution. To provide thatkind of solution the development of intelligent equipment are yet necessary. Some authorscall this solution of “full IEC 61850” solution.

The Figure 3.6 shows a simplified architecture of a third generation automation systemwith intelligent equipment.

Note that, this architecture is a concept based on the last architecture (Figure 3.4),which is the existing solution nowadays. Thus, it is centralized (a single IED to realize theautomation of a HGU - considering that there are not automations implemented in theintelligent equipment). Note also that, as the equipment are intelligent they can realizeother functions beyond the data acquisition.

If this architecture becomes true in the future, the only necessary connection (regardingthe automation system) are the communication network cables. In this approach theinterfaces to the process (inputs and outputs) are allocated in the equipment. The ownequipment will host the necessary data models (the boundary LNs).

Finally, in the future, maybe the gateway for connection to the centralized controllevel will not be necessary.

9As stated in the Chapter 3 “Evolution of the Automation Systems and Proposal”, LN is the acronymof “Logical Node”.


Figure 3.6: Architecture of a third generation automation system - intelligent equipment.

3.5 Evolution Analysis

All three generations can have centralized control rooms to operate the entire powerplant. However, with the advance of the computing and communication technologies,nowadays the central control has more resources and is friendlier.

With the evolution of the technologies, the standards and the software engineeringtools become more important and necessary to develop and to implement the automationsystems. The system integration is more important and, in theory, easier.

A lot of authors say that one great advantage of the IEC 61850 standard is the distri-bution of function. However, it is too rare to see a true distributed architecture. In thesubstations there are automation distributed by bays (each bay10 has an IED which con-tains all the data models of the bay). A few systems truly utilize data of other bays in thelocal logics to implement, for example, synchro-check and busbar isolation. Besides, thecontrol is apart of the protection. Certainly, the HMI is another IED. Almost all solutionspresented in the practice are strictly speaking centralized by bay. In the case of HPPsall solutions (theoretical and practical) are centralized (one controller and, normally, itsassociated remote I/O units). This research explore the distribution of functions. The

10The concept of “bay” varies. In this research it is considered that a bay is the set of circuit breakersand related to disconnectors (isolators) to connect an equipment or transmission line in a bus bar.


idea of the proposed solution is presented in the next section.Detailed critical analyses of the evolution presented here can be seen in [30] and [9].

3.6 Proposed Solution

Nowadays, a basic principle to design an automation system is the long life time [50].Therefore, the basic requirement to define the architecture is that the system must be“future proof”. To achieve this goal, the system upgradability (hardware and software),in particular of the unit and station levels which have shorter life cycles [9], is important.For this, the system must have two essential characteristics: to be standardized and open[6]. Thus, the use of the IEC 61850 standard (which has those features) is a good solution.

An outstanding feature of the IEC 61850 standard is its possibility of distributingthe automation (and protection) functions. This feature is explored here by proposinga decentralized architecture, with segregated components, using informative as well asfunctional interactions.

The decentralized architecture means that the functions are performed through thecooperation of different IEDs exchanging messages over the communication network [51][52] [53] [46]. Thus, the intelligence of the system is distributed, in other words, theautomatisms (automation logics) and interlocks can be made without one central coordi-nation device. The actual trend is that the functionalities are located (implemented) nearto the primary equipment (in the most extreme case the Logical LNs are in the equipment,as shown in the Figure 3.6 of the “future architecture”). In the beginning of the digitaltechnology in the electricity sector, this distribution was not feasible due to limitations ofthe communication channels. Now, the available technology makes it possible.

Nowadays, the devices can have great interaction with each other so that differentfunctions (implemented in different devices) can simultaneously participate of the au-tomation. This results in an overall improvement of the system performance. However,the disadvantage is that the complexity of the system design increases. This disadvantagemay be partly compensated by appropriate engineering tools, which can facilitate thedesign.

To implement the distributed architecture, the existence of the process bus is essential[54]. With this bus, there is an added bonus: feasibility to obtain longer life systems.Any change of inputs or outputs (process interface), on systems with complete processbus, requires only the creation or modification of messages and/or changes of the IEDssubscriptions. Note that, an architecture considering only the station bus does not provideall benefits of the current technology.


The Figure 3.7 shows a simplified architecture of the proposed distributed automationsystem for HPPs.

Figure 3.7: Architecture of a modern distribute automation system - simplified proposal.

As can be seen in the figure, it is proposed to use only one data communicationnetwork11, with the functions of the station bus and process bus, defined in the Section 3.4.According to the level of control, the station bus can be a “plant bus” connecting theautomation systems of all HGUs. Thus, note that, due to the distribution of functions,this communication network (and, in some cases, the time synchronization) had becomea critical resource. A solution to guarantee the high availability of this resource is theredundancy (it is not represented in the figures of this chapter, but that subject is discussedin the Section 6.2 of the Chapter 6 “IEC 61850 Standard and Communications”). Thissolution is used in the physical architecture (presented in the Chapter 9 “AutomationSystem Architecture”).

The data models of one equipment (boundary LNs) are distributed in the IED that ishardwired to this equipment. Remember that, the equipment considered are conventionaland the status and measured values of the process are represented by IEC 61850 datamodels. Besides, those IEDs perform part the automation (including interlocking and

11In fact, there is one complementary communication network in the centralized control level, as ex-plained in the Chapter 9 “Automation System Architecture”.


blocking) and not the only data acquisition as shown in the third generation (centralized)above. Also it is possible the existence of additional IEDs dedicated for the automation(not hardwired to the equipment), as represented in the figure.

A preliminar idea of a physical architecture is presented in [6]. Now, the logical ar-chitecture is developed and the physical architecture is improved, detailed and analyzedconsidering other aspects. The result is a basic reference architecture of a modern au-tomation systems for HPPs, which is the train of thought of this research. The issue“required technical skills and education” is based in the developments to the creation ofthe architecture and development of the automation.


The figures presented in this chapter show the great impact of new technologicalsolutions of communications and computing on the automation of the process. The ar-chitecture using the intelligent equipment is a future solution. Nevertheless, with theactual technology the advances can be beyond the current implemented architectures, asproposed in this research.

A completely distributed architecture is the proposal of this research. Once that theintelligent equipment are not available nowadays, this propose allows to put intelligencenear to the existing (conventional) equipment.

By the way, if it is supposed that the intelligent equipment will not perform automa-tion functions beyond the data acquisition (only provide process inputs and outputs),the future solution (Figure 3.6) can be considered similar to this research proposal (Fig-ure 3.7). An open question is which kind of equipment (beyond circuit breakers, discon-nector switches and transformers) and which level of intelligence they will have in thefuture.

The proposed architecture also allows a similar approach for centralized automation.If the IEDs presented in the Figure 3.7 only perform data acquisition (providing processinputs and outputs – the commands for the equipment), this architecture can be seen asthe centralized architecture, presented in the Section 3.4. In this case, the IEDs are theI/O devices of the Figure 3.4 (the IOUs). However, it is believed that the decentralizedarchitecture has more advantages, although it is more complex from the engineering pointof view.

As the proposed architecture can be realized with conventional equipment, it is feasibleto retrofit HPP. Several Brazilian power generating concessionaires have done or intendto modernize the automation systems of their HPP. Thus, the new solution can be widelyapplied.


The modernization of the automation systems adding computational assets create asecurity problem. Now it is necessary worry about the cyber security. When the devices ofautomation become IEDs, with characteristics and working like a computer, they inheritthe cyber security problems of the computers. That subject is addressed in the research,to assess the cyber security of the proposed architecture.

The technologies of the third generation of automation systems provides costs reduc-tions [28] [55] [56] [57] [58] [29] [36]. The costs are always important, but they are notaddressed on this research.

The modern automation systems have advantages, but they also have an additionalcomplexity related to the project. Details of the project are presented and discussed inthe next chapters.

Chapter 4

Case Study

“Knowledge is of no value unless you put it into practice.”Anton Pavlovich Chekhov (1860-1904)

4.1 Introduction

In this research a case study is presented to verify if the methodology and modelsproposed are suitable for real world applications. Besides to be a proof of concept, thecase study allows to verify if there is any problem in the proposal or if some topic can beimproved.

The case study is about the Itaipu power plant [22] [23]. In spite of being usinga specific HPP as example, the intention is to see the case study as a generic plant.The advantage of choosing the Itaipu is the fact that it is a big HPP, with large HGUsand, therefore, it has complex and complete systems. Thus, it is admitted that for anyequipment of any other hydroelectric power station there is one similar in Itaipu. Theonly restrictions are the fact that Itaipu is not a pumped storage plant (the generator donot has a motor mode of operation) and the generator does not work in the condensermode. Therefore, those functions are not considered in the case study.

4.2 Itaipu Power Plant

The Itaipu power plant started operating in 1984. In 2014 Itaipu has produced a totalof 87.8 million MWh. That year Itaipu provided around 17% of the energy consumed inBrazil and 75% of the energy consumed in Paraguay. The last record of production ofItaipu was reached in 2013, with 98,630,035 MWh.

Chapter 4. Case Study 35

4.2.1 Dam

The Itaipu dam is 7,919 m long (considering the “Hernandarias” dike) with a maximumheight of 196 meters. There are parts of concrete, rockfill and earthfill. The normal grosshead is 120 m (minimum 84 m and maximum 128 m) and the net head of project is 118.4m.

The dam has 20 water intakes of 8.23 m × 16.35 m with hydraulic actuated gates. Ineach water intake there is a penstock with internal diameter of 10.5 m and length of 142.2m, to reach the spiral casing.

On the right bank of the Itaipu dam there is a chute spillway1. It has three slopingtype troughs. The spillway maximum discharge capacity is 62.2 thousand m3/s.

4.2.2 Generating Units

The Itaipu power plant has two sectors, each one in a different frequency: 50 Hz (fre-quency of Paraguay) and 60 Hz (frequency of Brazil). In the power plant there are 20independent HGUs, 10 in each sector. As cited in the Chapter 2 “Hydroelectric PowerPlants and Hydro Generating Units”, the HGUs of Itaipu use vertical-axis Francis tur-bines. The design head is 118 m and flow rate is 645 m3/s to give rotation speed of90.9/92.3 revolutions per minute for the 50/60 Hz generators.

Each HGU has a rated active power of 700 MW. Thus, the total installed power ofItaipu is 14,000 MW. The HGUs of 50 Hz have rated power of 823.6 MVA and the HGUsof 60 Hz have rated power of 737.0 MVA.

Each HGU has a set of three single-phase transformers, each one with the rated powerof 825.0 MVA in the 50 Hz sector and of 768.0 MVA in the 60 Hz sector. The transformesstep-up 18 ± 5% kV (the rated terminal voltage of the generator) to 525.0 kV (the ratedvoltage of the gas isolated substation busbar).

4.2.3 Control Rooms

In the Itaipu power plant there are local control rooms near to the HGUs and alsoone central control room. Besides, there is an independent despatching room (to despatchthe produced energy to the Brazilian and Paraguayan electrical systems). Normally, theoperation of the HPPs is realized in that central control room. As a rule the local controlrooms are utilized only in the maintenances periods.

1The spillway function is discharging the water not used for electricity generation.


4.3 Schematic Diagrams

In this report “schematics diagrams” (also known as “piping and instrumentation dia-grams”) are used for graphical representation of the systems of the HGU (the electrome-chanical equipment and their instruments). The applications of the schematics diagramsare similar to the ones of the unifilar diagrams of the electric systems. The schematicdiagrams show the flows in the systems and their corresponding sensors and actuators.

The schematic diagrams use abstract graphic symbols rather than realistic pictures(the physical details are not important). In those diagrams, each instrument is identi-fied by a name or reference. Adicional information can be included in the diagrams, ifnecessary.

There are international standards for creation of schematic diagramas. The mostused is the ANSI/ISA-S5.1 “Instrumentation Symbols and Identification” standard [59].The identifications of the ANSI/ISA-S5.1 standard are sets of letters that represent thefunctionality and sets of numbers that indicate the control loop which the instrumentbelongs (the loops are not identified in this report).

The schematic diagrams of this report utilizes the instrumentation symbolism andidentification techniques described in the ANSI/ISA-S5.1 standard. The diagram areused to represent the modelling of the systems (Chapter 7 “Modelling of the GeneratingUnit”), including the references created in this research.

The schematic diagrams of this report are simplified. Details which are not relevant inthe scope o this research are omitted. For real implementations more detailed diagramscan be elaborated. The diagrams of real projects should have other components andformalisms.

4.4 Systems

The HGUs of the Itaipu power plant have all the systems listed in the Section 2.6. Infact, the Table 2.1 was created based on the HGUs of the Itaipu. One of those systems,which is considered as case study along the report, is presented in the next subsection:the “Middle Bearings (MBear)” system.

4.4.1 Middle Bearings (MBear)

Along the report (during the development of the methods and models of this research)are shown the studies regarding the “Middle Bearings (MBear)” system (thrust and guidebearings at the middle of the HGU) [60] [22] [23]. That system is explicitly addressed in


the Sections: 5.6, 7.5 and 8.14.The “Middle Bearings (MBear)” system was chosen because it has almost all the possible

elements considered in automation systems:

• binary outputs and inputs;

• analog outputs;

• sensors (level, pressure, temperature);

• actuators (control valves, motors);

• miscellaneous equipment (tanks, pumps, pipes);

• multiple equipment (multiple instances of the same equipment);

• different medias (water and oil);

• electrical circuits (three different).

“Bearings” are any type of mechanism that aims fixing the rotating part of the machineto its housing, without inhibiting the relative rotational movement between the rotatingpart and the static part [61].

In the case of the HGUs, the bearings are intended to support axial and/or radialforces of the HGU shaft allowing it to rotate on the contact surface of the bearings (the“pads” or “shoes”). The bearings keep the shaft centered and aligned, thus they arecritical components of the HGU.

The arrangement of bearings of the HGUs of Itaipu is “semi-umbrella” [60] [62]. Thereare a guide bearing on the top of the generator - the “Upper Bearings (UBear)”, a combinedbearing below the rotor of the generator - the “Middle Bearings (MBear)”, and a guidebearing at the turbine - the “Lower Bearings (LBear)”.

The “Middle Bearings (MBear)” system is responsible for pressurizing the lubricant oil,circulating the oil (into the bearing pads) and cooling the oil (and thus the bearings).Therefore, besides the bearings, the system involves other components as, for example:tanks, pumps, temperature sensors, level sensors, flow sensors. The automation systemsupervises and acts on those devices. The temperatures of the metal and of the lubricatingoil, the level of lubricating oil, the temperature and flow of the raw cooling water andother data are used in the automation system.

Some considerations regarding the real system of Itaipu are done. For example, itis assumed that each motor of pump has its independent contactor to start or stop thepump, installed in the drive panel board. Another example, it is considered that each


bearing pad has an independent temperature sensor installed on it (the real system hassensors only in a few pads).

The Figure 4.1 shows a simplified diagrama of the “Middle Bearings (MBear)” system.Some alarms and trips signals, selections and commands, are not presented (a completediagram is presented in the Section 7.5).

Figure 4.1: Schematic diagram of the “Middle Bearings (MBear)” system.

The symbology used in the figure is according to the ANSI/ISA-S5.1 standard [59].Note that, the instruments are not completely identified.

In the instruments, the (second) letter “T” identify the transmitters and the letter“S” identify the switches. The levels of the switches are identified by: “LL” = “toolow”; “L” = “low”; “H” = “high”; and “HH” = “too high”. The letter “M” is used toindicate “middle” or “intermediate”. The letter “A” is used for the analysis transmitters.The letter “I” identify the indicators that can be of many types (it is considered thatthey have no connections with the automation system). The other letters identify themeasured of initiating variables according to the ANSI/ISA-S5.1 standard (“F” for flow;“L” for level; “P” for pressure”; “T” for temperature).

The field mount instruments used only for local indications (readout actual measure-ments, without transmitters) are represented in dotted lines. They have no relation tothe automation system.

Some auxiliary valves and filters and other equipment were omitted. For example, thepump for oil sampling is not shown in the figure. Note that, in the figure it is not possibleto see all the bearing pads, the system has 16 thrust bearing pads and 16 guide bearingpads. Only the thrust bearing pads number 01, 04, 07, 09 and 15 and only guide bearingpads number 01, 05 and 09 have temperature sensors.


The part2 IEC 61850-7-510 “Basic communication structure - Hydroelectric powerplants - Modelling concepts and guidelines” [63] also presents an example of modelling abearing system. However, as this research proposes a new approach, the results are verydifferent. Besides, in fact, the systems are different, the bearings system presented hereis more complex then the system used as example in the part IEC 61850-7-510 of thestandard.

Nowadays there are new technologies for bearings. For example, on the market canbe found “water bearings” and “self pumping bearings”. However, the new technologiesof electromechanical equipment are out of the scope of this research. As stated in theSection 1.1, the focus of this research is the automation.

As cited above, in the systems of the HGU, defined in the Section 2.6, there are othertwo systems similar to the one chosen for the case study: “Upper Bearings (UBear)” and“Lower Bearings (LBear)”. Those two systems are simpler than the “Middle Bearings(MBear)” system. Thus, one time that the results are satisfactory for the studied case,the other two systems also should have good results.

4.5 Considerations

The descriptions and modellings of the Itaipu power plant presented in this researchare not 100% realistic, because simplifications were done (for example, using differentdevices or less devices than the real system) in some cases. On the other hand, in somecases minor improvements have been made, for exemplification and didactic approach.

4.5.1 Simplifications

The examples (case study systems) have the minimum points necessary for the au-tomation. On the other hand, in some cases were included inputs/outputs that do notexist in the HGU studied, in a way that the work presented is more complete and generic.

As stated in the Section 2.4, the system functions are not include. Thus, the pointsof supervision of the elements of the automation system (failures of IEDs, switches, com-puters, etc.) are not considered (described/modelled).

The “Local/Remote” and “Manual/Auto” conditions (and their respective switches,attributes, etc.) were not included in all the situations for simplicity, but it should beconsidered that the whole systems have those selections (and use them in the automation).

2In this report the “Technical Reports”, or simply TRs, associated to the standard also are called“parts” of the standard.


4.5.2 Automation

To conduct the case study, the automation logics used are similar to the implementedin the real system, although the new system is distributed. This means that considerableimprovements were not carried out, given that the purpose of the study is to verify themethods and that the data models are suitable to describe, modelling and implement areal automation system. This situation also allows demonstrating the flexibility of theproposed methodology. Anyway, improving the automation logics and to verifying themis very important, and it can be done in future works.

4.5.3 Documents

The schematic diagrams presented in this report are simplified. They do not have allthe equipment, devices, and so on of the real systems, thus they are illustrative diagrams.The outputs (as well as connections to destinations) of the transmitters and switches arenot shown. Some devices may have only one output and other devices several distinctoutputs for alarms and trip, for example. Some equipment and devices that are notrelevant for the automation as, for example, the auxiliary valves and the drivers for motorsare not represented in the diagrams. Note that, in a real project any relevant informationcan be included in the diagrams.

In the schematic diagrams the alarms and trips are not identified (there are onlyswitches for the levels or limits that are necessary in the automation).

The names, abbreviations, descriptions and identifications presented in this report arepreliminary, a revision is needed.

4.5.4 IEC 61850 Standard

The research proposes some modification in the IEC 61850 standard and specify newdata models. Thus, some data shown in this report are not present in the current editionof the standard (and maybe will never be in the next editions...).


The purpose of the case study is not to realize a design for a real system. The intentionis to verify if the proposed ideas of this research (methods and models) can be successfullyapplied to develop this kind of design.

To obtain a faithful representation of the Itaipu power plant, the descriptions andmodellings created in this research should be revised referencing the HGUs functional


diagrams and other as built documents. Above all, there are minor differences amongthe 20 HGUs of Itaipu. However, the important fact is that the systems described andmodelled are very close to a real large systems, with all equipment needed for large HGUs.

Along the report, some results about the “Middle Bearings (MBear)” system are pre-sented, as (typical) exemplifications. Results about other systems are presented in theAppendix B “Case Study of Other Systems”.

Chapter 5

Description of the Generating Unit

“If you can not explain it simply, you do not understand it well enough.”Albert Einstein (1879-1955)

5.1 Introduction

This chapter deal with the description of the systems of the HGU introduced in theChapter 2 “Hydroelectric Power Plants and Hydro Generating Units”. The descriptionis made considering the equipment of each system, their outputs (status and measuredvalues) and their inputs (commands and settings). The hierarchical structure (systems,equipment, devices) used for the description is introduced in the Section 2.5.

The description presented in this chapter is done disregarding the IEC 61850 standard.This approach allows an independent description (the description is not influenced by theIEC 61850 standard). In a second stage (in the Chapter 7 “Modelling of the GeneratingUnit”), the HGU is modelled according to the IEC 61850 standard using the data of thedescription.

It is possible to describe the HGU using directly the IEC 61850 standard data models.In this way, the total workload is smaller. However, one of the reasons of describing beforeis to verify (a proof of concept) if the IEC 61850 standard is able to model a real HGU(other reasons are presented along the chapter). Remember that, in this research it is alsodesired to check if the IEC 61850 standard is appropriate for large HPPs, therefore, it isimportant to describe the HGU (a free process) and then to model it (a restricted process,which depends on the IEC 61850 standard). This approach is especially important in thecase of modernizations, in which the primary system already exist.

In fact, the description proposed here also utilizes data models (created in this re-search). So, it is similar to the modelling using the data models of the IEC 61850 standard.

Chapter 5. Description of the Generating Unit 43

The difference is that in the first case the modelling is “completely” free (the utilizationof predefined data models is not mandatory, as explained along this chapter).

Thus, this chapter discusses the creation of a conceptual model for description1 of HGUfrom the automation standpoint. This model should allow the description of facilities (realphysical systems), characterizing the equipment and devices of each system. Each systemof the HGU is described relating all equipment with their respective interfaces. The resultis an appropriate high level inputs and outputs identification (complete textual names) ofthe HGU describing the meaning of them. The process values associated to those objectsprovide an image for the HGU from point of view of the automation system.

This description is very important since the automation system is designed based on it(in effect based on the model created after the description, as already said). Besides, theorganization of the data (that is a type of documentation) is a pre-step for the engineer-ing process. Lastly, a standardized HGU description is particularly important in largeprojects which different vendors may supply specific parts of the systems, facilitating theintegration.

The proposed data model was created as solution for a specific problem of this research.However, any kind of data can be added to the model for other purposes as, for example,data for assets management.

The main idea of the description approach presented in this chapter is to have apattern made by the user, without delving into the various existing standards, allowinga in house standardized description that can be used by the company and third parties.The intention is to obtain specific names whenever possible. The result (description basedon the proposed model) can be used by the power utilities for technical specifications [50][64] and it also can be used by the systems suppliers in the projects.

The idea of the users set their own patterns is not too drastic, given that some stan-dards state that any unused code may be applied for the user’s definitions. Besides, theusage of a “house standard” can be agreed between the parties or used to reach anotherlevel of standardization (an international one, for example).

To start de elaboration of the description model, the main views or “aspects” aboutdesignations are introduced in the following section.

1In this report the term “description” has a different meaning of the IEC 61850 standard definition.The term “description” of the IEC 61850 standard is referred in this report as “modelling”. Sometimesthe IEC 61850 standard also uses the term “modelling” or the expression “virtual representation” (withthe same meaning of this report).


5.2 Aspects

There are more than one approach to designate a part in an industrial plant. Thosedifferent approaches are called “aspects” or sometimes “views”, because they are waysto view the part. Another manner to understand the aspects is to imagine a (different)question which each one proposes to answer.

Those different aspects are used in diverse situations, as design, implementation, op-eration and maintenance of the systems. Thus in each situation a specific aspect canpresent advantages.

The three most important types of aspects and the questions which they propose toanswer are:

• Function: what does the object do?

• Location: where is the object located?

• Product: how is the object constructed?

Note that, considering the question, the aspect “product” could be called “construc-tion”.

According to R. G. Garcıa, E. Gelle and A. Strohmeier [65], typically, informationoriented by the three aspects cited above have to be managed simultaneously. Thus it isimportant to maintain the consistency among the aspects.

According to H. Dawidczak and H. Englert [66], “functional naming offers the user ahost of advantages in all phases of the engineering of substation automation system, fromthe invitation to bid for the project to startup and documentation”. It is considered thatthe same advantages are applied to the automation of HPPs.

The naming used in this research is the functional, because the goal is to describe(and then to model) the functions of the parts (equipment and devices) of the HGU.Discussions about that choice are presented along this chapter and on the next one.

The next section presents some standards for designations.

5.3 Identification and Modelling Standards

There are some international standards for identifications, designations and modellingof parts of an industrial plant or systems (in the context of this research: equipment anddevices). Besides, some companies create their own “house standards”. Those standards


generally associate some kind of alphanumeric codes (using letters and numbers) to iden-tify the components of the systems. The main idea is to obtain references2 that uniquelyidentify the parts. In most cases, those standards are organized in a “tree structure”,which is a structure based on breakdown levels (some of them use breakdown symbols forseparation).

As example, the following standards are available:

• IEEE C37.2-2008: standard for electrical power system device function numbers,acronyms, and contact designations [67];

• KKS: kraftwerk kennzeichnen system [68];

• RDS-PP: reference designation system for power plants3 [69];

• IEC 81346: industrial systems, installations and equipment and industrial products- structuring principles and reference designations4 [70];

• IEC 61850: communication networks and systems for power utility automation[11].

Some standards have more than one kind of representation approach. Basically thepossible approaches are regarding the part function, location or construction (productaspect), defined in the Section 5.2.

Generally more than one standard can be a solution for a specific problem of partsdesignation. Although, according to the application, one particular standard can bebetter. Besides, there are differences according to the main application purpose: fieldidentification, drawing, configuration, assets management, etc.

Some standards are based in previous standards. One interesting fact is that sometimesthe standards are compared and sometimes there are searches for “harmonization” betweenthem. For example, nowadays there are works for the harmonization between the IEC61970 standard and the IEC 61850 standard5, as can be seen in [71] [72] [73]. In thatspecific case, the scope of the standards are slightly different.

Another interesting fact is that some standards create new codes at the same timethat they maintain old codifications to be compatible with the antique applications. Notethat, this can compromise the standard effectiveness.

2In the context of this research, reference is an unique “path name” of an object also utilized as anidentifier of that object.

3The RDS-PP is a new standard which has been developed to replace the KKS.4The IEC 81346 standard replaced the IEC 61346 standard with the same name.5Presented in the Chapter 6 “IEC 61850 Standard and Communications”.


Finally, as cited above, also there are some “in-house” solutions. For example, theItaipu power plant has a pattern for coding equipment defined in the “System of Operationand Maintenance” (original in Portuguese: “Sistema de Operacao e Manutencao”) [74].There are two specific codifications, one for location and another for identification of theequipment.

The IEEE C37.2-2008 standard has a very particular purpose [67]. It utilizes de-vice function numbers (with prefixes and suffixes) to identify the functions of devicesinstalled in electrical equipment. Unlike the IEEE C37.2-2008 standard, in the case ofthe description proposed here it is not necessary to know details about the devices nei-ther differentiate devices of the same class. For example, it is not necessary to know if atemperature device is for bearings, transformers, and so on. The structure that the tem-perature sensor is inserted provides this information, i.e., there is a context in which thefunction is located. Thus, note that, in this research the devices are elementary, differentof the specific devices of the IEEE C37.2-2008 standard.

The KKS purpose is to identify plants, sections of plants and items of equipment inany type of power station according to task, type and location [68]. It has about 1,000standardized keys. The KKS replaces the long names of the elements of a system byvery short identifiers, but without semantic. Thus, the only way to know what the shortidentifier means is to know the KKS codes. The description model proposed here do notdeal with the short identifier, but only the long names in a standardized way. In theChapter 7 “Modelling of the Generating Unit” the HGU is modeled, when identifiers or“references” are used (based on the IEC 61850 standard data models, which have semanticmeaning, and on the abbreviation of the names used in the description).

In the last cited standards a system can be seen from different points of view. Thenecessity of this research is to have only one aspect: the function aspect. The ideais to build the description around the functional view of the objects that compose thesystem. This is an advantage of the proposed model, because in some cases the existenceof various view can be confuse [65]. Nevertheless, the proposed model can be extended toother aspects if necessary to deal with other applications.

The IEC 61850 standard also can be used for describing a system from the automationstandpoint. However, it is a too complex standard for the single purpose of description(the objective of this chapter). The IEC 61850 standard will be applied to model theprimary system in the Chapter 7 “Modelling of the Generating Unit”. Anyway, as citedabove, it is completely feasible to use the IEC 61850 standard to realize the description.The difference between the approaches will become more clear in the development of thiswork.


5.4 Structure of the Solution for Description

The proposed solution to describe the HGU from the automation point of view consistsof an object-oriented model, using the concepts of entities and relationships. The modelhas all the necessary classes (and attributes) for this purpose. Roughly speaking, a “class”is a specification6 (and an object is an instance of a class). The proposed conceptual modelis useful in any HPP (and also substations and other kind of industrial plants). Besides,some suggestions of extension are stated in the end of this chapter.

The purpose of the conceptual model is to provide a simple, unique, comprehensible,consistent, structured, standardized and extensible way for describing the meaning of thedata. The proposed model can be seen as a standard method of work, and the datapopulation is a kind of a “private standard” because the data used in the description isdefined by the users (companies). The users can define all the names (and abbreviations)according to their necessities and directives.

The conceptual model was created for existing primary systems, but it also can be usedto describe the new ones. The model can be seen as a structured consistent points namingstandardization. This structured description can be used as the first step to modelling7

the HGU and them to develop an automation system.The model has a simple structure (this is one of the advantages). The first level is

named according to system (for example, in the context of HPPs: brake system, bearingsystem, intake gate system, etc.), the second according to the equipment (for example:tank, pump, motor, circuit breaker, etc.) and the last level according to the devicetype (for example: temperature sensor and/or thermostat, current transformer, contactor,switch, etc.). At the end, there are the four possible types of points (from the devicestandpoint): binary output, analog output, binary input and analog input.

The Figure 5.1 shows the graphical idea of the structure in which the system is acollection of equipment. The systems of this figure are the boxes that contain conventionalequipment on the bottom of the Figure 3.7, in the Section 3.6.

Note that, the “subsystem” (and Logical Device) concept, represented in the figureby a green dashed box, is not used here. It is only necessary in the modelling phase(Chapter 7 “Modelling of the Generating Unit”).

Also note that, the proposed structure have already associated one system to one IED.Other approaches are possible, as discussed in the Chapter 3 “Evolution of the Automation

6That concept is discussed in the Section 5.5.7In fact, the description presented here is a kind of modelling, it is a conceptual model. However, in

the context of this research “modelling” means to apply the data models of the IEC 61850 standard tocreate an abstract view. The concepts related to modelling are presented in the Chapters: 6 “IEC 61850Standard and Communications” and 7 “Modelling of the Generating Unit”.


Figure 5.1: Structure of the solution for description.

Systems and Proposal”.As stated in the Section 2.5, the systems are parts of the HGU (which in its turn is

a part of the HPP). The equipment are parts of the system. The devices are parts ofthe equipment. Thus, alternatively, more generically the following terms could be used:system, component (of the system) and element (of the component: input element andactuating element). Besides, sometimes in a few companies the system is called equipment.In this case, for the context of this research the equipment would actually be a part ofthe HGU.

Note that, the equipment has other parts, but in the model are described only their de-vices which are necessary for the automation system. This means that only the interfaces(inputs and outputs) with the automation system are described.

The inputs and outputs of the devices, which are the physical points, are in the lowestlevel of the hierarchical structure. All points of the automation system are derived fromthose physical points. Thus, the model of the HGU describes only the points belongingto devices attached to the equipment. The devices belonging to the secondary systemsare not included.

As can be seen in the figure, considering the object structure, the model proposed here


is more similar to the KKS, but the last one has many levels (considering de classificationinside each one of the three main levels).

Remember that, the proposal does not (necessarily) use codes for designations of ob-jects. All elements of the structure are referenced by texts (and abbreviations). Certainly,in the implementation the objects have identifiers (primary keys), but it should be trans-parent for the users.

Finally, remembering, the model proposed in this research for description is not a“standard” in a strict point of view (as the IEC 61850 and IEC 61970 standards, forexample), because it allows the users to create a kind of classes and to instantiate objectsaccording to their necessities. Anyway, the results follow a pattern.

5.4.1 Lowest Level - Points

In the proposed data structure, the status, measured values, controls and referencesof the process are associated to devices and assigned to data points, or simply “points”(sometimes they are called “signals”8). Those points can be seen as variables of theprocess (see the Chapter 8 “Generating Unit Automation”). Thus, each point has datavalues associated to.

Considering the nature of the points, they can be binary (logical) or analog (quantity).Besides, the points can be inputs or outputs. Thus, there are four basic types of points.In this research, the definition of “output” is really an output of the device, thus it is an“input” for the secondary systems (automation system) standpoint9. This concept can beseen in the Figure 5.1.

It is considered that all the binary points of the description model are single. If thephysical device has a double point (also called “four way” point), two single points shouldbe instantiated. The treatment of those two single points to create a double point shouldbe done by the application.

Only for clarification, the analog points may be considered raw values declared as theprogramming data types “integer” or “floating point”. The engineering values (or scaledvalues) are the values obtained from the raw values after application of a scaling factorand an offset and associated to an engineering unit.

8Some authors also call them of “tags” - but it is not strictly correct.9Normally, in the automation area the “input points” are inputs of the secondary systems - data

coming from the field devices. That is not a problem, but only a nomenclature preference.


5.4.2 Application

The data structure of the conceptual model is flexible and can be utilized accordingto user needs. For example, a device “temperature sensor” can be a simple transmitteror a more complex sensor including switches. In the case of a transmitter, it gives onlythe temperature value. In the case of a complex sensor, it can give some status such as,for example, normal temperature, low temperature, high temperature, in addition to thetemperature value. Another situation is to create a “switch temperature sensor” device,or “thermostat”, which gives only one status, high temperature, for example. Thus, thereare infinite possibilities to create the devices to describe any kind of system.

Using the same example, the users do not need necessarily to differentiate a “tem-perature sensor” of a “thermostat”. According to the points associated to the device ispossible to know what it refers to.

Note that, in that description context there is no interest in the operating principleof the sensor, but only in the data they provide, because the functionalities are theconcern. Thus, the proposed description model does not have constructive characteristics(or product aspects, according to the definition in the Section 5.2). Using another example,it is not necessary to describe the kind of the pumps: centrifugal, axial, etc. Althoughin some cases it is possible to infer physical characteristics of the equipment according tothe devices that compose it10. Besides, the user can create different equipment or deviceif necessary. For example, in this report there are several kinds of control valves.

In the case study developed in this research, generally it is considered that the devicesare of the multifunction type (transmitter and switches functions, as described in the lastparagraph). However, if necessary, it is also possible to create different devices for eachfunction (transmitter or switch). It is a combination of design and users decision. Notethat, if the users want to do a product description, the created devices should reflect thereal physical system.

Once that the description is done, it is possible to understand the function of any pointwithout necessity of other documents (constructive or functional diagrams, for example).In the case of too complex systems (containing many equipment and devices, sometimesfor redundancies) a schematic diagram can facilitate understanding.

5.4.3 Data Acquisition Granularity

Basically there are two approaches to the data acquisition granularity. The first isto acquire all the data available in the devices. The second one is to acquire the data

10In this sense, anyway, for the correct description it is necessary to know the type of device, becausethat information is important to create the right structure and to define the points.


according to the automation system needs. In the last case, the contacts of the devicescan be combined in a logical approach to join the data (for example, using several contactsin serie or in parallel, realizing logical functions AND and OR, respectively).

For example, considering the “Braking (Brake)” system it is possible to have twostatus points for each braking shoe, indicating the states applied or disengaged (andalso an intermediary position) of each one. Another approach is to use only two statuspoints for all braking shoes indicating the state of the system: brakes applied or brakesdisengaged. The first status point can be obtained connecting all the limit switches (ofapplied position) in parallel and the second one can be obtained connecting all the limitswitches (of disengaged position) in serie.

Considering conventional equipment, in the first approach all signals are hardwiredto the device that realize the data acquisition (there are parallel copper wires for eachsignal that will be acquired). On the other hand, in the second approach some signals arehardwired individually and others are hardwired jointly to the data acquisition (there aresome wires in the equipment to connect the signals - in serie or parallel).

The advantage of the first approach is that the automation systems have a higherlevel of granularity of data. The advantage of the second approach is that are realized lessphysical connections and data acquisitions. Considering the actual technology, the firstapproach is better, due to the benefits for the operation and for the maintenance. So, thefirst approach is adopted in this research.

5.5 Proposed Conceptual Model for Description

The class diagram of the proposed conceptual model for description of the HGU isdeveloped in this section, after the introduction of some tools, concepts and definitions.

5.5.1 Unified Modelling Language - UML

This subsection introduces some definitions and concepts about data models and no-tations used in the development of the conceptual models of this research (in this chapterand in the Chapters: 7 “Modelling of the Generating Unit and 8 “Generating Unit Au-tomation).

The conceptual models proposed in this research have an object-oriented [75] [76]approach. They use the Unified Modelling Language (UML) [77] notation. The UMLprovides abstract modelling needed to understanding real systems.

The UML is a graphical language for visualizing, specifying, constructing and docu-menting software systems (and also non-software systems). The UML is widely applied


for object-oriented analysis and design. It is used for modelling and communicating ofsystems through diagrams and supporting texts.

One of the UML applications is the development of database schemas. Besides theconceptual aspects, the concrete aspects also can be addressed. One advantage is that itdoes not dependent on any language.

The data structure of the model is represented by a “class diagram”. That diagramgives an static overview of the system by describing the classes of the data structure andtheir relationships (relationships among the classes).

A “class” describes a set of objects that share the same attributes and operations (ormethods). The class has a name and in the diagram it is rendered as a rectangle. The“attributes” of a class are pieces of information that represent the state of an object. Inthe diagram they can be represented inside the rectangle, known as “inline attributes”,or by association with another classes (a class can have other classes as attributes).

The following concepts are applied in the class diagram:

• Association: is a relationship between instances of two classes. In UML classdiagrams the associations are represented by lines;

• Multiplicity: is the number of possible instances of a class associated with a singleinstance of the other class. It is related to each direction of each association. Themultiplicity is a single number or ranges of numbers;

• Aggregation: is an association in which one class belongs to a collection. In UMLclass diagrams the aggregation has a unfilled diamond end pointing to the partcontaining the “whole”;

• Composition: is an association which the composite object has sole responsibilityfor the the component parts. The relationship between the composite and thecomponent is “strong”. In UML class diagrams the composition is also depicted bydiamond, but a filled one;

• Generalization: it is an inheritance link indicating that one class is a “superclass”of other one. More than one generalization is possible for a single superclass. InUML class diagrams the generalization has a triangle pointing to the superclass.

5.5.2 Class Diagram for Description

The Figure 5.2 (on page 53) shows the proposed conceptual model for description,represented by a class diagram.


Figure 5.2: Conceptual model for description.


The class diagram shows only the classes and the relationships that are necessary tounderstand the conceptual model of description. Details are not included.

The possible operations are not shown in the class diagram. For example, some oper-ations of the class Equipment can be: addDevice(); removeDevice(); getDevice(); getAllDe-vices().

The class EquipmentType associated to the class Equipment identifies the type of equip-ment. The types of equipment can be, for example: circuit breaker; disconnector; filter;motor; pump; tank.

The class Qualifier associated to the class Equipment is an optional additional data.Anyway, in some cases the Qualifier is useful to make the description of the Equipmentmore clear (qualifying the equipment...). For example: air; oil; water; voltage levels.

Lastly, the class Equipment has the attribute suffix. In some situations that attributeis necessary because it is possible to have more than one identical equipment (within thesame EquipmentType and same Qualifier) in a specific System. Note that, the attributesuffix is optional. It is suggested that the suffix should be used only in actually neededsituations and it should preferably be a number (not a free string, although the modeldefine it as “string” type - in some specific cases it can be necessary...).

Some systems have multiple equipment of the same type, for example, the bearingsystems have several identical pads. Thus, the model could be designed to define acomplete type of equipment (with all its features and points) that would be replicatedseveral times to certain systems. However, as this occurs in a few cases, this increase ofcomplexity of the modelling is not justified (in this research). In the practice, to facilitate,the resource “copy and paste” can be used to populate the tables (of course that resourcedoes not replace the benefits of using templates).

In the context of this research the relationship between the class Equipment and theclass Device is a composition (instead of aggregation), because the Device does not existwithout the Equipment. The physical equipment have other parts than those devices;therefore, in the real world the equipment is not only composed of devices. Note that,the same reasoning applies to the relationship between the class System and the classEquipment.

The Device has a relationship with the class DeviceType which in its turn has a rela-tionship with the class Quantity. Thus, each instance of Device has an association to anobject DeviceType, for example: contactor; control valve; flow sensor; overcurrent relay;undervoltage relay.

The DeviceType in its turn has a Quantity, for example: angle; electric current; flow;frequency; pressure; speed. Thus, the objects of the class Quantity are the known primaryand derived quantities. The objects are around 35 and it is believed that this number


cover all possible situations in the context of the description. Lastly the class Quantityhas an association with the class ISUnit, the units of the “International System”. Notethat, it is not possible the existence of points associated to different quantities in the samedevice.

The classes System and Equipment have an attribute description, to include a briefdescription of them. Attributes like description also can be included in the classes Equip-mentType and DeviceType to explain what they are. That information is useful when thedescription is used by third parties not involved in the elaboration of the description andtherefore may have questions regarding any term. Note that, it is like to consult the“pattern of the company” used to create the description.

The class Device has the attribute modifier, which is a “string”. That attribute is acomplement to clarify the description of the devices. It is particularly useful when anyequipment has similar devices. For example, in the case of a water/oil heater exchangera temperature sensor may be necessary for the oil and another one for water. Thus, thecomplements “oil” and “water”, respectively, help to understand the function of thosedevices. Note that, in this example also may exist temperature sensors for the input andfor output (temperature of the oil/water at the input of the heater exchanger and at theoutput of the heater exchanger) and the attribute modifier solve this description problemtoo. However, when including one attribute there is a problem: the description becomemore complex. Thus, this is a user decision. If it is possible to describe all the similardevices using only the attribute instance, the attribute modifier is not necessary and shouldbe avoided.

In addition to the attributes described above, the class Device has an attribute instance.If two or more devices of the same type are present in a specific equipment, they aredistinguished by the instance number (a suffix integer value from 1 to 255). Note that,this attribute is optional. The instance is useful to describe equal devices in series orparallel or even separated. For example, several limit switches of the same type can beinstantiated.

It was chosen to use a numeric instance instead of a qualifier in the Device to increasethe uniformity. Unfortunately, this slightly reduces the level of clarity about the device.For example: selector switches “local/remote” and “manual/automatic”, etc. are clearlythan selector switches “1”, “2”, “3”, etc. However, using the data of the Status of thePointType of those devices (described below) it is possible to know their functions.

In the sequence of the main classes, the class Device is a composition of the classPoint. In the proposed model each device may performs more than one function, the onlyrestriction is that all functions should be regarding to the basic quantity of the device.Thus, if a multifunction device is considered, it has more than one point. Each instance


of the class Point is associated to one PointType.The class PointType is contained by the the class DeviceType, it is an aggregation.

Note that, the class PointType is abstract, it does not have direct instances.The PointType is a basic data of the DeviceType. It represents the possible types of

points of a specific type of device. As can be seen in the model (Figure 5.2), the instancesof the class PointType are complex data which include as attributes direction (“I” for inputor “O” for output) and type (“B” for binary or “A” for analog).

There are four specializations of the abstract class PointType: BinaryOutputPoint, Bina-ryInputPoint, AnalogOutputPoint and AnalogInputPoint. Remember that, as already citedin the Section 5.4 (and can be seen in the Figure 5.2), the points directions refer to thedevices. Thus, an “output” point is an output of the device, which means that it is asignal provided by the device to the secondary systems (automation system).

The terms “points” of the model could be denominated “signals”. The nomenclature“point” was chosen because it is widely used in the area. Besides, the term “binary” ofthe specializations is sometimes referred as “discrete” or “digital”. In the specific casehere, the term “binary” is better because in fact those outputs (BinaryOutputPoint) andinputs (BinaryInputPoint) are binary (it means that they can only assume true or falselogic statuses).

Note that, the class Point do not have an instance number, because there is no two ormore points associated to an instance of the class Device with the same Status / Action/ Measure / Setting. Remember that, in the case of redundancy there are two distinctdevices. Also note that, there is an one-to-one correspondence between the name of aPoint and the“physical point”.

Regarding the binary outputs of the devices, instead of using an attribute for thedescription and another one for a pair of messages, only one attribute has been used: therelationship with the class Status. The status in that case is associated to the true logicvalue. If the point has the opposite meaning when it is in the false logic value, the pointcan be used in the control logic through its complement (using an inverter gate NOT). Incases of double points (four way) the single points associated to each bit should be usedin the control logics, or it also can be used a calculated point (four statuses) using thosetwo bits. The last option is better due to the consistency checking.

The type of the contact (“make contact” or “break contact”) can be defined by theuser, although it is important to follow a pattern.

The analog outputs of the devices are only measured values (or supplied by basiccalculations as, for example, conversion to engineering units). Therefore, in the proposedmodel all analog outputs of the devices are “measures” (there is a relationship with theclass Measure). That is the rule for conventional sensors. For intelligent sensors, the


outputs may be different, for example, the approach of sampled values (sampled values ofa process quantity) defined in some standards.

The class which has the largest population is the Status. The others classes (Action,Measure and Setting) contain not many objects, particularly the class Measure, which doesnot reach a half dozen of objects.

Each instance of the class Point can be associated to many instances of the classPhysicalValue. A PhysicalValue has an attribute timeStamp and an attribute quality. ThetimeStamp attribute is the Universal Time Coordinated (UTC) time of the last change inthe value (the time stamp). The quality attribute is used to indicate the quality of the point(accuracy and validity), for example, if the data is “good”, “invalid” or “questionable”.

Only for illustation, the Figure 5.3 presents an example of indication of a variable(the field current) in a HMI display showing the quality of the data (as an data attributecolor). Note that, the example is an efficient way to present various information to theuser. The displays of the HMIs must show everything that the operators need to know.

Figure 5.3: Example of HMI object for current measuring.

The class PhysicalValue has two specializations, the classes BinaryValue and Analog-Value. The last ones have their associated values. Here the analog value is representeby a type of data “float”, but other kind of analog data type can be used (and otherspecializations can be created).

5.5.3 Model Extensions

Note that the description model do not include the HGU (the Figure 5.2 does notinclude, for example, a class GeneratingUnit). It would be a level up the class System.There is no reference to the HGU because de model is for a single HGU and also it issupposed that all the HGUs of the HPP are equal (or similar). Anyway, if the users wishrepresenting the HGU, it is just necessary to include a composition with a new containing


class and the contained class System (in fact, this is done in the Chapter 7 “Modelling ofthe Generating Unit”).

If the HPP has multiple HGUs which have little difference among them, the ideal isto model a “typical” HGU with all existing points (contemplating the possible differencesamong distinct units). On the HGUs which do not have all those points, they simply arenot used. Additionally, an attribute, for example, implemented can be created as extensionto indicate the points that are really used. If the differences among HGUs are too large,it is better to separate typical models for each type of HGU.

In a similar way, if necessary, a top class, for example PowerPlant, can be created asthe first level of the overall structure. As each object of this class would be only a name(and some few additional attributes), the class PowerPlant also was not included in theFigure 5.2. In a simplistic way, to complete de structure of any object of the proposeddescription model it is only necessary one identifier for the HPP and one identifier for theHGU.

The model can have other extensions. For example, in the class Point can be includeattributes for the “normal condition”, “alarm settings” (levels, classes, etc.), “trips set-tings”, etc. Another option is to create classes and relationships for those purposes, forexample, the classes Alarm and Trip can be added to the model. Attributes to defineand to characterize points of “latch type” and “pulse type” also can be included in thedescription model.

More data can be aggregated in the model to generate information and to be usedin other applications. For example, an attribute can be created to indicate which pointsshould be sent to (different levels of) control centers. Besides, in this specific case, de datacan be used to configure gateways and proxies. Finally, the data can be utilized to createall the necessary lists: status, measures, alarms (with classes and priorities), trips andalso points that go into the historian databases, etc. There are an infinitude of possibleextensions.

5.5.4 Practical Application

In the application of the conceptual model, each physical point (inputs and outputs)are defined following the structure: system, equipment and device. Some examples wereshown above to introduce the conceptual model.

The description includes only the binary outputs of the devices that are physicallyassociated to status, alarms and protections. The binary points derived from analogprocess signals (limit signals) or derived from signal conditioning are not represented inthe conceptual model for description, because they are points of the application. Besides,


the analog points also are include in the description.As mentioned above, the devices are elementary. For example, in the description of

CTs it is only indicated that the measurement value is “raw” (needing to convert it to anengineering unit). The transformer ratio and the correction factors are of no interest (inthe description). In that case, it is not described if the CT is an 1 A or 5 A type, nor thenominal current value of the primary winding, for example. If the application requiresthe description of those details, they can be included in the class DeviceType, as stated inthe last subsection.

In fact, depending on the application of the description (in this research case: func-tion), it is not even necessary to indicate the type of measure. It is considered wheneverthat it is a measured value, the nature of the measurement has interest only for imple-mentation (and for the application).

The description model can also be used to map inputs and outputs of devices suchas Remote Terminal Units (RTUs), for example, once typically numbers are used (forexample: RTU 10 - Rack 07 - Card 07 - Input 08). To that end, each equipment and/ordevice should be assigned to a RTU and a software can associate the inputs/outputsautomatically.

5.6 Case Study

In this section it is verified if the proposed conceptual model for description is suitableto solve the problem discussed in this research. The chosen system is the lubricatingand cooling system of the “middle bearings” - the “Middle Bearings (MBear)” system,introduced in the Section 4.4 of the Chapter 4 “Case Study”.

5.6.1 Structure of the System

Considering the proposed structure of the systems (see Section 5.4), the “Middle Bear-ings (MBear)” system has the equipment and devices listed in the Table 5.1 (on page60).

The Table 5.1 is equivalent to the box “System i” of the Figure 5.1, with its equipmentand devices. The inputs and outputs, described in the next subsection, are associated tothose devices.

Note that, not all bearing pads are presented in the table (but only the pads 01, 02and 16, as examples).

Here the “pipes” are considered equipment. Thus, devices (such as valves, flow sensors,pressure sensors, etc.) can be associated to them. Similarly, the “electrical circuits” are


Table 5.1: Equipment and devices of the “Middle Bearings (MBear)” system.

Equipment Devices125Vdc Circuit Under Voltage Relay125Vdc Circuit 1 DC Mini CB125Vdc Circuit 2 DC Mini CB

460Vac Circuit 2

AC InterrupterFuseThermal Overload RelayUnder Voltage Relay

Guide Bearing Pad 01 Temperature Sensor (switch)Temperature Sensor (transmitter)


... ...


Oil Pipe Pressure Sensor (switch)Oil Pump 1 Contactor AuxiliarOil Pump 2 Contactor Auxiliar

Oil Tank

Level Sensor (switch)Level Sensor (transmitter)Temperature Sensor (switch)Temperature Sensor (transmitter)Water in Oil Detector

Panel IHM

Button 1 (Turn On)Button 2 (Turn Off)Selector Switch 1 (Remote)Selector Switch 2 (Pump One)

Thrust Bearing Pad 01 Temperature Sensor (switch)Temperature Sensor (transmitter)


... ...


Water Pipe Flow Sensor (switch)Flow Sensor (transmitter)

considered equipment. Thus, devices (such as circuit breakers, fuses, relays, etc.) can beassociated to them (see the comment in the Section 7.2).

Also note that, the transmitters and switches are differentiated in the table.It was defined a “virtual” equipment, the 125Vdc Circuit. It was necessary because


the real system has only one under voltage relay for both direct current power sources(125Vdc Circuit 1 and 125Vdc Circuit 2). That solution shows the flexibility of the modelfor description. Other approaches are possible.

As stated in this chapter, the names are completely configurable. For example, if theuser want do create a new equipment “Sump”, instead to use the generic one “Tank”,he/she can do it. The result would be: “Oil Sump”.

The motor power sources are distinct (for high reliability, because it is a very criticalfunction). The first comes from the “Motor Control Center (MotContCen)” system11 (thereis a specific control unit in the panel board for that function) and the second comesfrom a source of the auxiliary service through a panel board of the “Middle Bearings(MBear)” system. Thus, they have different devices (and distinct commands). In the casepresented here, to explore the model, there are some differences from the real system. Forexample, it was considered that the fuses have supervision.

5.6.2 Names of the Points

Considering the proposed data model of the systems (see Section 5.5), the “MiddleBearings (MBear)” system has the points (inputs and outputs associated to the deviceslisted in the Table 5.1) shown in the Tables 5.2 (on page 62) and 5.3 (on page 63) - binaryand analog, respectively.

The naming was created according to the conceptual data model using the namesdefined by the author. Remember that, as emphasized in this chapter, the standardizationof the names is very important. Thus, the naming requires special attention in the firstdesign. After the first application the names can be reutilized.

The Table 5.2 presents the binary outputs (statuses, alarms and trips) and the binaryinputs (commands) of the devices.

Note that, the names of the points are complete in a way that pair of messages foreach point are not necessary (the logical statuses true mean exactly what the point namesstate). Remember the particular case of the two way points described in the Section 5.5.

Also note that, the Table 5.2 includes the indications of alarms and trips (there aredifferent types of trips, not specified in the table. They are associated, for example, todifferent thrust bearing temperatures). Those columns were included only to show anexample of extension of the description model.

Physical switches (installed in the equipment front panel board) were chosen for theselection of the location of control (“Panel HMI Selector Switch 1 (Remote)”) and for

11The data associated with the points of the “Motor Control Center (MotContCen)” system can be seenin the Appendix B “Case Study of Other Systems” at Section B.6.


Table 5.2: Names of the binary points of the “Middle Bearings (MBear)” system.

Point name Alarm Trip125Vdc Circuit 1 DC Mini CB Opened X125Vdc Circuit 2 DC Mini CB Opened X125Vdc Circuit Under Voltage Relay Operated X460Vac Circuit 2 AC Interrupter Closed460Vac Circuit 2 AC Interrupter Magnetic Actuated X460Vac Circuit 2 Fuse Blown X460Vac Circuit 2 Thermal Overload Relay Operated X460Vac Circuit 2 Under Voltage Relay Operated XGuide Bearing Pad 01 Temperature High XGuide Bearing Pad 01 Temperature Too High XGuide Bearing Pad 02 Temperature High XGuide Bearing Pad 02 Temperature Too High X

... ... ...Guide Bearing Pad 16 Temperature High XGuide Bearing Pad 16 Temperature Too High XOil Pipe Pressure NormalOil Pump 1 Turn OnOil Pump 1 Turned OnOil Pump 2 Turn OnOil Pump 2 Turned OnOil Tank Level Too High XOil Tank Level Too Low XOil Tank Temperature High XOil Tank Temperature Too High XOil Tank Water in Oil Detector Operated XPanel IHM Button 1 Turn OnPanel IHM Button 2 Turn OffPanel IHM Selector Switch 1 RemotePanel IHM Selector Switch 2 Pump OneThrust Bearing Pad 01 Temperature High XThrust Bearing Pad 01 Temperature Too High XThrust Bearing Pad 02 Temperature High XThrust Bearing Pad 02 Temperature Too High X

... ... ...Thrust Bearing Pad 16 Temperature High XThrust Bearing Pad 16 Temperature Too High XWater Pipe Flow Low XWater Pipe Flow Too Low X

selection of the main pump (“Panel HMI Selector Switch 2 (Pump One)”). For sure, alsoit is possible to use “virtual switches” (software) or both. In those cases, the modeling is


similar.The Table 5.3 presents the analog outputs (measures) of the devices. Note that, in

this specific case there are no analog inputs (settings).

Table 5.3: Names of the analog points of the “Middle Bearings (MBear)” system.

Point nameGuide Bearing Pad 01 TemperatureGuide Bearing Pad 02 Temperature

...Guide Bearing Pad 16 TemperatureOil Tank LevelOil Tank TemperatureThrust Bearing Pad 01 TemperatureThrust Bearing Pad 02 Temperature

...Thrust Bearing Pad 16 TemperatureWater Pipe Flow

Note that, the two tables above do not present all the bearing pads (only the padsnumbers 01, 02 and 16 are presented; the others are identical). It was considered that allbearing pads have sensors (different of the real system, which is simpler, as described inthe Section 4.4).

As exemplified above, the names are completely configurable. Following the citedexample (use “Sump” instead of “Tank”), the results would be: “Oil Sump Level” and “OilSump Temperature”.

The HPP identification, for example “ITA” (for “Itaipu” power plant), the HGU iden-tification, for example “U01” (for “Unit 01”), and the identification of the system, in thiscase “Middle Bearings”, are not included in the names of the points in the two tablesabove (for simplicity). For example, the complete name of the points associated to the“Guide Bearing Pad 01” of each table (5.2 and 5.3) including those identifications are:

Binary: ITA - U01 - MBear - Guide Bearing Pad 01 Temperature Too High

Analog: ITA - U01 - MBear - Guide Bearing Pad 01 Temperature

Also is possible to use the names instead of the identifiers (abbreviations), or yet acombination of abbreviations and names, for example:

Binary: Itaipu - Unit 01 - Middle Bearings - Guide Bearing Pad 01 Temperature Too High


Analog: Itaipu - Unit 01 - Middle Bearings - Guide Bearing Pad 01 Temperature

Note that, the names constructions above exemplified can be utilized as Human Ma-chine Interface (HMI) names.


This chapter presents a standardized methodology for describing the HGU from theautomation standpoint including a proposition of a new conceptual data model.

The conceptual model created in this chapter has all classes and attributes necessaryfor the description proposed in the research. Besides, as the model is object-oriented,all additional data required for other applications can be easily added (new attributesand/or classes). Nevertheless, the classes and their relationships introduced here are thebase of the model and should be maintained. In fact, an extension is done in the stage ofmodelling, described in the Chapter 7 “Modelling of the Generating Unit”. In addition, adescription created using the proposed model can be interpreted by software applicationswith appropriated methodology and dictionaries.

The proposed conceptual model does not guarantee that the description will be entirelystandardized. During the population of classes (actually tables) the standardization ofnames should be kept in mind. For example, a user could create a qualifier and anotheruser creates another qualifier synonym of the first. This situation causes the loss ofpattern of names. The implementation of the model can provide computational resourcesto minimize this kind of problem. For example, artificial intelligence techniques can beused to avoid patternless. A key advice is to do a good population of the tables associatedto the classes EquipmentType, DeviceType and PointType (including the classes Status,Measure, Action and Setting). Those are the most important tables to define a pattern.

Using the description model the users do not need think about the codes conventions,because the description is done in a natural language. The users can define their own datapatterns and also can use the existing traditional naming methods of their companies. Thisis a way to permit any automation expert which does not know a specific standard (theIEC 61850 standard, for example) to make a base for a modelling and also to facilitatethe work. Another advantage of the proposed standardized description is the possibilityto reuse the data. That procedure can reduce times and costs of engineering.

In the practice, maybe there are situations in which it is not possible to describe aspecific point with the same nomenclature used by the company. However, generally thatpoint can be described in an alternative manner. Thus, it is necessary understanding ofall the people involved in the process to accept the (rare) situations that may occur.


The proposed granularity of the data acquisition is high. All the signals necessary tothe automation system are acquired individually (thus, they also are described individu-ally). Nowadays, the values of any kind of process variables are very valuable data. Thosedada can be transformed in important information.

For implementation purposes more data should be aggregated to the description. Forexample, the data types should be detailed; the diverse types of commands should bespecified; the constructive aspects should be specified; etc. Some of those data belongs tothe executive design stage (not included in this research).

The system description could be performed directly using the IEC 61850 standard.One of the problems of that approach is that some equipment or device (or point, in theIEC 61850 standard jargon: “data objects” and “data attributes”12) maybe is not defined,or properly defined, in the standard. Note that, in the context of an academic research,one goal is to verify if the IEC 61850 standard is adequate for HPPs. In the future, whenthe IEC 61850 standard become consolidated for HPPs, the direct application of thatstandard may be the best choice.

Anyway, as the description created in this chapter is function oriented, it is correlatedto the IEC 61850 standard data models, which also is function oriented. In theory, eachfunction described here have a correspondent LN13 in the IEC 61850 standard. The nextchapter deal with the “translation” of the description (defined here) to the modelling(utilizing IEC 61850 data models).

This chapter provides the starting point for the engineering process of design (orspecification) of the automation system for HGUs. Having the data well organized beforethe project can avoid the need for repeated troubleshooting, which frequently causes delaysin the project progress. In addition, a structured description makes it easy to analyze,for example, the devices characteristics (quantities of inputs and outputs required and soon).

The descriptions presented in this chapter are not exhaustive. As the systems are com-plex and there are more than one way to describe them (with advantages and disadvan-tages), more time is necessary for analyses and for concluding about the best descriptionaccording to the defined criteria. Specific analyses of descriptions are suggested as futureworks. The data of the case study also need to be reviewed.

12Those concepts are introduced in the next chapter (7 “Modelling of the Generating Unit”), at Sec-tion 6.5.

13That concept also is introduced in the Section 6.5.

Chapter 6

IEC 61850 Standard andCommunications

“A standard international language should not only besimple, regular, and logical, but also rich and creative.”

Edward Sapir (1884-1939)

6.1 Introduction

This chapter presents concepts and definitions of the IEC 61850 “Communication Net-works and Systems for Power Utility Automation” standard [11] necessary to understandsome parts of the research. As already cited in the Chapter 5 “Description of the Gen-erating Unit”, the IEC 61850 standard will be used in the modelling of the HGU (nextchapter) and also in the automation (Chapter 8 “Generating Unit Automation”).

This chapter also presents the author’s interpretations of the IEC 61850 standard.A few methods to apply the standard are proposed. Besides, some modifications andimprovements in the standard are suggested. During the development of the chapter acouple of constructive critical analyses are presented.

This research is focused on the application. Thus, it is supposed that the data modelsand communication services of the IEC 61850 standard are completely implemented andready to be used1. The software that implement the IEC 61850 communications can beseen as a midlleware2.

1In spite of the fact that the lack of IEDs for HPPs compliant to the IEC 61850 standard on themarket is known.

2In this context, a “midleware” is a software layer that provides a programming abstraction and isused to join entities of software and hardware.

Chapter 6. IEC 61850 Standard and Communications 67

There are a large number of bibliography about the IEC 61850 standard regardingelectrical substations. According to K.-P. Brand [12], “the scope of IEC 61850 is substationautomation systems of any type, size and voltage level”. According to many authors theIEC 61850 standard support all necessary communications of the automation systems insubstations [26] [78] [51] [52] [79]. According to L. Hossenlopp and E. Guimond [53], “theIEC 61850 does not standardize the functions in order to foster innovation, and distributedautomation must be engineered on a per project basis”. At same time, the use of IEC61850 standard simplifies the engineering of the systems, since it is not dependent on thehardware.

Orth, J. [27] consider that the introduction of the IEC 61850 standard is a big stepforward in simplifying the integration of electrical systems. Similarly, many other au-thors considers that the IEC 61850 standard facilitates the development of traditionalapplications for new substations [54] [80] [58].

On the other hand, the IEC 61850 standard is also considered complex and a domainspecific knowledge. For example, Y. Liang and R. H. Campbell [81] affirm that “theIEC 61850 standard is difficult for people other than domain experts to understand andimplement”. That complexity is partially due to the huge standard scope, introducedbelow. Besides, C. Brunner [82] et al. present a serie of problems found in the firstexperiences of IEC 61850 projects. A recurrent complaint about the standard is theamount of data necessary to implement it (a very simple automation system may have alarge quantity of data associated to).

The IEC 61850 standard intends to support the communications of all functions beingperformed in substations and power plants (hydro, thermal and wind). The standard canbe used to modelling both primary and secondary systems (introduced in the Section 2.4).The IEC 61850 standard has data models for modelling conducting and general equip-ment. The standard has the specific part IEC 61850-7-410 [18] [17](an extension whichfirst edition was published in 2007 and the second in 2012) for the automation of HPPs(including: electrical, mechanical and hydrological functions).

The Figure 6.1 illustrates the conceptual modelling approach for mappings of devicesin different “worlds”. That is the concept of “virtualisation” of the IEC 61850 standard toprovide a view of real devices aspects [83]. The modelling elements and concepts presentin the figure and also the mapping process are discussed in this chapter (and utilized inthe Chapter 7 “Modelling of the Generating Unit”).

The IEC 61850 standard separates the application and the communications aspects.Thus, those two aspects can be managed independently. The changes in one part donot have impacting on the other part and vice versa. That characteristic is sometimesreferred as “future-proof” [26]. In this research the focus is on the application part. It is


Figure 6.1: Conceptual modelling approach.

considered that the communications part is well resolved.Before the exploration of the IEC 61850 standard, some aspects of communication

systems are presented.

6.2 Communication Systems

This section briefly present some concepts, definitions and analyses regarding commu-nication systems necessary to develop the research.

A communication system is an “arrangement of hardware, software, and propagationmedia to allow the transfer of messages from one application to another” [84]. In thecontext of this research, the communication system provides all communication links ofthe automation system. It is implemented utilizing transmission medias (cables) andcommunications ports (adapters of the data terminal equipment: IEDs and computers),switches, routers, firewalls, etc., and the associated protocols and software.

The part IEC 61850-6 of the standard [85] states that the communication systemdefines “how IEDs are connected to subnetworks and networks, and at which of theircommunication access points (communication ports)”.

Normally, the IEDs are physically interconnected through Local Area Networks(LANs). A LAN is a privately owned network that operates within and nearby a sin-gle building [86]. In the context of this research, the building is the powerhouse, dam andthe control and operation rooms of the HPP.

Some authors state that the use of networked communication infrastructure in sub-


station environment is limited. However, as presented in the Chapter 3 “Evolution ofthe Automation Systems and Proposal”, this scenario has been changing. Nowadays itis not possible to think in a new automation system for an electrical substation withoutnetworked communications. The same is occurring in the HPPs [7] [8].

The IEC 61850 standard adopts the Ethernet network [87] [88] [79] [89] [90] [91]. Thatchoice facilitates the design and implementation considering that nowadays it is the maintechnology of network communications.

The Ethernet is specified by the IEEE 802.3 “Standard for Ethernet” [92] of theInstitute of Electrical and Electronic Engineers (IEEE). It has simplified configurationand management for application in industrial automation systems. The Ethernet utilizesthe layers “physical” and “data link” of the Open Systems Interconnection (OSI) model3

of the International Standards Organization (ISO).According to B. Kasztenny et al. [93], the standard Ethernet has features (introduced

below) such as VLANs, MAC address filtering, and priority tagging that allow to createLANs with success and proper level of repeatable performance.

On the other hand, the utilization of Ethernet networks in the automation of electricalfacilities brings new concerns. The major one is the cyber security (discussed in theSection 6.3 below). The reliability also is frequently discussed.

The protocols more used over the Ethernet are the Transmission Control Protocol(TCP), the User Datagram Protocol (UDP) and the Internet Protocol (IP) [94]. Theyare applied in the IEC 61850 standard.

Other protocol used by the IEC 61850 standard is the Manufacturing Message Spec-ification (MMS), introduced hereafter in the Section 6.8. The part IEC 61850-8-1 of thestandard [48] specifies the mapping of the objects and communication services (shownbelow, in the Section 6.6) to the MMS.

The next subsection presents other aspects of the communication systems and of theprotocols and standards cited above.

6.2.1 Networks Topologies

The topology of a communication network refers to the organization of the “nodes”4 onthe network. Physically it is the way in which the constituent parts of the communicationsystem are arranged. Thus, the topology guides the transmission media connections.

3The OSI model is an abstract model that divide the communication tasks in seven layers, each oneresponsible for a specific function.

4Node is a point of connection within a communication network. In the context of this research, a nodeis any device (capable of receiving and/or transmitting data) attached to the communication network.


The Figure 6.2 shows the basic network topologies, which are explained in the followingparagraphs.

Figure 6.2: Basic communication networks topologies.

Bus

The bus is the simplest physical topology. It consists of only a trunk cable. Eachdevice is connected to that trunk. All devices receive all messages.

Ring

The ring topology is basically a closed loop communication network in which, normally,the network devices (switches) are connected5. The messages pass through each networkdevice (a redistribution point) to reach the next.

Some advantages of the ring topology are that the times to transmit data are knownand there is no collisions. The main disadvantage of that topology is that for long se-quences of devices, each device delay has influence on the overall response time. Anotherdisadvantage is the cost.

Star

The star topology join the cables of each device to a single central connection net-work device (that is a redistribution point). Normally that device is a switch (see theSection 6.2.2).

The star topology is simple, has great insensitivity to the increasing of data trafficand achieves fast response times, compared with the bus and ring topologies. Anotheradvantage of the star topology is that the quantity of required switches is reduced. Fur-thermore, in that topology the expansions are easy to be done. The disadvantage of thestar topology is that the switch failures discontinue the communications of all devices.

5The automation devices are (singly) connected to those network devices.


Tree

The tree topology is also called “hierarchical” or “star of stars”. It is a combinationof the bus and star topologies (presented above). The devices are connected in stars andthe network devices of those stars also are connected among them. The tree topologycombines the advantages and disadvantages of the original topologies.

6.2.2 Switched Ethernet

Ethernet networks that use switches6 are called “switched Ethernet” networks [86].The switches provide intelligence to the communication system (for example, processingthe messages priorities) and increase in the throughput. Utilizing a switch, each pairof communicating devices can transmit the data at the highest common speed betweenthem.

It is assumed that the switches used in this research are managed. Those kind ofswitches allows diverse configurations as, for example, definition of VLANs, configurationof port bandwidth and prioritization of ports for Quality of Service (QoS)7. Thus, it ispossible to configure VLANs and redundancy protocols. Some of those functions areintroduced in the next subsection. Besides, the managed switches can have centralizedmanagement. That function is important for networks containing many switches (as thecase presented in this report).

The 802.1Q Ethernet frame [94] provides a set of 3 bits for priority classification. Thatdata allows to distinguish hard real-time traffic, soft real-time traffic and time insensitivetraffic in order to provide better quality of service over Ethernet [86].

To connect distinct networks are used devices similar to the switches, the routers8 [86].

6.2.3 Virtual Local Area Networks - VLANs

Virtual Local Area Networks (VLANs) are logical subgroups within a LAN [6] [86].They are defined by software (rather than cables), configuring the ports of the switches.

6Switch is a network device that connects different devices on a communication network. It uses“packet switching” to receive, process and forward data to the destination device. The switch can forwardsdata to one or multiple devices according to its configuration and to the packet data (header). The switchworks in the layer 2 of the OSI model, using hardware addresses (here layer 3 switches are called “routers”,defined in the page 71).

7QoS is a set of network service requirements, based on standards, to assure adequate data trans-mission. The QoS indicates a level of service that allows the transmission of data at a specific rate anddelivery in a specific time.

8Router is a network device that connects multiple communication networks and forward packetsdestined either for its own networks or other networks. The router requires packets formatted in “routableprotocols”. It works in the layer 3 of the OSI model, using IP addresses.


Thus, as the VLANs are assigned to the switch ports, they work at the layer 2 of the OSImodel.

The utilization of VLANs is highly recommended in the IEC 61850 standard compli-ant systems [80] [56] [90] [6]. According to G. Leischner and C. Tews [95], the “VLANsoffer a preferred method for simplifying substation wiring, reducing installation cost, andenhancing overall protection of contemporary high-speed Ethernet communication net-works”.

The VLANs allow more efficiently data traffics within specific groups of devices. In thecontext of this research, the VLANs allow isolating distinct communications (accordingto applications and/or services) to ensure the highest performance. For example, in thisresearch the filtering provided by the switch will ensure that IEDs do not receive datatraffic on VLANs which they do not participate. Thus, some IEDs do not need to processmessages intended for other IEDs.

6.2.4 Redundancy of Communications

To increase the reliability of the communication system, redundancy of communicationnetworks are used. There are diverse strategies of implementation. The initial basicprinciple is if one network fails, other one immediately takes over the communications sothat no data will be lost. A newer approach is redundancy implemented using networksworking concomitantly.

The Edition 2.0 of the IEC 61850 standard [96] [49] had included the cases where theIEDs have two network connections, to avoid loss of communication if one connection fails.The Parallel Redundancy Protocol (PRP) or the High-availability Seamless Redundancy(HSR) can be used9.

The PRP and the HSR are specified by the IEC 62439 “Industrial communicationnetworks - High availability automation networks” standard [97]. The main idea of bothis to ensure high reliability to the communication within the automation systems.

This research proposed to use the PRP. The main reasons are the facts that the PRPis transparent for the application, it works without reconfiguration and switchover, andit does not change the active topology of the network or have restrictions. Besides, intheory, the PRP can be easily implemented (in different ways).

H. Kirrmann, P. Rietmann, and S. Kunsman [98] present the principles of the PRP.They affirm that the PRP “provides completely seamless switchover in case of failure oflinks or switches, thus fulfilling all the hard real-time requirements of substation automa-

9In the part IEC 61850-9-2 of the standard [49] the possible redundancy protocols are PRP and HSR.The part IEC 61850-8-1 of the standard [96] also includes the “Rapid Spanning Tree Protocol” RSTP.


tion”.The PRP was designed as a layer 2 Ethernet protocol. Thus, it is not able to support

IP routing. However, M. Rentschler and H. Heine [99] present some solutions to enablePRP for routed networks. They also present the principles of the PRP.

The PRP principle of working is the operation of two (or more) fail-independent Eth-ernet networks of similar topology in parallel. Each message is send twice on differentnetworks paths and the receivers discard the second message. Thus, in the case of twonetworks, the PRP provides (n-1) redundancy tolerating any single network device failure.One of the main advantages of this approach is that the redundancy is invisible to theapplication. Besides, the PRP achieves zero recovery time. The PRP has no restrictionson the size or on the architecture of the network and it is available in hardware.

6.3 Cyber Security

The cyber security [100] [29] [101] [28] [102] of the modern automation systems shouldbe a major concern. The system design (and other phases of the systems life cycle) mustensure the communications and data securities. The main goals of information systemssecurity are: confidentially, integrity, and availability.

It is believed that in recent past the cyber security issue was being underestimated inthe electricity sector [103]. However, nowadays the electrical companies are changing suchbehavior and they have started to worry about the information security Some companieshave created specific divisions of cyber security with experts (teams to study the subjectand provide solutions).

The electrical automation systems are subject to diverse cyber risks10. Unfortunately,the modern automation systems can have many vulnerabilities [104] [105] [102].

The North American Electric Reliability Council (NERC) has created some standardsregarding cyber security, known as “NERC CIP11 Standards” (CIP-002-1 through CIP-009-1). Most of them initially published in May, 2006. The purpose of them is to reducethe risks associated to cyber security.

An IEEE working group (C1 Working Group of “Power System Relaying Commit-tee”) has worked on the security of electronic communication paths to protective relays.They published an extensive report presenting some background and discussions aboutthe concerns associated to electronic communications in the power industry [100]. Theyconcluded that the cyber security “faces substantial challenges both institutional andtechnical”, and it presents some of the major trends, besides other considerations.

10A cyber risk is the probability of a threat to exploit a vulnerability.11CIP stands for Critical Infrastructure Protection.


An IEC working group (TC 57 - WG 1512) also has worked on the cyber securitysubject. They created the IEC 62351 “Power systems management and associated infor-mation exchange - Data and communications security” standard [106]. It presents a lotof cyber security issues implementations.

Another important work of the IEC about cyber security is the IEC 62443 “Industrialcommunication networks - Network and system security” standard [84]. It was createdto address the need to design cyber security robustness and resilience into industrialautomation control systems. It is based on threats, risks and countermeasures, as wellas the relationships among them. The relevant security aspects are discussed in differentphases of the life cycle of the automation systems.

The communication network segmentation is a key element of the IEC 62443 standard.The standard introduces the concept of “zones and conduits”. That model address thedifferent levels of security of complex systems. It is a way to segment and isolate (from thecyber security standpoint) the parts of an automation system. The model of zones andconduits is applied in this research (in the Chapter 9 “Automation System Architecture”).

The assets are separated in groups: the “security zones”. A security zone is defined asa “grouping of logical or physical assets that share common security requirements” [84].The zone has a clearly defined border. Sometimes a zone can be comprised of a collectionof “sub-zones”. Each zone has a level of security. That level represents the importance ofthe zone and, thus, its requirements for security.

The communications between two zones occurs through a “conduit”. A conduit is aparticular type of security zone. It is a “logical grouping of communication assets thatprotects the security of the channels it contains” [84]. The name is an analogy to thephysical conduit that protects a cable from damage. The conduits control the access tothe zones and protect the integrity and confidentiality of the data traffic in the links. Inthe context of this research, the conduits are parts of the communication networks.

The IEC 62443 standard presents the security requirements to define the zones andconduits. However, the standard does not specify how the zones and conduits should bedefined. They varies for each facility, according to the risks of cyber attacks and theirconsequences.

The basic idea proposed in this research (presented in the Section 9.11) is to isolate thedifferent parts of the automation system and, at the end, to isolate it from the externalsystems. There are different levels of isolation. The main function applied for isolationpurposes is the firewall13 [86]. It is important to remember that there are other issues

12Technical Committee (TC) 57 “Power Systems Management and Associated Information Exchange”.Working Group (WG) 15 “Data and Communication Security”.

13Firewall is a general-purpose or dedicated network device that restricts the communication between


related to cyber security, as the physical access to the computers and devices, for example,also briefly addressed in this report.

6.4 Time Synchronization

The introduction of digital data processing in the electrical automation systems hasbrought the need for time synchronization. The IEDs have internal clocks by definition[107]. Therefore, those clocks must be synchronized.

The temporal data of the automation system must have the same time reference. Thetime synchronization allows a temporal relationship between data acquired by devices atdifferent locations. It is important for time tagging of events (changes of statuses) andfor synchronization of sampled values.

The first approaches for time synchronization were based on an uncertain local timereference, with low accuracy. That approaches does not meet the requirements of someapplications based on the modern digital technology. To solve that problem, the timesynchronization based on timing signals from satellites of the Global Positioning System(GPS) has been adopted. Thus, the Coordinated Universal Time14 (UTC) has becomethe reference.

Nowadays there are many technologies and methods based on the UTC. The threemost used are: Inter-Range Instrumentation Group mod B (IRIG-B); Network TimeProtocol (NTP); Precision Time Protocol (PTP). They are briefly described in the nextsubsections.

6.4.1 Inter-Range Instrumentation Group mod B - IRIG-B

The IRIG [108] was created by the United States government in the decade of 1950and it was accepted as standard in 1960. It consists of a set of patterns for encodingand transmission of timing signals. Its goal is to convey information for time tagging ina precise and accurate way. The IRIG can be applied to various types of interfaces, withvarious types of physical layers. It is not restricted to the electrical sector, the IRIG isused in general industry and also in military applications.

The IRIG time codes have one letter for designations of format, which varies from onepulse per minute until 10,000 pulses per second. The pulse rate of the IRIG time code Bis 100 pulses per second. It is widely applied in the electrical sector. In addition, a threedigit suffix in the IRIG specifies the type and the frequency of the carrier.

two distinct networks. There are different kinds of firewalls, generally they perform predefined “rules”.14Or also Universal Time Coordinated.


6.4.2 Network Time Protocol - NTP

The NTP [109] is the solution of the Internet Engineering Task Force, or simply IETF,for time synchronization. Its development began in 1979 and the first specification (version0) was issued in 1985 (RFC 958). Its initial purpose was to synchronize the time of networkdevices among them and as close as possible to the UTC reference. The NTP is theoldest protocol for time synchronization through communication networks in operation.Currently it is the most widely used method of time synchronization for computer networksand for the Internet.

With the inclusion of data networks in electrical automation systems, the NTP startedto be used on the electrical sector. In 2002 a simplified version consistent with the NTP,the Simple Network Time Protocol (SNTP), was adopted by the IEC 61850 standard asthe time synchronization method. The SNTP is basically the NTP without some internalalgorithms that are not needed for all types of servers.

The IEC 61850 standard continues requesting the support of SNTP. Curiously theSNTP time accuracy is insufficient for sampled values applications. That synchronizationapproach does not reach microsecond synchronization. Furthermore, now the IEC 61850standard also apply the PTP, described below.

6.4.3 Precision Time Protocol - PTP

The PTP [110] is a protocol for precise synchronization of clocks into measurementand control systems. Its development began in 1990 for use into instrumentation systems.In 2000 it started to be used into industrial automation. In 2002 the IEEE published theversion 1.0 of the standard, defined by IEEE std 1588 and in 2008 a revision was published[111]. In 2004 it was also approved as standard by the IEC, intituled IEC 61588 withsame name. The active standard is the IEC 61588 edition 2.0 [112] published in 2009.

Like as the NTP, the PTP is implemented with technologies of communication net-works. It was conceived with the objective of providing precision better than one microsec-ond, addressing distributed systems, being ready to redundant and fault-tolerant systems,as well as being a multivendor international standard (to provide interoperability).

The IEC 61850 standard now has a new part IEC 61850-9-3 “Precision Time Pro-tocol Profile for Power Utility Automation” [113] that define a profile for accurate timesynchronization based on the IEEE 1588 standard (PTP Version 2).

Due to its characteristics, the PTP looks to be the tendency for time synchronizationin the future systems. That method of time synchronization is adopted in the architectureproposed in this research.

As cited in Section 6.2, the PRP is adopted for network redundancy in this research.


The PTP can works over PRP, but some attention to configuration is necessary. Thescheme of time synchronization can be configured to handle the two networks such asdifferent systems of time synchronization, avoiding a possible problem of different delaysof the two networks. In fact, to avoid problems due to varying delay estimations from theduplicate packets, the time protocol needs to know that there are two physical Ethernetnetworks.

6.5 Basic Entities of the IEC 61850 Standard

This section introduces the main elements of the IEC 61850 standard. In the standardthere are some basic entities that compose the fundamental data model. The Figure 6.3shows the structure of those entities.

Figure 6.3: Structure of the basic entities of the IEC 61850 standard.

As can be seen in the figure, the most important entities of the information models ofthe IEC 61850 standard are [114]:

• Data Attribute (DA): entity that defines the semantic, format, range of possiblevalues, and representation of values while being communicated;

• Data Object (DO): entity that represents structured meaningful data of applica-


tions15;

• Logical Node (LN): entity that represents a typical function of applications16;

• Logical Device (LD): entity that represents a set of typical functions of applica-tions (group of LNs);

• Physical Device (PD): entity that represents the physical parts of a device (hard-ware including the firmware, etc.). The physical devices host the LDs.

The Figure 6.3 shows that in the IEC 61850 standard the data are organized in astructure of DOs composed by DAs. The DAs have specific types. The DA type conceptcan be seen in the part IEC 61850-7-2 of the standard [114].

The part IEC 61850-5 of the standard [107] introduces the concept of “Logical Node”(LN). The LNs are the core objects of the IEC 61850 object-oriented approach. Thus, theyhave data and methods (see the Section 5.5). The LNs are the communicating functionparts of the applications functions. Thus, they represent the interfaces of basic functions.Only the data that are relevant for the “external world” are available on the LNs.

The representations of the applications functions are decomposed in LNs. They canrepresent functions of the primary and secondary systems. A LN is the smallest part of afunction (of those systems) that exchanges data. Besides, there are LNs specifics for eachlevel of the automation system (defined in the Section 8.3): process level, unit (or bay)level and station level.

Informative examples to use the LNs are given in part IEC 61850-5 of the standard[107] (basic applications) and in the part IEC 61850-7-510 [63] (HPPs applications).

The part IEC 61850-7-1 of the standard [83] introduces de “Logical Devices” (LDs)applications. The part IEC 61850-7-2 of the standard [114] also has information aboutthe utilization of LDs.

The LDs basically are sets of LNs. The LDs are implemented in the “Physical Devices”(PDs). The LDs must include LNs for common functions: the “Logical Node Zero - LLN0”and the “Logical Node Physical Device - LPHD” defined in the part IEC 61850-7-1 [83].The LLN0 represents common data of the LD. The LPHD contains common data of the PDhosting the LD, as information about the PD status.

The PDs are the Intelligent Electronics Devices (IEDs) or another kind of hardware(and the associated software). From now, in this report will be considered that PD andIED are synonyms. The main IEDs addressed in this research are PLCs, thus, the terms

15Applications of measuring, automation, control, protection, supervision, monitoring.16Considering the modelling ideas presented in this report, the LNs represent typical functions of

equipment or devices (see the Section 6.11).


IED and PLC also will be used as synonyms (the context allows to verify if the referredIED is a PLC or not).

As stated in the Chapter 1 “Introduction”, the IEDs are the automation devices. TheIED is “any device incorporating one or more processors, with the capability to receiveor send, data/control from, or to, an external source” [11].

In fact, the IEC 61850 standard states that all electronic devices for telecommunica-tion, HMI, process environment, and so on are IEDs17. For example, the part IEC 61850-4of the standard [115] cite as typical IEDs: gateways, RTUs, protection relays, personalcomputers, workstations, bay control units, meters, autonomous controllers, transducersand digital VTs and CTs. Curiously the PLCs are not cited.

Considering the above presented structure and definitions, the IEDs (or PLCs) canhave multiple LDs which can contain multiple LNs. That arrangement is according toother definition contained in the IEC 61850 standard [11]: the IED is a “device capableof executing the behaviour of one or more LNs”. Thus, the IEDs host data according tothe data model and allow exchanging data according to the services/interfaces specifiedin the IEC 61850 standard [107].

From the communication point of view, the LNs are standard interfaces to data ex-change between PDs. Note that, a PD may have internal data which are not visible tothe “external world” and, thus, those data are not included in the LNs. In this researchit is suggested to apply the IEC 61850 standard in the implementation of the logics ofautomation (in the Chapter 8 “Generating Unit Automation”). Thus, may be necessaryto represent some IED internal data using the IEC 61850 notation.

Making a connection between the data structure of the IEC 61850 (Figure 6.3) andthe data structure created in the Chapter 5 “Description of the Generating Unit” for thedescription (Figure 5.1), the IED is the “Physical Device” and the “inputs and outputs”are associated to the DOs (in fact they are connected to the DAs). Each LN has a setof specific DOs, to be associated to specific process devices. The LNs are organized in“groups” (the LNs groups are introduced below). Those associations are used in theChapter 7 “Modelling of the Generating Unit”.

As can be observed in the text above, the main elements of the IEC 61850 standardgive the idea of nested elements. The Figure 6.3 shows a ludic representation of thenesting, using the most world famous symbol of nesting: the “Matryoshka”.

17The author of this report does not like that generalization. Thus, in this report only the automationand control devices, or PLCs, and protection devices are considered IEDs. The network devices andcomputers are referred by their specific names.


Figure 6.4: Ludic nesting of the basic entities of the IEC 61850 standard.

6.5.1 Groups of Logical Nodes

The IEC 61850 standard defines in its part 7-4 [116] some groups of LNs, in fact groupsof LN classes. The groups are identified by a single letter. The names of the LN classesbegin with the character representing the group to which they belongs to. As examplecan be cited the group “S - Supervision and Monitoring”, broadly used in this research.

The group “H - Hydro Power” contains LNs that covers specific functions for HPPs.In theory, some LNs of that group may also be used by water supply utilities or otherutilities with larger reservoirs.

The group “T - Instrument Transformers and Sensors” represents the sensors whichthe values have to be continuously sampled. Those sampled values are used by dedicatedprocessing LNs, for example, the supervision LNs (group S).

6.6 IEC 61850 Conceptual Data Model

The part IEC 61850-7-2 of the standard [114] defines a model of Abstract Communica-tion Service Interface (ACSI). That standardized interface provides access to the objects ofthe applications and communications through the network, allowing real-time cooperationamong IEDs and other devices.

The ACSI has the conceptual models to build the domain specific information models.Each one of those information models is defined as a class. As stated in the Section 5.5,the classes comprise attributes and services (or methods). The semantics of the entitiesintroduced in the Section 6.5 are standardized by means of classes. The following overall


classes are defined [114] :

• Server: represents the external visible behaviour of a device. All other ACSI modelsare parts of the server;

• LogicalDevice: represents the information produced and consumed by a group ofdomain specific application functions;

• LogicalNode: contains the information produced and consumed by a singledomain-specific application function;

• DataObject: provide means to define typed information.

The Figure 6.518 presents the basic conceptual class model of the ACSI.

Figure 6.5: Basic conceptual class model of the ACSI.

As can be seen in the figure, the classes LogicalDevice, LogicalNode and DataObjecthave the generalization class Name (the class Name is inherited by them). Thus, eachone has the attributes objectName and objectReference. The objects of the class Name areunique among objects of the same server to which the specializations belong to. Thatsubject is presented separately, in the Section 6.7.

18Adapted from the source “Standard IEC 61850-7-2, Communication networks and systems for powerutility automation - Part 7-2: Basic information and communication structure - Abstract communicationservice interface (ACSI)” [114].


The ACSI also has an information model for DAs defined by the class DataAttribute.The DataObject is a composition of DataAttribute. The DAs of the DOs19 are dada forspecific use. For simplicity, the DAs are not explicitly used in this research (although inthe practice they are mandatory). Besides everything, also there are “components” of theDAs.

The relationships with the classes BinaryValue and AnalogValue and the attributestimeStamp and quality of the Figure 5.2 (presented in the Section 5.5) are examples ofDAs.

The specific use of the DAs are characterized by Functional Constraints (FCs). TheFCs could be understood as filters of the DAs. Besides, the FCs indicate the services thatare allowed to be operated on specific DAs. The part IEC 61850-7-2 of the standard [114]presents a table with the possible FC values.

For simplicity20, the data models presented in this research (subject of the Chapters: 7“Modelling of the Generating Unit” and 8 “Generating Unit Automation”) do not go intodetails of DAs and FCs. It is assumed that looking at the DOs specified, the DAs and FCscan be supposed. Naturally, those information are necessary for the implementations.

6.7 IEC 61850 Objects Names and References

The standardized naming of the IEC 61850 standard can provide an intuitive descrip-tion of the points (signals). When compared with older protocols for automation, theIEC 61850 standard (which is not only a protocol...) presents advantages for signalsidentification (names and references) [6] [118].

As cited in the Section 6.6, each object of the ACSI has a name and a reference (seethe Figure 6.5). The objectName is the name of an instance of a class. The objectReferenceis a reference of an instance of a class that defines the “path name” of that instance (it is aconcatenation of all object names). The objects can be accessed through their references.To invoke a method in an object, the object reference and method name should be given.

The objects references are built from the following parts [114]:

• LD Name: user defined part identifying the LD;

• LN Prefix: function related part to distinguish several LNs of the same class withinthe same LD;

19Data Objects.20To have an idea, the DO associated to the common data class (concept defined below) “Single point

status - SPS” [117] has 12 DAs, although here the main interest is only in three of them: stVal, q, and t.


• LN Class: standardised LN class name (they are the names of the classes thatbelong to the groups of LNs described in the Section 6.5, defined in the parts IEC61850-7-4XX of the standard [116]);

• LN Instance: number which distinguishes several LNs of the same class and prefixwithin the same LD;

• Data Object Name21: name of the data;

• Data Attribute Name22: name of the attribute.

A graphical representation of those names, prefix and instance can be viewed in theFigure 6.6. Some words “name” and “logical nodes” were omitted to the figure looks moreclear. The numbers in the figures are the maximum lengths in characters (in the Edition1.0 of the IEC 61850 standard [119] those numbers are smaller - see a comparison, forexample, in [120]).

Figure 6.6: Objects names and references syntaxes.

The boxes in green color are, in theory, configurable (they can be freely chosen).Note that, the LN name is composed of the LN prefix, LN class and LN instance. The

LN prefix and the LN instance are not semantically standardized (but it is proposed inthis research, as explained in the Chapter 7 “Modelling of the Generating Unit”).

The DO name and the DA name identify the data (signals) inside the LNs. Thosenames are defined in the parts IEC 61850-7-3 [121] and IEC 61850-7-4 [116] of the stan-dard.

21The IEC 61850 standard indistinctly uses the terms “Data Object Name” and “Data Name”.22The IEC 61850 standard indistinctly uses “Data Attribute Name” and “Attribute Name”.


In the context of this research, for simplicity, the DO reference is the signal identi-fication in the automation system. In the practice, the signal identification is the DAreference, sometimes filtered by the FCs.

The Chapter 7 “Modelling of the Generating Unit” presents some considerations aboutthe reference syntax, more specifically about the LN prefix.

In the mapping of the data to the application layer protocol the dots symbols “.” arereplaced by the dollar sign “$” and the FC is included.

6.7.1 Definition of the Names

There are several option do define the LD names and the LN prefixes. In theorythey are completely free with lengths limitations (as cited above the lengths limits aredifferent in the Edition 1.0 and Edition 2.0 of the IEC 61850 standard). The IEC 61850standard presents some examples considering product related naming and function relatednaming. A proposal of naming is developed in this research and presented in the Chapter 7“Modelling of the Generating Unit”.

Some manufacturers do not permite the definition of the LD names by the customers.In a few cases the LD names are fixed, two examples can be cited: Measurements, Recordsand System; or Control, Disturbance Recording, Extended, Measurement and Protection.In this research it is considered that the definition of LD names is free (there are norestrictions).

6.8 IEC 61850 Communications Services

The IEC 61850 standard specify a complex and embracing set of communications ser-vices. The foundations and some details of those services are described in [6]. As well, W.Wimmer presents a brief and consistent explanation of the IEC 61850 standard communi-cation services in [122]. Basically the IEC 61850 standard communication services allowintegration with the process (peer-to-peer messages) and integration with supervisorysystems (client-server messages).

As presented above, the part IEC 61850-7-2 of the standard [123] defines the concept ofACSI. The Figure 6.7 shows the idea of the relation of data models and the communicationservices.

The information models of the ACSI are introduced in the the Section 6.6. Here areintroduced the models of the services.

Any communication service is configured by means of a “data set” (defining the datato be sent) and a “control block” (defining when and how the data will be sent). The


Figure 6.7: Communication and information interfaces and mappings.

data sets are assigned to the control blocks. There are different types of control blocks fordiverse applications [114]: “report control block”, “log control block”, “generic substationevent control block”, “sampled value control block” and “setting control block”. The partIEC 61850-6 [85] specifies the elements of those control blocks.

The ACSI comprises the following models that provide services operating on DOs,DAs, and data sets [114]:

• Data Set: permits the grouping of data objects and data attributes. Used for directaccess, reporting, logging, Goose messaging and sampled value exchanging;

• Substitution: supports replacement of a process value by another value;

• Setting Group Control Block: defines how to switch from one group of settingvalues to another one and how to edit setting groups;

• Report Control Block and Log Control Block: describe the conditions forgenerating reports and logs based on parameters set by configuration or by a client;

• Control Blocks for Generic Substation Event: supports a fast and reliablesystem-wide distribution of input and output data values;

• Control Blocks for Transmission of Sampled Values: supports a fast andcyclic transfer of sampled values

• Control: describes the services to control devices;

• Time and Time Synchronization: provide the time base for the devices;


• File Transfer: defines the exchange of large data blocks.

The part IEC 61850-7-2 of the standard [114] presents a figure with an overview of theconceptual service model of the ACSI.

The generic substation event and the sampled value are the services most utilized inthis research. Their models are detailed below.

6.8.1 Generic Substation Event Model

As cited above, the Generic Substation Event (GSE) model allows fast and reliablecommunications. Thus, it can be used for distribution of input and output point values ofthe automation system. In the practice, the GSE model is used to exchange a collectionof DAs. Two control classes and the structures of two kind of messages are specified inthe part IEC 61850-7-2 of the standard [114]:

• Generic Object Oriented Substation Event (Goose): supports the exchangeof a wide range of possible common data organized by a data set;

• Generic Substation State Event (GSSE): provides the capability to conveystates changes information (bit pairs).

The Goose messages are used for peer-to-peer communication (among IEDs). They arenot confirmed publisher-subscriber communication services. The messages are transmittedover a reduced communication stack, in the layer 2 of the OSI model. The Goose messagesallow transmission of signals in high speed, for example, the statuses of the high voltageequipment. As the processing of intermediate layers of the OSI model are eliminate, thetransmission time is very short. Thus, the Goose messages can be used to transmit highpriority data such as for interlocking and tripping.

6.8.2 Sampled Value Model

The model for Sampled Values (SVs) specified in the IEC 61850 standard (part IEC61850-7-2 [114]) provides transmission of the values in a time controlled way. Each sampledvalue is identified by a number that provides the time reference. The SV model appliesto the exchange of analog values of a data set. The DOs of that data set are of the CDC“Sampled value - (SAV)” type, defined in the part IEC 61850-7-3 of the standard [121].


6.8.3 Manufacturing Message Specification - MMS

The MMS is an application layer protocol. It operates independently of the applicationfunctions. It is designed to deal with generic messaging for supervising and control ofindustrial equipment (originally in the manufacturing processes).

The MMS is specified in the ISO/IEC 9506 “Industrial automation systems - Manu-facturing Message Specification” standard [124] [125]. That standard basically defines aset of objects that must exist in a physical device and a set of messages to supervise andcontrol those objects. The ISO/IEC 9506 standard also define encoding rules for mappingthat messages. The MMS data can be simple (boolean, integer, char, etc.) or structured.

6.9 IEC 61850 Configuration Language

The part IEC 61850-6 of the standard [85] specifies the System Configuration descrip-tion Language23 (SCL). The purposes of the SCL are: substation automation systems24

functional specification; IED capability description; and automation system description.It is important to clarify that the functional description is only at the communicationinterfaces. Thus, the SCL is used for configuring and engineering the communications inthe automation of the power plants and substations.

W. Wimmer [126] discuss the SCL contents and applications and also the exchange ofdata among engineering tools.

The SCL is based on the eXtensible Markup Language (XML). The XML [127] is ahigh-level language that can be used to construct text files describing structured datafor specific applications. The XML uses “tags” and structures to identify and transportdata. The main advantage is that the XML is independent of hardware, software andapplications.

The XML is applied in many applications. For example, the C37.239-2010 “IEEEStandard for Common Format for Event Data Exchange (COMFEDE) for Power Systems”[128] provides an XML-based format that can be utilized to map sequence of events inany format and protocol to XML [129].

The SCL has diverse data models described using UML notation (introduced in theChapter 5 “Description of the Generating Unit”) [85].

Besides the standardization, that approach has another great advantage: it is vendorneutral, since SCL is not proprietary. Likewise, it is possible the existence of diverseengineering tools from different vendors, including third parts.

23Originally called “Substation Configuration description Language”.24It is considered that the HPP automation systems are included.


The SCL object model (shown in the part IEC 61850-6 of the standard [85]) has threebasic parts: substation (here also it is proposed power plant...), product and communica-tion. Those parts are presented below.

6.9.1 Substation Model

The substation model [85] is an object hierarchy based on the functional structure ofthe substations. Its purpose is to relate each LN and its function to a substation functionand to derive a functional designation for that LN from the substation structure.

The part IEC 61850-6 of the standard [85] specifies the following substation objects:Substation, VoltageLevel, Equipment, SubEquipment, ConnectivityNode, Terminal, Functionand SubFunction.

In this research it is considered that the substation model is not suitable for HPP and,thus, a new model is proposed in the Chapter 7 “Modelling of the Generating Unit” (seethe Section 7.2).

6.9.2 Product Model

The product model [85], or IED model, is an object hierarchy based on the structureof the IEDs.

The part IEC 61850-6 of the standard [85] specifies the following product objects: IED,Server, LDevice, LNode and DO.

6.9.3 Communication System Model

The communication system model [85] is a no hierarchical model. It models the “logicalconnections” of the system. Thus, the communication model contains the communicationconfiguration of the automation system.

As presented in the Section 6.5, the LNs are allocated in LDs and the LDs by theirturn are allocated in PDs. The PDs are connected through “physical connections” (sub-ject of the Chapter 9 “Automation System Architecture”) and the LNs are connectedthrough logical connections [107]. The logical connections are implemented over physicalconnections and, as cited, allow the data communication among the functional elementsof the automation system.

The part IEC 61850-6 of the standard [85] defines the following communication systemobjects: Subnetwork, AccessPoint, Router and Clock.


6.9.4 Complete Model

The part IEC 61850-6 of the standard [85] presents a complete SCL object model(including the substation model, product model and communication system model), bymeans of an UML class diagram.

6.10 IEC 61850 SCL Files and Tools

In the scope of the IEC 61850 standard, specific files are utilized to exchange dataamong engineering tools. This section describes those files and the respective engineeringtools.

6.10.1 System Specification Description - SSD

The System Specification Description (SSD) file basically describes the plant structureand the secondary systems functions. That file is created by a “systems specification tool”using data from the single line diagrams and schematic diagrams and also informationabout the operational functions.

The SSD file allows to extending the standardization into the specification [64]. It isparticularly important when the plant has multiple bays, substations, generating units,etc.

6.10.2 IED Capability Description - ICD

The IED Capability Description (ICD) file basically describes a type of IED. That filecontains the complete functional engineering capabilities of the IED. The ICD files aresupplied by the manufacturers of IEDs.

The ICD file can be created by an “IED configuration tool”, normally developed bythe manufacturer of the IED and sometimes associated to specific IEDs. Besides themanipulation of the data of the IEC 61850 standard structured models, that tool mayhave other functions as, for example, the configuration of the HMI of the IED and internalsettings.

Each IED can be configured using its dedicated tool, possibly using proprietary files.However, that tool also should be compliant to IEC 651850 standard, more specifically itshould be able to use the SCL standardized files (specified in the standard).

Rigourously, an IED shall only can be considered adherent to the IEC 61850 if it isaccompanied by its ICD file (or by its IID file) [85]. The system integrator needs thestandardized files of all IEDs of the system.


6.10.3 System Configuration Description - SCD

The System Configuration Description (SCD) file basically describes the completepower plant configuration. That file contains all configured IEDs, information about theirinteractions and configurations of the communication networks. The SCD files includedefinitions of all types used: Logical Node types, DO types, DA types, etc.

The SCD file is created by a “system configuration tool”, sometimes called of “systemsintegration tool”, using data from the other files described above. Part of the data of theSCD file is derived from the SSD and ICD files.

An IED shall only be considered compatible in the sense of the IEC 61850 if it candirectly use a SCD file to set its communication configuration [85].

6.10.4 Configured IED Description - CID

The Configured IED Description (CID) file basically contains the configuration of aspecific IED within an application. That file is also created by an “IED ConfigurationTool”. The CID file contains the configuration parameters of the IED, for a specificapplication. Thus, the IED can be configured simply loading that file. In fact, the CIDfile contains the data of SCD file related to the referred IED.

6.10.5 Other SCL Files

The Edition 2.0 of the IEC 61850 standard introduced two new SCL files: InstantiatedIED Description (IID) file and System Exchange Description (SED) file [85] [130].

The IID file describes the project specific configuration of an IED and it allows toupdate the IED data within a system. The IID file is used by the IED configuration tooland by the system configuration tool.

The SED file contains the transferred engineering and the IED engineering capabilitiesof a specific project. The SED file is used to share information between two SCD filesthrough the system configuration tools. Thus, it allows the right data flow engineeringtransference from one project to another one.

Those extra files are not addressed in this research.

6.10.6 IEC 61850 Tools

In the context of the IEC 61850 standard [123] [115] [85] the “engineering tools” aresoftware tools that support the creation and documentation of a substation automationsystem to the specific substation and customer requirements. There are different kinds of


software tools. The edition 2.0 of the standard presents a better definition of the roles ofeach tool, including new files (cited in te last subsection).

The IEC 61850 engineering tools can be classified in two main groups: device specifictools (the “IED configuration tools”) and system specific tools (the “system specificationtools” and “system configuration tools”). The IEC 61850 standard [116] also classifythe tools as “project management tools”, “parameterizations tools” and “documentationtools”. Some vendors call their tools “all-in-one”, supposing that those tools can supportall the necessary engineering processes regarding the IEC 61850 standard. Also there arethe called “multi-vendor integration tools” to emphasize that they can work with files ofdifferent manufacturers25.

In the last years the manufactures have create IEC 61850 software tools associatedto their systems and IEDs. Third parts and researchers also have developed tools [131][132]. Analyzes and comparisons of existing tools have been realized. Specialized worksalso have been carried out, for example, P. Young and J. Stevens [133] discusses about toolsfor automatic error detection in SCL files (they deal with different stages and categoriesof checking).

Unfortunately many available IEC 61850 tools do not fully support the SCL processes.Thus, it is supposed that yet there are some problems to understand and to apply the IEC61850 standard. According to C. Brunner et al. [134], although the SCL files are uniquelydefined in part IEC 61850-6 of the standard [85], “many implementations by vendors andsystems integrators have confused the mandated specification of these files and how theyare to be used”.

Finally, tests realized with some engineering tools, some years ago, shown that thereare differences of the IEC 61850 standard interpretation and limitations [135]. Besides,ways to convert the SCL files to be used by distinct manufacturers are discussed. Intheory, that conversion should not be necessary.

According to G. Dogger et al. [136], the IEC 61850 “engineering tools, still under de-velopment, must be improved to enhance the complete process ease-of-use and efficiency”.In a similar way, N. Nibbio et al. [137] say that “while the devices supporting IEC 61850are now abundant, there are still some shortcomings with the associated software toolsand support of SCL”. It is supposed that they are referring to IEDs for substations (notfor HPPs).

The Figure 6.8 shows a illustrative scheme of the process of generations and transfer-ences of the main SCL files and the associated tools.

25In that case, disregarding the IED specific tools, strictly speaking the term “multi-vendor” does notmake much sense, given that the SCL files of all manufacturers would have to be adherent to the IEC61850 standard.


Figure 6.8: Generations and transferences of SCL files and associated tools.

6.11 IEC 61850 Modifications Proposal

The application of the IEC 61850 standard in electrical substations is already a reality,but it is still incipient in power plants [7]. For that reason, the standard has not beenfully proven in the practice at the HPPs. Thus, some modifications in the IEC 61850standard can be necessary and some improvements may be done. A critical analysis ofthe IEC 61850 standard application in HPPs is carried out in this research26.

To model a complete primary system of a large HGU, some additional LNs (and DOsand DAs) are necessary in the IEC 61850 standard, but it is not a considerable problem.A greater problem is regarding the functionalities approach, a hierarchical functionalstructure specific for HPPs is missing. In addition, some modifications may be done toimprove the standard.

In the next subsections some proposals for modifications and improvements of theIEC 61850 standard are presented, considering the applications in HPPs. Some of themare applied in the case study of this research. The basic proposals of modifications arepresented below, the proposal of the functional structure is presented in the Chapter 7“Modelling of the Generating Unit” (at the Sections 7.2 and 7.3) and other proposal of

26Part of the critical analysis is carried out considering the experience in the modelling of the studycase (Chapter 7 “Modelling of the Generating Unit” and Appendix B “Case Study of Other Systems”).


modifications are included in the Appendix C “IEC 61850 Issues”.Additional comprehensive analyzes regarding the LN classes used for supervision, con-

trol and automation functions in HPPs are still necessary.

6.11.1 Sensors

In the automation system, the primary signals belongs to the LNs of the group “S -Supervision and Monitoring” (sampled values are not used). On the other hand, accordingto the part IEC 61850-7-4 of the standard [116], the LNs of the group “T - InstrumentTransformer and Sensors” seems to be needed27. It is supposed that the allocation ofthose LNs are associated to the existence of a process bus.

Therefore, in this research, for each LN of the group “S - Supervision and Monitoring”used in the modelling will be considered that exist one associated LN of the group “T -Instrument Transformer and Sensors” (although in the practice their utilization looks tobe not mandatory). However, the LNs of the group T are not explicitly presented.

A discussion about that subject (application of LNs of the groups S and T) is presentedin the Section C.8 of the Appendix C “IEC 61850 Issues”.

6.11.2 Alarms, Trips and Indications

In this research it is assumed that all supervisory LNs (group “S - Supervision andMonitoring”) have multiple levels of alarms, trips and indications28, as explained in thenext paragraphs.

Each DO of alarm has the following pattern: PrefAlmInst (CDC “Single point status -SPS” [117]), where the prefix Pref may be “Lo” meaning “low” or “Hi” meaning “high” andthe Inst is an instance number. The optional Pref “Lo” indicates an alarm in decreasingvalues and “Hi” indicates an alarm in increasing values (the Pref is omitted when notnecessary). The optional Inst is a meaningless integer number, but a good practice is touse it in a ascending/descending order. Thus, an alarm will be generated when a “Lo/Hi”(low/high) alarm level number Inst is reached. Note that, for each alarm it is necessaryto define an alarm level setpoint PrefAlmValInst29 (CDC “Analogue setting - ASG” [117]).

Each DO of trip30 has the following pattern: PrefTripInst (CDC SPS), where Pref

27The edition 1.0 of the part IEC 61850-7-410 of the standard [18] presents the “conceptual use oftransmitters”, however the edition 2.0 [17] do not present it.

28All the abbreviation presented in this subsection are specified in the IEC 61850 standard (and notdefined in this research).

29Observation: the IEC 61850 also defines the abbreviation “Set” for “Setting”, in addition to “Val”for “Value, Setting Value”.

30The IEC 61850 standard utilizes the term (abbreviation) “Trip” in a few LN classes (mainly in thegroup “S - Supervision and Monitoring”) and the term “Tr” in the majority of LN classes. The list of


may be “Lo” meaning “low” or “Hi” meaning high and Inst is a meaningless instancenumber. Thus, a trip will be generated when a “Lo/Hi” (low/high) trip level numberInst is reached. Note that, for each trip it is necessary to define a trip level setpointPrefTripValInst (CDC ASG).

In some applications the trips have particularities. Therefore more than one kind oftrip (with different consequences) can exist. Thus, this question also need to be analyzedfor the specification of the LN classes. In this research it is considered that the utilizationof the trip signals is defined by the logics of automation.

The same idea is applied to the DOs for indications: PrefIndInst (CDC SPS) andPrefAlmValInst (CDC ASG).

Another more radical change in the working of the alarms, trips and indications is theunification of the LN class for supervision. That proposal is not applied in this research,because the results would be very different from the actual edition of the IEC 61850standard. However, considering the advantages of this approach, it is described here.

There is no need of one specific LN class of supervision (Group S) for each measuredquantity. The IEC 61850 standard would specify an unique LN class for that purpose anduse it for any quantity through inheritance. If necessary, additional semantic for a clearidentification of the LN function could be included in the LN prefix (as proposed in thisresearch).

The Table 6.1 shows the semantic specification of the DOs Alarm, Trip and Ind ofthe proposed class for supervision.

Table 6.1: Specification of data objects for alarms, trips and indications.“SUPERVISION” Class

Data Object CDC Explanation T M/O/CSettings{Pref}AlmVal{Inst} ASG {Pref} preset value of the alarm level {Inst} O{Pref}TripVal{Inst} ASG {Pref} preset value of the trip level {Inst} O{Pref}IndVal{Inst} ASG {Pref} preset value of the indication level {Inst} OStatus Information{Pref}Alm{Inst} SPS {Pref} alarm level reached {Inst} O{Pref}Trip{Inst} SPS {Pref} trip level reached {Inst} O{Pref}Ind{Inst} SPS {Pref} indication level reached {Inst} O

An additional change is to include the delayed signals identification. In some casesmay be necessary to indicate that the signals are associated to timers (there is a delaytime to generate the signal). In those cases can be used the abbreviated term “Tm” before

abbreviated terms of the standard contains both abbreviations.


the discriminators “Lo/Hi”. Thus, the prefix Pref has new combinations. For example, aDO of a delay time low alarm would be “TmLoAlm”.

For each timed signal it is necessary an associated time setting (CDC “Integer statussetting - ING” [117]). The Table 6.2 shows the semantic specification of those settings (tobe added in the last table).

Table 6.2: Specification of times settings for alarms, trips and indications.“SUPERVISION” Class

Data Object CDC Explanation T M/O/CSettings{Pref}AlmTm{Inst} ING {Pref} preset delay time of the alarm {Inst} O{Pref}TripTm{Inst} ING {Pref} preset delay time of the trip {Inst} O{Pref}IndTm{Inst} ING {Pref} preset delay time of the indication {Inst} O

More analyses about the prefix “Tm” is necessary, because it can be a problem forimplementation. Anyway, the utilization of delay time signalizations is a useful resourcewidely applied in automation systems. That modification also is not applied in this report(the LN prefix is used instead of it).

An additional change is regarding the “starting/stoping actions”. Some LNs, as forexample the “Supervision of media level - SLEV”, have the DOs Activ (Start actionwhen activation threshold passed) and DeActiv (Stop action when activation thresholdpassed). Those DOs are considered unnecessary, because the DOs Alarm and Trip (andin some cases the DO Ind) can be used for the purpose of starting or stopping any action.Besides, it is considered that this kind of information is regarding to the applicationimplementation and not regarding to the communications (interface). Eliminating theDOs Activ and DeActiv the LNs would be simpler. Besides, those attributes do notfollow a standardization (pattern of specification in the standard).

A final comment is a criticism about the abbreviations used in the IEC 61850 standardfor adjusts. The standard use the abbreviations Val, Spt and Set to identify presetvalues. There is not an unique pattern. That approach is not good for a standard (morediscussions about that subject is presented in the Appendix C “IEC 61850 Issues”).

6.11.3 Logical Node Basic Functions

The mains idea is that each LN class for primary devices has only its basic functions.Any additional function should be represented by another basic LN class containing thatnecessary function. That change can simplify and, thus, improve the IEC 61850 standard,mainly the interpretability (and also the interoperability).


Note that, the proposed modification eliminates one of the present problems in theactual edition of the IEC 61850 standard, the large amount of optional DOs.

Unfortunately, the proposal presented in this subsection is not applied in the research.It is not applied because it would cause major changes in the IEC 61850 standard, sothat if applied the results of this research would be very different of the actual editionof the standard. Despite that the proposal would cause great changes in the standard, atranslation from one approach to the other is feasible.

6.11.4 Modification of LN Classes

It is proposed the modification of the following LN classes:

• Generic Process I/O - GGIO;

• Generator Shaft Bearing - HBRG;

• Dam Gate - HGTE;

• Intake Gate - HITG;

• Mechanical Brake for the Generator Shaft - HMBR;

• Speed Monitoring - HSPD;

• Hydropower Unit - HUNT;

• Air Compressor - KACP;

• Filter - KFIL;

• Supervision of Media Flow - SFLW;

• Circuit Breaker - XCBR.

For details, see the Section C.4 in the Appendix C “IEC 61850 Issues”.

6.11.5 New Logical Nodes Classes

It is proposed the creation of the following LN classes:

• Conventional Panel Board Interface – ICPB;

• Braking Lifting Monkey – KBLM;


• Oil-Water Heat Exchanger – KOWE;

• Relief Valve – KRLV;

• Solenoid Valve – KSVV;

• Three Way Valve – KTWV;

• Lockout Relay - PLOR;

• Timer – RTIM;

• Shunt - SHUN;

• Water in Oil Sensor - SWIO;

• Contactor - XCON.

For details, see the Section C.5 in the Appendix C “IEC 61850 Issues”.


In spite of the power and advantages of the IEC 61850 standard, it is complex withlarge documents, many topics (of diverse areas) and sometimes difficult to understand.Fully applying the standard is a challenge. Thus, some improvements are necessary andcan be done. For example, despite the fact that the IEC 61850 standard has a semanticfamiliar to the electrical automation engineers, the description of some data models couldbe more clear and friendly.

The technical reports of the IEC 61850 serie help to understand and to apply thestandard, but they can be improved. The technical reports should concentrate in cleardidactic examples of applications (and do not to reproduce the standard contents).

The main scope of the IEC 61850 standard are the communications for automation ofpower systems. The standard provides the models for communications related to the dataof the primary system. They are applied in the Chapter 7 “Modelling of the GeneratingUnit”. The standard also provides the secondary system models, which are applied in theChapter 8 “Generating Unit Automation”.

In the IEC 61850 standard compliant systems, a lot of configuration files are createdand must be maintained. Thus, that is a new way to work and also a new concern.

The software tools are very importante for the IEC 61850 standard application. Thetools can hidden part of the complexity of the IEC 61850 standard, cited above. Besides,user friendly graphical tools can facilitate the works (specification, design, etc.). Nowadays


there is a lack of IEC 61850 software tools on the market and some existing tolls do notfully support the SCL process. Generally the IED tools are quite restricted.

Tools that allow easy viewing of the structure of primary and secondary systems, con-sidering the LDs, LNs, DOs and DAs as well as the data exchanges should be developed.The direct representation of all those data in a single figure is complex (large amount ofdata) and hinders the understanding and analyses. One solution might be the creationof “views” with only the parts of the data according to the users’ choices and to allowdiverse kinds of views.

It should be clear that, although the critical statements above, the IEC 61850 standardhas excelente ideas to modernize the automation systems and to cause advances in thefield. It is know that the IEC 61850 standard contains the effort of diverse qualifiedexperts.

The names of the proposed model for the HGU description (presented in the lastchapter) together the IEC 61850 data models have more semantic than other standardswhich use codes to identify the components of the systems. It is expected that solutioncan be put into practice and it provides good results.

Finally, a question that is not matter of this research but it is a practical problem forthe implementation of automation systems for HPP is the low availability on the marketof products supporting the part IEC 61850-7-410 of the standard. Without IEDs (PLCsadherent to the IEC 61850 standard), there is no IEC 61850 automation system in HPPs.

Additional specific comments about the IEC 61850 standard are presented in the Chap-ter 7 “Modelling of the Generating Unit”, mainly about the application of the standard.

Chapter 7

Modelling of the Generating Unit

“Abstraction is a mental process we use when tryingto discern what is essential or relevant to a problem.”

Tom Gordon Palmer (1956)

7.1 Introduction

This chapter presents the modelling of HGUs according to the IEC 61850 standard.Almost all data models used are defined in parts IEC 61850-7-X of the standard [83]. Theresults are typical groups of LNs and LDs for a large HGU. The concepts and definitionsintroduced in the last chapter are applied here.

The description of the HGU given in the Chapter 5 “Description of the GeneratingUnit” is, in fact, a form of modelling. The main difference between the work done inthat chapter and the work presented in this chapter is that the first modelling was free(user defined) and here it will be done in accordance to the IEC 61850 standard and, asexpected, the conceptual data models are different. Remember that, the object modelof the IEC 61850 standard has a visible behavior to the communication systems. Thestructure used in the description is somehow reutilized here.

The main idea is to develop a method for modelling HGUs, introduced in the Chapter 2“Hydroelectric Power Plants and Hydro Generating Units”. The modelling is done usingthe description realized in the Chapter 5 “Description of the Generating Unit”. The LNsrelated to the components of the HGU represent mainly the intelligent part of the primaryequipment. Thus, they are a kind of “image” of the primary system (and the sensors andactuators) for the secondary system.

The description is transformed in structured LNs (including the other elements of thestructure). The user’s data used for description are associated to the data types of the

Chapter 7. Modelling of the Generating Unit 100

IEC 61850 standard (LN classes and DO types derived from the CDCs - the DA types arenot directly addressed). That activity is the initial step to develop the logical architectureof an automation system.

The part IEC 61850-7-4 of the standard [116] presents some modelling remarks. How-ever, to develop the modelling is not a too simple work. For example, some years afterthe publication of the part IEC 61850-7-410 of the standard [18] for HPPs, the part IEC61850-7-510 [63], a technical report, was published to provide explanations on how to usethe LNs to model a power plant. Unfortunately, some points are yet no so clear. Besides,some improvements are recommended.

Here it is proposed a new scheme of function oriented naming for HPPs. The proposednaming can also be used as IED names (and communication names). Thus, it is used onlyone naming in the engineering processes. That approach presents some advantages, forexample, it is not necessary a database to translate the names from one aspect to theothers.

The modelling developed in this chapter considers the modifications in the IEC 61850standard proposed in the Section 6.11 of the Chapter 6 “IEC 61850 Standard and Commu-nications” and also some considerations presented in the Appendix C “IEC 61850 Issues”.

In the modelling the choice of the IEDs to be used is not included (although indirectlythey are defined) and, thus, neither the links of inputs/outputs (the DOs/DAs of the LNs)to the devices terminals are include. That activity is an engineering step of the executiveproject, which is out of the scope of this research.

7.2 Proposed Conceptual Model for Modelling

The HGU (or HPP) description is already defined in the Chapter 5 “Description ofthe Generating Unit”. For the modelling according to the IEC 61850 standard, someclasses and relationships should be aggregated to the model presented in the Figure 5.2of that chapter. The main classes come from the conceptual data model of the IEC61850 standard, introduced in the Section 6.6 of the Chapter 6 “IEC 61850 Standard andCommunications”.

7.2.1 Hydroelectric Power Plants Functional Structure

The IEC 61850 standard defines a functional structure for the substations (presentedin the Section 6.9). However, that structure is considered not ideal for HPPs. Thus, inthis section a new functional structure specific for HPP is developed.

The substations typically are organized in control zones and bays, which contain the


switchyard equipment: circuit breakers, disconnectors and sometimes power transformersand regulators. The organization of HPPs is completely different. Basically the HPPs areorganized in HGUs, which contain a great variety of electromechanical equipment.

The functional structure proposed for the modelling of the HPP is based on the physicalstructure defined in the Section 2.5 of the Chapter 2 “Hydroelectric Power Plants andHydro Generating Units” including a new element “Subsystem”, defined below.

• Subsystems: are sets of equipment within a system. In the subsystems are groupedthe equipment, and their respective devices, related to a determined function in thesystem. Those equipment may be mechanical and/or electrical.

That new level in the hierarchical structure is a way to apply the concept of LD(introduced in the Section 6.5). Remember that, the LDs are entities which may containarbitrary LNs (besides two mandatory LNs).

One importance of the LDs is that they are used to provide a common address forthe LNs. Although, the obligatoriness to define LDs is not too clear in the IEC 61850standard.

The IEC 61850 standard does not determine how to organize the functions. Thatorganization depends on the installation and on the design features. The allocation ofLNs in LDs and then in PDs is guided by the functionality, performance, reliability,restrictions, etc.

In this research, the LNs of the process are allocated in LDs considering the mainfunction and the interfaces (inputs and outputs) and the LDs are allocated in PDs (theIEDs) considering the main systems. Thus, the allocation of the process functions isgoverned by the systems of the HGU (stated in the Section 2.6). As consequence, the basicdistribution of the LNs of the process is well defined by the systems (already established).

7.2.2 Class Diagram for Modelling

The IEC 61850 standard provides the interfaces of the common functionality for theHGU and for other applications. As shown in the Section 6.6, those interfaces are stan-dardized by means of classes. The automation systems use instances of those classes (forthe primary and secondary systems).

The class diagram created here connects the functions of a HPP associated to thestructure defined in the last subsection with the entities of the IEC 61850 standard (LNs,DOs... and DAs) shown in the Section 6.5. Thus, more information is added to the modelcreated for the description.


The Figure 7.1 shows the proposed conceptual model used for modelling, representedby a class diagram. It is basically the diagram shown in the Figure 5.2 of the Chapter 5“Description of the Generating Unit” including some classes of the diagram presented inthe Figure 6.5.

Figure 7.1: Conceptual model for modelling.

The classes DataObjectTypes (of the LNClass), CommonDataClass (with common at-tributes) and DataAttribute and their relationships are not represented in the figure.

Each input/output point is a structure of data. Thus, the class Point is associated tothe class DataObject. However, for simplicity, the relationships with the class DataAttributeare not represented. Remember that, the class DataObject is a composition of the classDataAttribute. In the scope of this research, the most used DAs are the associated to thevalues, time-stamps and qualities (as already cited in the Section 6.6).

The simplification stated in the last paragraph has impact in the model of the logicsof automation developed in the Chapter 8 “Generating Unit Automation”. By its turn,the data necessary in the logics has impact in the data flow. That dependency will result


in different configuration of the data sets. A most simple approach, but not efficient fromthe communication point of view, is to use as elements of the data sets the DOs (do notworry about the DAs). A more detailed configuration can consider the DAs. The IEC61850 standard [114] allows to create data sets referencing DOs or DAs.

As can be seen in the Figure 5.2, the LNs (class LogicalNode) can be related to twolevels of the HPP structure. That is an important aspect of the proposed model. It issupposed that there are LNs specific for equipment or for devices. The class LNClasscan be associated to equipment (through the class EquipmentType) or to devices (throughthe class DeviceType). The complete relationship is realized through the abstract classComponent, which is a generalization of the classes Equipment and Device.

It is important to note that, actually, considering the way that the NL classes of theIEC 61850 standard are organized it is not always possible to do a relationship from oneto one (one equipment or one device for each LN). Thus, utilizing the data models of thecurrent edition of the IEC 61850 standard, a LN can have relation with an equipmentand also with distinct devices at the same time (it is not according to the representationshown on the class diagram). That question is discussed in the Appendix C “IEC 61850Issues”, in the Section C.8.

The proposal of connections for equipment (classes Terminal and Connections) is themost simple possible. Terminals are connection points of the equipment at the schematiclevel. Once that a equipment is defined, its terminals exist implicitly. The connectionsdefine which terminals are connected together. The detail of the devices connections arenot represented in the model, but it is considered that the devices are connected to theirrespective equipment. If necessary, the class Device can be associated to the class Terminal.

Note that, that approach is different of the “terminals” and “connection nodes” spec-ified in the IEC 61850 standard [85]. Here the connections are used to connect differentelectromechanical equipment.

It is possible to define the terminals and connections in the description (Chapter 5“Description of the Generating Unit”), but it is not necessary.

Remember that, the LNs have many optional DOs. Thus, in the modelling, normallynot all the DOs of a specific LN class are used. That is an aspect that can be improvedin the IEC 61850 standard. A proposal of solution is presented in the Section 6.11 andsome suggestions are shown in the Appendix C “IEC 61850 Issues”.

The classes of the figure which already were introduced in the Chapter 5 “Descriptionof the Generating Unit” (Figure 5.2) are now simplified. To see all the attributes andrelationships, please look at the original figure.

The purpose here is only the modelling of the HGU (including the sensors and actu-ators functions for automation). Thus, the automation system specific functions are not


included in the model (that issue is addressed in the Section 8.12). It means that the LNsused here are applied for the process level functions.

The model contains only the functional structure and the product structure, the com-munication model is not represented in the figure. It can be considered similar to the onespecified for substations.

The idea of “containers” of the IEC 61850 standard (part IEC 61850-6 [85]) is notapplied here.

The mappings of the functions of the equipment of the HGU for the IEDs are estab-lished with the proposed model. The mapping is the link of the functions associated tothe HGU description to the LNs of the IEDs. As in this research the existence of appro-priated IEDs on the market is not important, the mapping consists in to choose the LNsthat correspond to the functions, in other words, the LNs that has as DOs the points ofthe description.

The approach of the proposed model has as advantage allowing to use the same ref-erence for the function and the product. However, it also can be seen as a disadvantage,once that the two aspects become hard connected (there is a loss of independency).

The short addresses used for communications are not discussed here. Anyway, it ispossible to create short address within the communication system.

The electrical parts (as, for example, the circuits of the case study cited in the Sec-tion 5.6) could be modelled using the original conceptual model of the IEC 61850 standard.However, that approach would cause the increase of complexity of the conceptual modeland also could generate confusions. Anyway, a deeper analysis should be done to evaluatethat solution.

The relationship of the systems (class System) with the IEDs is discussed in the Chap-ter 8 “Generating Unit Automation” (illustrated in the Figure 8.4).

7.2.3 Hydroelectric Power Plants Scheme

As cited above, the IEC 61850 model for substations represented by the Substationsection is not feasible for HPPs (as the proper name indicates). Considering the propo-sitions established, a basic (partial) new scheme for a HPP, called here of PowerPlantsection, is presented in the Figure 7.2.

Note that, the proposed scheme has one level more than the actual scheme (the Substa-tion section) specified in the IEC 61850 standard [85] [83]. Also note that, the “subsystem”defined above is included in the scheme.

The process LNs can be associated to equipment and devices (the abstract elements“components” - see the Figure 7.1 - related to them are not explicitly shown in the scheme


<PowerPlant><GeneratingUnit>

<System><Subsystem>

<Equipment><LNode ><Device>

<LNode ></Device>

</Equipment></Subsystem><Connection > . . .

</System></GeneratingUnit>

</PowerPlant>

Figure 7.2: Scheme for hydroelectric power plants “PowerPlant section”.

and are not necessary).The basic scheme presented in the Figure 7.2 does not cover the whole HPP. A complete

scheme for HPP should consider other elements besides the HGU as, for example, thereservoir (with dams, spillways, sluices, etc.) represented in the Figure 7.1.

The basic types definitions of each element of the structure are not detailed in thisreport.

The diverse kinds of electrical machines should be considered in the modelling of theGeneratingUnit to obtain a more generic structure, which could be applied to diverse typesof power plants (utilizing different primary sources of energy). In this way, the proposedscheme can be utilized for any type of power plant.

The integration of the PowerPlant section and the Substation section should be an-alyzed in more details. Examples of subjects are the necessity of a voltage level for theHGU and the connections. Also it is important to analyze the integration (harmony) ofthe proposed model with the CIM model [138].

For the secondary systems, the ideas of “functions” and “subfunctions” of the Substa-tion section can be applied, if they are extended. The LNs related to secondary functionsand subfunctions can be allocated inside any level, from the PowerPlant level until theEquipment level. The functions of the devices (Device level) are intrinsic to them. Thatissue is detailed in the Chapter 8 “Generating Unit Automation”, in the Section 8.12.

Finally, note that, the proposed structure also can be utilized in substations. Forexample, the system may be any bay, the equipment may be circuit breakers and dis-connectors and the devices may be any device of measure, automation, protection or


monitoring associated to the equipment.To implement the proposed solution, some modifications in the restrictions of the

IEC 61850 standard references (introduced in the Chapter 6 “IEC 61850 Standard andCommunications”) are necessary. The next section discuss that question.

7.3 Naming

There are several possibilities for the names of the elements presented in the Figure 6.6“Objects names and references syntaxes” (on the page 83). The IEC 61850 standard illus-trates some options and also there are many published works about namings. Rememberthat, as presented in the Section 6.7, there are restrictions to define the names.

Here the functional naming is defined by the proposed HPP structure, presented inthe introduction of this chapter, at the Section 7.1. Besides, as proposed in that section,in this research it is used a single naming for both the functions and the products. Thus,the product naming also is directly influenced by the HPP structure.

The Figure 7.3 shows a graphical representation of the proposed naming and references.Some words “name” and “logical nodes” were omitted for the figure looks more clear. Thenumbers in the figure are the maximum lengths in characters.

Figure 7.3: Proposed objects names and references syntaxes.

The character underline “ ” is utilized as breakdown symbol in the LD reference. The


character baseline dot “.” is utilized to separate the names in the hierarchy of the LNreference.

There are diverse ways to identify the IEDs. Some projects (for example [16]) haveused alphanumeric codes to identity the IEDs, but here are used (short) abbreviations ofthe names of the systems associated to the IEDs (long abbreviations also can be used -see the explanation below). That approach has the advantage of better semantic.

As can be seen in the figure, the IED name is a concatenation of the HPP name,the HGU name and the system name. For example, a possible IED name (consideringthe example of the Section 5.6) is: “ITA U01 MBear”. It refers to the “Middle Bearings ”system of the unit “01” of the “Itaipu power plant”.

In the case of redundancy of IEDs, a discriminator, for example the letters “A”(for main 1) or “B” (for main 2), should be added at the end of the IED name(“ITA U01 MBear A” and “ITA U01 MBear B”, respectively).

The LD name is composed by the IED name (which is unique within the HPP) and bythe subsystem name. Thus, the LD name is unique within the communication network,since the subsystem name is unique within a system (represented by the IED).

In a few situations the LD name (created using the approach above) is not enoughto the complete semantic identification of the application function of all associated LNs.Thus, additional identification are added to the name using the LN prefix. One moretime: the standardization of LN prefixes has advantages and disadvantages.

Also there are many options for the prefixes of the LNs. Initially the first edition ofthe part IEC 61850-7-410 of the standard [18] and now the technical report IEC 61850-7-510 [63] presents some LN prefixes only as recommendation1. They present a table of“recommended LN prefixes” with 22 items (initially 17 items). However, considering thecase study of this research, that table is not enough. Curiously, some abbreviations ofthat table are different of the abbreviations specified in the standard.

In this research it is proposed to use a mix of the data of the equipment and device(created in the description - Chapter 5 “Description of the Generating Unit”) for iden-tification of the purpose of the LNs. In fact, as explained in the next paragraph, theabbreviations of those data are used.

The abbreviations defined in this research are used to form all the necessary names forreferences. Those abbreviations are listed in the Appendix A “Abbreviations”. Despitethe abbreviations defined in this research, for obvious reasons the names of the DOs(and naturally the names of the DAs) are exactly as defined in IEC 61850 standard(even including those identified problems related in Appendix C “IEC 61850 Issues”, at

1As stated in the standard: “the user may decide on another method to identify the purpose of logicalnodes for control functions.” [63].


Section C.6).The basic functionality is identified by the LN and the prefixes identify the equipment

to which the LNs belong. Note that, in some cases that solution can produce pleonasmin the references, but it is not a big problem. The instance number of the LN is usedfor identification of similar LNs in the same equipment of the same LD (the LN referencemust be unambiguous within a LD).

The Table 7.1 presents the lengths of the abbreviations for the elements of the Fig-ure 7.3 in characters (letters or numbers) considering the short abbreviation approach.Those values are based in the case study of this research, in which the reduction of lengthwas sought. Thus, in the general case some space must be added (increasing the maximumvalues) to avoid limitations.

Table 7.1: Lengths of (short) abbreviations of the elements for references.

Element Minimum MaximumSystem 3 10Subsystem 3 8Equipment 3 8Device 3 9

The Table 7.2 presents the minimum and maximum lengths for the parts of the LNreferences of the IEC 61850 standard. Note that, the LN instance utilized here is not onlya number.

Table 7.2: Lengths of the parts of the IEC 61850 references.Part Short Long

Minimum Maximum Minimum MaximumLN prefix 3 16 5 24LN instance 2 7 3 12LN name 13 31 15 44

In the LN name are considered four additional characters: two underscores “ ” asbreakdown symbols and two digits for instantiation of identical LNs.

As can be seen, the table present two values for each element: “short” and “long”.The short is the length of abbreviations presented in this report. An alternative methodfor define the abbreviations utilizing more characters also can be used, to obtain moreclear abbreviations, although, the length is greater (indicated in the column long of thetable). The LD name also can be composed without using abbreviations, due to the great


length reserved for it in the current edition of the IEC 61850 standard, but it is a not toopractice solution.

Thus, it is suggested to change the lengths specified in the IEC 61850 standard tothe maximum values presented in the Table 7.2 plus a space for some extra characters,for example (considering the short approach): LN Prefix 20 characters; LN Instance 10characters; LN name 38 characters. That suggestion does not include the characters toimprove the semantic of instantiable DOs described hereafter, in the Section 7.5. Notethat, the length of the LD name specified in the IEC 61850 standard is enough for anysituation presented here (the length do not need to be changed).

Note that, the global lengths specified in the edition 2.0 of the IEC 61850 standard[114] are greater than the lengths proposed here. But, the problem is the lengths of theLN prefix and LN instance, which should be greater.

Also note that, the protection functions and substations applications are not consideredin the analysis presented here.

It is possible to use mnemonics or codes (like as presented in the Chapter 5 “Descriptionof the Generating Unit”) to create the LN prefixes. In that case, there is no need to changethe length of the prefix currently specified in the IEC 61850 standard. However, it will benot possible easily to know the exact functions of the LNs in application context (thereis a lose of semantics).

The references have direct impact on the messages configuration (at publish-ers/subscribers and clientes/servers). Thus, the IEDs and the software should supportthose references. In the development of the case study presented in this report it is as-sumed that the IEDs and associated software are compatible with the references proposedhere.

An alternative way to define the naming and references (represented in the Figure 7.3)is to include the equipment in the LD name. That approach can solve the problem relatedto the small length of the LN prefix, but there is the disadvantage of lost of flexibility.Thus, that alternative is not recommended.

The IEC 61850 standard sometimes includes the equipment in the LD name and othertimes does not include it. However, apparently, the IEC 61850 standard specify that theLD name does not include the equipment, but only the names related to the substation,the voltage level and the bay. There is no references to HPPs.

Another alternative way to define the naming and references is presented in the Fig-ure 7.4. Note that, the “IED instance” is included in the LD name. The other parts, afterthe slash of the Figure 7.3, do not change. That alternative allows to distribute LDs (andLNs) of one system of the HGU in distinct IEDs.

That last approach is similar to the product naming specification, thus it also can


Figure 7.4: Alternative logical device name composition - product aspect.

be used for that purpose. Note that, also it is possible to discharge the HPP and HGUidentifications and use only an IED identification (a free name, including any currentmnemonic solutions).

The alternative shown in the Figure 7.4 is only illustrative and to show that it ispossible to use the naming proposed in this research from a product aspect standpoint.That composition of LD name is not applied in this research. Having one IED for eachsystem of the HGU is considered here the best approach (see the Section 8.9). Thus, theproduct naming is not necessary2 (or it can be considered equal to the function namingdefined here).

7.3.1 IEC 61850 Standard References Modification

The structure of LNs (and references to the DAs, or according to the IEC 61850 stan-dard: DataAttributeReference) existing in the current edition of the IEC 61850 standardis considered here not totally suitable for HPPs. The structure was specified thinking inthe substations cases, where the equipment are limited (a few types of equipment) andgrouped by bays. Thus, in substations cases it is enough to define smaller prefixes to theLNs names.

On the other hand, for a complete semantic description of equipment and devices inHPPs it is necessary to increase the number of characters reserved for LNs names in theIEC 61850 standard (currently - Edition 2.0 - it is possible to use 12 characters includingthe prefix and instance). Once the instances may simply be a number (for differentinstances, although it can be also used to improve the semantic), the need is to increasethe number of characters for the prefixes. Moreover, the number of characters reservedfor the LD names is too large (currently - Edition 2.0 - it is 64 characters).

2Some authors consider that the existence of a product view and a functional view and the decouplingof them is a key concept of the IEC 61850 standard.


Suggestions of lengths for the prefix and the instance of the LN names are presentedin the Section 7.3.

7.4 Practical Issues

This section presents some practical issues for the modelling.The creation of subsystems (or definition of LDs) should be done after the complete

description. Once that the description is ready, the equipment are grouped in subsystems.It is believed that it is the best way to work. The description without subsystem guaran-tees that the device is unique in the system. Anyway, if the user prefer, he/she can definethe subsystems in the moment that the equipment are created.

In some cases the subsystem can looks like a redundant data. Although, it alwaysshould be defined to follow the proposed pattern.

The LNs are selected according to the types of equipment and type of devices. Intheory, the relationship between those elements and the LN classes of the IEC 61850standard should be one to one.

Each kind (type and direction) of point (instances of the class Point) defined in thedescription is mapped to a DO category, presented in the Section 6.6.

Some commercially available IEDs do not follow completely the requirements of thedata model (parts IEC 61850 7-x) of the IEC 61850 standard. Thus, in the implementationphase, unfortunately, some adjust may be necessary.

The use of the generic LN “Generic Process I/O - GGIO” (and the “Generic AutomaticProcess Control - GAPC ” in the automation) should be avoided.

After the modelling of all systems of the HGU, perhaps it can be concluded that thedefinition of systems (Table 2.1) should be modified. Some systems can be too small or tobig from the automation standpoint. For example, the power transformers of the system“Excitation” and its associated equipment and devices can be placed in a new systemindependent of the original. Once that all the process modelling is done, various analisescan be realized.

From the point of view of work, the changes above are not difficult. As all data arestructured and object-oriented, it is necessary only to change the objects of the classesSystem and Equipment. However, that procedure must be done before the automationdesign.


7.5 Case Study

In this section it is verified if the proposed conceptual model for modelling is suitableto solve the problem. The chosen system is the lubricating and cooling system of the“middle bearings”, introduced in the Section 4.4.

In this chapter are included only the LNs of the HGU (based on the description ofthe Chapter 5 “Description of the Generating Unit”). The LNs of the automation system(without considering the LNs of sensors and actuators) are not include here (this is anissue of the Chapter 8 “Generating Unit Automation”).

Remember that, as shown in the Section 5.6, the formal name of the case study systemin this research is “Middle Bearings” that is abbreviated by “MBear”.

7.5.1 Logical Devices and Logical Node Classes

This subsection define the LDs and present the LN classes necessary to model the casestudy system. The data of the description (Chapter 5 “Description of the GeneratingUnit”) and the conceptual model proposed in this chapter are used.

The Table 7.3 presents the subsystems defined for the “Middle Bearings (MBear)” sys-tem. Each one of those subsystems are associated to one LD (see the Figure 7.1).

Table 7.3: Subsystems of the “Middle Bearings (MBear)” system.

Subsystem AbbreviationControl Power Supply CPowSupCooling CoolGuide Bearings GBearHuman Machine Interface HMInterLubrication LubMotor Power Supply MPowSupThrust Bearings TBear

The subsystem “Control Power Supply (CPowSup)” could be called “Automation PowerSupply (APowSup)”, because normally it also serves the protection system. The name“Control” was maintained because it is an established term.

The Table 7.4 presents the LN classes used in the modelling of the “Middle Bearings(MBear)” system. The table also shows the quantity of instances of each LN class.

Note that, the LN classes LPHD and LLN0 are not presented in the table (because theyare mandatory).

There are 32 instances of the LN class STMP, related to the 16 thrust bearing pads and16 guide bearing pads. As stated in the Section 4.4 in the introduction of the Chapter 4


Table 7.4: Logical node classes of the “Middle Bearings (MBear)” system.

Logical node class InstancesICPB 1

KPMP 2XMCB 3PTTR 1PTUV 2SFLW 1SLEV 1SPRS 1STMP 33SWIO 1XFUS 1

“Case Study”, it is considered that each pad has a temperature sensor (the real systemhas sensors only in a few pads). That construction allows to verify the most completecase, which demands more resources of the IED and communications. Also it is possibleother configurations, for example, utilizing an additional IED only to obtain those kindof data (IED for interface).

Remember that, as stated in the Section 6.11, for each LN of the group “S - Supervisionand Monitoring” it is considered that exist one associated LN of the group “T - InstrumentTransformer and Sensors”3. The last ones are not explicitly presented in this report, forsimplification reasons. For example, associated to the Table 7.4 also should be consideredthe following LN classes (and respective quantities of instances): TFLW (1); TLEV (1); TPRS(1); TTMP (7).

The following LN classes, defined in the Section C.5 of the Appendix C “IEC 61850Issues”, were created in this research (thus they are not specified in the current edition ofthe IEC 61850 standard):

• ICPB: Conventional Panel Board Interface;

• SWIO: Water in Oil Sensor;

• XMCB: Miniature Circuit Breaker;

Note that, considering the atual edition of the IEC 61850 standard, it is suppose thata new LN class TWIO also is necessary.

The LN classes presented in the Table 7.4 are used in the next subsection to createthe instances (the LNs).

3Perhaps the LNs of the group “T - Instrument Transformer and Sensors” are not necessary: see thediscussion in the Section C.8 of the Appendix C “IEC 61850 Issues”.


7.5.2 Logical Nodes and References

Using the data of the last subsection and the idea presented in the Section 7.3, il-lustrated in the Figure 7.3, the LNs are instantiated and the references to the DOs (theDataObjectReference’s) are created. The references of the “Middle Bearings (MBear)” sys-tem are presented in the Table 7.5, grouped by LDs.

Table 7.5: References of the data objects of the “Middle Bearings (MBear)” system.Data object reference Data object reference

Coo/WPipe SFLW.Flw Lub/OTank SLEV.HiTrip1Coo/WPipe SFLW.LoAlm1 Lub/OTank SLEV.LevPcCoo/WPipe SFLW.LoTrip1 Lub/OTank SLEV.LoTrip1CPowSup/125VdcCirc PTUV.Op Lub/OTank STMP.HiAlm1CPowSup/125VdcCirc1 XMCB.Pos Lub/OTank STMP.HiTrip1CPowSup/125VdcCirc2 XMCB.Pos Lub/OTank STMP.TmpGBear/GuiBPad01 STMP.HiAlm1 Lub/OTank SWIO.AlmGBear/GuiBPad01 STMP.HiTrip1 MPowSup/460VacCirc2 XMCB.MagGBear/GuiBPad01 STMP.Tmp MPowSup/460VacCirc2 XMCB.PosGBear/GuiBPad02 STMP.HiAlm1 MPowSup/460VacCirc2 PTTR.OpGBear/GuiBPad02 STMP.HiTrip1 MPowSup/460VacCirc2 PTUV.OpGBear/GuiBPad02 STMP.Tmp MPowSup/460VacCirc2 XFUS.Alm

... TBear/ThrBPad01 STMP.HiTrip1GBear/GuiBPad16 STMP.HiAlm1 TBear/ThrBPad01 STMP.HiTrip2GBear/GuiBPad16 STMP.HiTrip1 TBear/ThrBPad01 STMP.TmpGBear/GuiBPad16 STMP.Tmp TBear/ThrBPad02 STMP.HiTrip1HMI/IPanel ICPB.But1 (Turn On) TBear/ThrBPad02 STMP.HiTrip2HMI/IPanel ICPB.But2 (Turn Off) TBear/ThrBPad02 STMP.TmpHMI/IPanel ICPB.Sw1 (Remote) ...HMI/IPanel ICPB.Sw2 (Pump One) TBear/ThrBPad16 STMP.HiTrip1Lub/OPipe SPRS.Ind (Normal) TBear/ThrBPad16 STMP.HiTrip2Lub/OPump1 KPMP.Oper TBear/ThrBPad16 STMP.TmpLub/OPump2 KPMP.Oper

For simplicity, the DO references presented in the Table 7.5 are not complete. Forexample, the complete references to the DOs of the water pipe of cooling (the first threereferences in the table) including the HPP identification, for example “ITA” (for Itaipupower plant), the HGU identification, for example “U01” (for the unit 01), and the iden-tification of the system, in that case “MBear”, are:

ITA U01 MBear Coo/WPipe SFLW.FlwITA U01 MBear Coo/WPipe SFLW.LoAlm1ITA U01 MBear Coo/WPipe SFLW.LoTrip1


Those three DO references belongs to only one LN, the LN“ITA U01 MBear Coo/WPipe SFLW”, where ITA U01 MBear Coo is the LD name, SFLW isthe LN class4, and WPipe is the LN prefix. The parts after the baseline dot “.” are theDOs names. Note that, the last two DOs follows the pattern stated in the Section 6.11of the Chapter 6 “IEC 61850 Standard and Communications”.

The instances associated to the LN classes LPHD and LLN0 are not presented in thetable, also for simplicity.

Note that, not all existing bearing pads are presented in the table (but only the padsnumber 01, 02 and 16, the other are identical - only their identification numbers aredifferent).

The part of the references related to the DOs are according to the IEC 61850 standard(utilizing the abbreviations defined in the standard) and the other parts are according tothe abbreviations defined in this research (listed in the Appendix A “Abbreviations”).

Note that, since there are multiple instances of specific LN classes (Table 7.4) in thesame LD, they are differentiated through their prefixes and/or instance numbers.

Remember that, as stated in the Sections 6.6 and 6.7 of the Chapter 6 “IEC 61850Standard and Communications”, generally the DAs references (and the FCs) are notpresented in this report.

In a few cases, according to the DO specification and its utilization there is a poorresult. In the analyzed system, the semantics of the references are not complete for theLN IPanel ICPB. For example, in the case of the push buttons for local commands areused as DOs: But1 and But2. For clarification, a complement (which is not part of thereference) is presented between parentheses besides the DO. In other systems that usemany instances of the DOs of the LN class ICPB, for example (the DO Sw in) the “IntakeGate (IGate)” system, that question is more relevant. In fact, in the application of anyLN class which the DOs can be instantiated that problem can occurs. It is due to thereference construction of the standard.

A solution is to include data in the reference. For the LN classes related to alarms,trips and indication that problem is partially solved (as explained in the Section 6.11.1).For a complete solution, it would be possible to add data in the LN suffix, but in thatcase the length of the suffix specified in the current edition of the IEC 61850 standard isnot enough (it would be larger). Besides, that solution has other consequences. A worstsolution (not recommended) is to specify LN classes for each situation.

It should be clear that other approaches of modelling for the studied case (the “MiddleBearings” system) are possible. For example, as already cited, the part IEC 61850-7-510

4The LN class “Supervision of media flow - SFLW” [17] is used to represent devices that supervise themedia flow in a major plant object (for example, a pipeline or tube). It provides alarm and trip functions.


of the standard [63] presents a very different solution for the bearings system (althoughthe systems presented here and there are not identical).

7.5.3 Schematic Diagram

The Figure 7.5 (on page 117) shows a simplified diagrama of the “Middle Bearings(MBear)” system with the references defined in the last subsection.

Note that, as detailed in the system description (5.6), the power supplying of thetwo pumps are different, besides the composition (components) of the circuits also aredifferent. That configuration reflects the real implementation. The data associate withthe points of the “Motor Control Center (MotContCen)” system and other related data arepresented in the Appendix B “Case Study of Other Systems” (see Table B.20). As canbe seen, the proposed models created in this research are flexible.

Also note that, as defined in the Table 5.2, the alarms and trips referring the guidepads and thrust pads are different.

As exemplified in the Chapter 5 “Description of the Generating Unit”, the names arecompletely configurable. The changes of names are reflected in the references (which usethe abbreviations of the names). Following the example cited in the Section 5.6 (to use“Sump” instead of “Tank”), the results would be:

ITA U01 MBear Lub/OSump SLEV.HiTrip1ITA U01 MBear Lub/OSump SLEV.LevPc

ITA U01 MBear Lub/OSump SLEV.LoTrip1ITA U01 MBear Lub/OSump STMP.HiAlm1ITA U01 MBear Lub/OSump STMP.HiTrip1

ITA U01 MBear Lub/OSump STMP.TmpITA U01 MBear Lub/OSump SWIO.Alm

Note that, if a point is changed (new name, type, etc.), that change must be propagatedthroughout the data information of the system.

The displays of the HMI for real-time operation can be implemented based on theschematic diagrams. They should be complemented with other information of the au-tomation system. The displays must consider the ergonomics requirements, which canresult in modifications of the schematic diagrams (on the HMIs). In some cases otherdisplays, completely different from the schematic diagrams, can be better for real-timeoperation. The ergonomics should be considered.

The same software and displays used in the HMI of the centralized level can be usedin local level. Naturally, both levels can have specific displays (not utilized in the other


Figure 7.5: Schematic diagram of the “Middle Bearings (MBear)” system with references.


level). That standardization improve the scalability and it is good for the implementation,operation and maintenance.

7.5.4 ICD file

Remembering the Section 6.10, each IED has an ICD file. In this subsection is createdone ICD file (containing the LDs, LNs and LN types) for the specific IED of the “MiddleBearings (MBear)” system, as example of capability file. The file is presented in theAppendix D “SCL Files”, at Section D.2.

Note that, in this research it is considered that the HGUs have conventional equipment.Thus, the LNs (and LDs) necessary to modelling those equipment are in the frontier IEDs(here they are the same IEDs responsible by the distributed automation). Possibly in thefuture, if modern equipment (IEC 61850 compliant intelligent equipment - as introducedin the Section 3.4 and illustrated on the Figure 3.6) are used, the equipment themselveswould have the necessary boundary LNs. In that hypothetical situation, the data modelingpresented in this chapter also can be applied, just defining appropriated relationships withthe modern equipment.

Also note that, the ICD files defined in this research have the LNs of the primaryand of the secondary systems, but for now the focus is on the process (the LN for thesecondary systems will be approached in the Chapter 8 “Generating Unit Automation”).

Remember that, the proposal of this research is not to elaborate an executive project,but to define procedures and methods to succeed in achieving it. Besides, in this researchthe vendors and models of the IEDs are not defined, in fact those devices are not availableon the market yet (but here it is assumed that they exist).

As can be supposed, the CID files will not be addressed in this research by the reasonsstated above. In the practice the CID files are created by the specific “IED configurationtools” using data from the SCD file. Note that, apparently the IEC 61850 standard alsoallows the configuration of IEDs without the CID file (it is optional), a vendor specificfile can be used in the configuration process.

The SCL file presented here can have some minor errors because it is “handmade”,using the information of the IEC 61850 standard (software tools were not used). Besides,the file was not checked in a test suite. The aim is only to present a simple example.


7.5.5 Summary of the Characteristics of the Modelling


Modelling an automation system strictly according to the IEC 61850 standard is nota easy work. Finding and choosing the appropriated LNs (and DAs) to model the realphysical systems are difficult tasks. The idea created in this report, describing the systembefore modelling it, can help in that task. Anyway, adequate software tolls are necessary.

It is believed that the proposed functional structure for HGUs make the modellingprocess more near to the reality of the HPPs. Besides, the conceptual models proposedfor modeling are suitable for lager HGUs. The results obtained in the case study aresatisfactory. Naturally, they can be improved.

The proposed solution somehow unify the functional and product namings. Thatapproach presents advantages and also a couple of disadvantages, as explained in thischapter. The main disadvantage is that the independency between the aspects is lost.

If any part of the LD name and/or the LN name is defined by the vendor (a fixedpart) the proposed naming define here is yet possible, because it needs few characters.The length of the LN prefix is the main restriction (and in specific cases, a problem).

The custom parts of the names proposed in this report together the standardizednames of the IEC 61850 standard provides an intuitive description for the automationsignals (in a few very specific situations the semantic description is not complete, butalternatives are presented in this chapter). However, it is not easy to implement thatsolution. One difficulty is that, currently, each manufacturer decides which functionsare provided, or are available, in its IEDs and sometimes he/she also decides inclusivethe LDs organizations. The manufacturers typically provide IEDs with some predefinedfunctionality, however with no context to the project specific usage. The configurationsfor a specific usage are limited. Implementing the idea proposed in this research requiresmore flexibility of the commercial IEDs.

It would be good if the manufacturers gave freedom to the customers (concessionariesand integrators) to define the names according to the IEC 61850 standard. A free defini-tion of names can facilitate the specification and, then, the complete engineering process.Nowadays, the computing technologies allow that freedom without much difficulties.

In fact, the comments above are for IEDs applied in substations. It is still very rareto find IEDs for HPPs on the market. That solution is hardly offered by the vendors.Obviously, there are other issues than technical involved (commercial, for example).

Considering the equipment and devices defined in the description (Chapter 5 “De-scription of the Generating Unit”), the current edition of the IEC 61850 standard does


not have all the LN classes necessary for HPPs. The new LN classes proposed in thisresearch (listed in the Section C.5) could be seen as extensions of the standard. However,it would be better that the standard be revised to possibly include some new data models.Besides, also it is proposed to modify some LN classes (listed in the Section C.4) specifiedin the current edition of the IEC 61850 standard. Note that, as this research is one of thefirst analytical works about HPPs, more studies and analyzes (and, naturally, the normalcritical process for updated the IEC publications) are needed for possible modification ofthe IEC 61850 standard. Practical experiences also are very important for the criticalanalysis of the standard, but those experiences are not known.

Even creating some LN classes (not specified in the IEC 61850 standard) it was nec-essary to use the instances of the LN classes GGIO.

The LDs presented in this research are only to validate de proposed models and to showthe effectiveness of the methodology. According to IEC 61850 standard, the grouping offunctional elements (the LNs) in LDs is free. That approach makes the standard flexible.By other hand, if the LDs also are defined in the standard some advantages will arise, forexample the standardized development of applications. This research suggests that theremust be a balance between the two options. Thus, the LDs defined in this report (after adetailed revision and consolidation) can be seen as a reference to design the automationsystems for HPPs.

The Chapter 6 “IEC 61850 Standard and Communications” present some criticismsabout the standard. Here also are presented (or reinforced) some criticisms consideringthe practical aspect.

Some of the conceptual data models of the IEC 61850 standard are difficult to under-stand. Some parts are ambiguous and can lead to different interpretations, which hindersthe application of the standard and can cause other problems. Thus, it is suggested toinclude more detailed descriptions and explanations. In fact, the IEC has done an inter-esting work creating technical reports as, for example, the already cited IEC 61850-7-510report. However, the reports also need to be improved (to be clearest).

Besides, the IEC 61850 standard contains some complex LN classes (although it isnot the idea of a LN). Sometimes the column “explanation” of the tables of LN classes inthe IEC 61850 standard is not enough to understand “what for” and/or “how” the DOsshould be used. Thus, it is suggested to improve some explanations.

The problems presented above are normal, considering the size and complexity of theIEC 61850 standard and also the fact that it is a relatively new standard. They can beresolved in appropriated time.

Other problems are regarding the software tools. In systems with a great quantity ofequipment and devices, the definition of the LNs, LDs and then the references is time


consuming and subject to errors. Thus, the existence of effective software engineeringtools is very important. Similarly, the software tools also are necessary to create thedescription of the systems. Finally, some mappings and namings (as the presented in thisreport) can be “masked” by the engineering tools, in a way that the work become easierfor the engineers.

The structured data and standardization of naming and functioning is a tendencyin the engineering processes. Those characteristics allow to create a reference modelarchitecture. The reference architecture together libraries of components and templatescan be seen as a reuse engineering methodology to develop new projects in a efficient way.The models created in this chapter are utilized to develop the logical architecture of theautomation system and, then, to consolidate the physical architecture.

The modellings presented in this chapter are not exhaustive. As the systems arecomplex and there are more than one way to model them (with possible advantages anddisadvantages), more time is necessary for analyses and for concluding about the bestmodellings according to defined criterias. Specific analyses of modelling are suggested asfuture works. The data of the case study also should be reviewed.

Chapter 8

Generating Unit Automation

“Ideas control the world.”James Abram Garfield (1831-1881)

8.1 Introduction

In the context of this research, the automation system deals with the operation of theHGU (as introduced in the Section 1.1). It can be seen as the the intelligence of the HGU,in contrast to the electromechanical equipment.

The electromechanical equipment of large HGUs are usually installed in a relativelywide area. Those equipment interact with each other in a coordinated way to generateelectricity. The automation system supervises and coordinates the interactions of theequipment, controlling the process. For that purpose, the automation system must beable to acquire, process, transfer and store the data of the process.

This chapter address the automation system and its logic functionalities, which areresponsible by the above cited interactions. Initially some concepts and definitions aboutautomation of HGU and related standards are introduced, and them a methodology and aconceptual model to develop the logics of automation are proposed. Some implementationissues also are discussed. At the end, a case study is presented.

The proposed automation system is composed of stand-alone controllers, the PLCs (orIEDs using the IEC 61850 standard nomenclature), connected though data communicationnetworks. Each controller is considered a completely independent device capable of peer-to-peer communications (directly with others controllers). That communication capacityallows any interchange of data using the established LNs. The physical architecture of theautomation system, including the controllers, is detailed in the next chapter (Chapter 9“Automation System Architecture”).

Chapter 8. Generating Unit Automation 123

Considering the proposal of distribution of IEDs for systems (introduced in the Sec-tion 3.6 and explained below, in the Section 8.9), the allocation of LNs is somehow simple,because they are well defined by the systems that they belong to. In each system there isa “main” primary equipment that compels the definition of the necessary LNs. Thus, itis clear which LNs must be allocated in each IEDs. Anyway, an effort for go into detailsof the allocation of functions is necessary.

Each IED hosts basically two categories of LNs. The first category includes the LNsthat are used to model the parts (equipment and devices) of the HGU. The second categoryincludes other LNs dedicated to implement the automation of the HGU (the automationfunctions, disregarding the sensors and actuators - already associated to the primaryequipment). That second set of LNs is the main subject of this chapter.

The modularization of the interface of the automation functions provided by the IEC61850 standard through the object-oriented approach allows, and can facilitate, the imple-mentation of the distributed automation. Similarly to the representation of the functionsof the HGU (primary system), the automation functions (secondary system) representa-tion is decomposed in LNs.

This chapter can be seen as responsible for the description and modelling of the sec-ondary system. Similar to the modeling of the functions of the HGU (Chapters 5 “De-scription of the Generating Unit” and 7 “Modelling of the Generating Unit”), now thefunctions of the automation system are modeled. In addition, this chapter also deal withthe logics of automation, which are implemented using the data of the modelling.

The interfaces of the automation functions are implemented here using the data modelsdefined in parts IEC 61850-7-4 [116] and IEC 61850-7-410 [17] of the standard. Thus, theinterfaces are vendor independent. As cited above, the required automation functionsdefine the necessary data, or in the IEC 61850 standard vocabulary, the LNs with theirDOs (and DAs). All automation logics, including the interlocks, are created using thoseLNs. That is a new solution for the design and implementation of automation systemsfor HGUs.

The next sections introduce some concepts and definitions necessary to develop theideas of this chapter.

8.2 Automation Considerations

This section presents some considerations regarding the automation in this research.They are illustrative, once there are other considerations and details not presented here.

The pumped-storage HPPs are not addressed in the research. It is considered that theHPP operation mode is “active power production”. Also it is considered that the HPP


control strategy is “water flow control” and it is realized in a control level above the localcontrol. Thus, the joint generation control function, which controls the total water flowthrough the HPP, is not addressed in this research. Naturally, the joint control of thevoltage (or reactive power) is not addressed too.

The algorithms of the joint control functions are out of the scope, but the proposedsystem architecture allows to implement them in the centralized control level. All thenecessary resources are contained in the proposed architecture. The power and voltagecontrol loops of each HGU can interact with secondary control levels.

It was not realized a detailed analysis of which sensors should be modified, added oreliminated. That task can be a future work. The analyses presented in the report considerthe existing sensors in conventional typical HGUs. As the sensors are a specific processrelated issue, that question should be analyzed by experts in each part of the HGU (eachmain equipment, or system as stated in the Chapter 2 “Hydroelectric Power Plants andHydro Generating Units”). Anyway, it is suggested the use of electronic sensors instead ofmechanical sensors whenever possible. The question of the actuators shall have the sameapproach.

The control logics presented here are based in an existing conventional automationsystem. They were realized only as a case study. Thus, those logics are basic and needto be reviewed, matured, tested and duly documented. A new version is particularlyimportant if new sensors (and/or actuators) are applied. Enhancements can be madeaccording to new analysis, simulations and tests. Anyway, the presented logics can beenseen as a reference for new projects.

In some cases the control modes and locations (manual/automatic and lo-cal/centralized/remote, defined in the Section 8.4 below) are not analyzed in details andexplicitly shown in this report (diagrams, tables, figures, etc.), for simplifications reasons.Anyway, it is considered that the real automation system should take into account thecontrol modes and locations. In real implementations they must ever been included.

The analyses of the scan periods of each part of the logics are not addressed. It isconsidered that all control periods of the controllers (IEDs) are enough to execute thelogics. Besides, there is no specific analyzes to verify the timings into details and possibledeadlocks. Those analyses are important and can be done in future works. Adequatesoftware tools can help.

8.3 Levels of the Automation System

The automation systems for HPP can be divided in hierarchical “levels”, accordingto the equipment, devices, features and functionalities. Considering the large HPP five


levels can be defined:

• 0 - Process: it is the lowest level of automation, where are the interfaces with theprocess, in other words, the sensors and actuators. Thus, that level could be called“process interface”. The interfaces are close or integrated to primary equipment(introduced in the Section 2.4, which are in fact the “process” to be controlled).They allow the supervision and operation of parts of a single equipment;

• 1 - Unit (or Bay1): it includes the automation (and protection) devices. Theyare close to the process (primary equipment) and allow limited supervision andoperation of the HGU (they may have simplified HMIs). In electrical substations,usually that level is called “bay”;

• 2 - Local Station (or Local Control): it is the first control or operation level,located physically relatively close to the HGU, where are the local HMIs, the localprocessing and archiving, and other devices to supervise and operate the HGU(and the associate bay - circuit breakers). Eventually the local level is designed tooperate more than one HGU. Since the numerical technology, that level has beencalled “station”. That level also includes the main communication networks devices;

• 3 - Centralized Station (or Centralized Control)2: it is a control or operationlevel removed from the HGU, were are the centralized HMIs, centralized processingand archiving, and other devices to supervise and operate the whole HPP. It takesone or more special rooms inside the HPP to concentrate the operating data andfunctions. That level also includes the centralized communication networks devices;

• 4 - Off-Site Station (or Off-Site Control or Center of Operations): it is acontrol or operation remote level outside the HPP, where are the HMI and otherdevices to supervise and operate several HPPs (and substations) in a limited way.The off-site control is commonly called of Network Control Center (NCC) and itcan be a “national control center” or a “regional control center”, according to thegeographical area of actuation.

The definition of levels of the IEC 61850 standard [11] (“process”, “bay” and “station”)confound with the three first levels of the definition presented above.

The local control, centralized control and off-site control are supervisory levels. Thelogics of automation (and protection) are realized in the unit (or bay) level. Is it possible to

1In the cases of electrical substations.2As that level is remote from the HGU (less close than the local level), sometimes it is also called

“remote”, contrasting with the “local” level and confounding with the “off-site” level.


implement additional or complementary logics, as interlockings of commands for example,in the local control level. Also it is possible to implement secondary control logics in thecentralized control level (as already cited).

In the case of electrical substations, usually there is only one station level, the central-ized. The local station level does not make much sense in substations.

The enterprise (business) levels are not addressed in this research.The Figure 8.1 shows the arrangement of the levels above defined. Each level of the

figure has interfaces with the adjacent levels, for exchanging data (and commands). Ascloser to the primary equipment the level is (as lower in the figure), its control priority ishigher and the times of response are more critical.

Figure 8.1: Levels of the automation systems (applied to hydroelectric power plants).

The figures presented in the Chapter 3 “Evolution of the Automation Systems andProposal” can now be related to the Figure 8.1. Those figures have the first four levelsdefined here (they do not have the level “4 - Off-Site Control”). Note that, the devices forautomation are different according to the technology used (from electromechanical relaysto IEDs). In some cases devices of diverse technologies can work together.

The communications are not only vertically between hierarchical levels, but also hori-zontally inside the level (in spite of the physical location of the communication devices).For example, there are communications among the devices of the unit level (the IEDs,in the case of the modern technology) for interlocking functions. With the advancementof the technologies, the physical separation of the lower level is becoming less noticeable,due to the use of digital devices in the primary equipment.

More details about each level describe here can be found in [6].


8.4 Control Hierarchy

This section presents two important concepts regarding the categories of control (oroperation). The “mode” of control and the “location” of control.

8.4.1 Modes of Control

There are two basic modes of control:

• Manual: it consists in basic operations realized directly by the human operatorsthrough a simple order, such as opening or closing a valve. The operations in thismode are executed one by one. Usually the manual mode is used for maintenanceand testing. In addition, it may serves as a “backup” of the automatic control.Usually that mode is performed only up to the level of local control (local station);

• Automatic: it consists in sequences of operations that occur automatically fromone initiation command given by the human operators or issued from an automa-tion device, which triggers several basic commands. The basic commands follow apredefined sequence according to established states or conditions. That is the usualoperating mode of the HGU. Strictly speaking, the automatic mode applies only inthe starting preparation, starting, stopping and synchronization of the HGU. Nor-mally there is also the possibility of automatic operations performed stepwise (stepby step), coordinated by the human operators. That procedure is done for testingor returns after maintenances.

8.4.2 Location of Control

Regarding the location, the control authority is related to hierarchical levels definedin the Section 8.3. The locations of control can be:

• Local: it is performed near to the HGU, in the local station or local control level(the level 2 of the Figure 8.1), generally a “local control room”. It only covers theHGU in question. The local control supports the manual and/or automatic modes;

• Centralized: it is performed in the central station or central control level (the level3 of the Figure 8.1), generally a “central control room”. It covers the entire HPP.Normally only the automatic control mode is possible, but few manual commandscan be implemented (the actual technology facilites that function). That mode isalso called “remote”, mingling with the next mode (Off-Site). It is due to the factthat from the HGU point of view there are only the local and remote modes. From


that perspective, if the HGU is not in the local mode, it is not possible to know ifthe control is done from the central control level (central station) or from anotherremote control level (off-site level), because in both cases the communication withthe HGU is made through the first one (naturally different approaches are possible);

• Off-Site: It is also called “telecontrol”, “telecommand” or “distance command”. Itis similar to the centralized location, but the control room is located outside thearea of the HPP (off-site), in a “power system control center” (the level 4 of theFigure 8.1). The control mode is always automatic. Sometimes that level is usedonly for supervision of the process and for supplying control references (set points).

Note that, the control at the level of equipment is not considered here.Another approach for the selection of the control authority is to associate the location

of control to the current level (it is considered the reference level). In that case, there areonly two locations of control: local (the current level has the authority) or remote (thenext level - the higher one - has the authority).

The location of control can be selected by physical or logical (software) switches. Incase of invalid control switch selection or lose of communication, the control location mustbe considered on the lowest level.

8.5 Steady States of the Hydro Generating Unit

A HGU has several operating steady states. Each state is defined by a subset ofprocess variables. The elements of each subset are provided by the primary equipment.They are used in the automation system to indicate the states and to compose the logicsof automation.

The states changes are triggered by specific events. Those events can be generatedautomatically by the automation system or by commands (or orders) given by humanoperators.

The Figure 8.2 shows the main steady states of a typical HGU, as well as the transitionsbetween them. The dashed blocks represent transitory states.

The “normal operation” is the synchronized state, in which the HGU is most of thetime. In that state normally there are variations (increasing/decreasing) of active powerand/or voltage (or reactive power), according to the power grid necessity.

Not all possible transitions are shown in the figure. For example, the HGU can gofrom the state “energized” to the state “stopped” if a complete stop without blockingis requested. Another example is a “total stop” before a scheduled maintenance, whichincludes a transition from the state “stopped” to the state “maintenance”. Besides, other


Figure 8.2: Steady states and events of a hydro generating unit.

less important transient states are not shown in the figure, as for example: creeping,charging and discharging.

The stopping process of a “emergency shutdown” has some differences from a “totalstopping” (normal stopping). The details of those processes are not represented in thefigure. The closing of the intake gate is not represented too. It is supposed that when inthe states “blocked”, the HGU is physically stopped.

The IEC 61850 standard edition 2.0 has the LN class “Hydropower unit - HUNT”used to represent the generator and turbine combination which has the DO UntOpSt toindicate the status of the HGU [17]. The possible states specified in the standard are notcompletely equal to the states defined here. For example, the standard do not includethe state “maintenance” and it has only one state “blocked” (improvements are proposedin the Appendix C “IEC 61850 Issues”, in Section C.4). However, the main states arepresent in both approaches (here and in the standard).

8.6 Automation Functions

The electrical automation systems must have, basically, resources for the activities ofoperation, in a reliable, efficient and safe way, as well as resources to support the activitiesof maintenance and engineering [2]. Considering the HPP, those features are well defined.Regardless the specificities of the HPP, the functions of data acquisition and processingas well as supervision and control do not vary much among different plants.

The main functionalities of industrial automation systems are acquiring data, process-ing them, and sending commands to the plant, and also resources for real time supervisionsupervision. The electrical automation systems have as base those same functions. Besides


there are other specific related functions [4] [27].Some basic characteristics of the automation functions are presented in the next sub-

sections.

8.6.1 Supervision

The supervision is the resource of the automation system that allows the operators tosee and to follow the states of the process. Basically the variables of the process (statusesand measures) are shown in real time. Some warnings or “alarms” (defined below) alsoare shown.

The presentation of the variables differ according to the technology used for the HMI,they can be: lamps, gauges, texts, tables, graphs, etc. The characteristics of the existingHMIs in HPP according to the technology can be seen in [6].

8.6.2 Alarms and Trips

Alarms play a key role in automation systems. They keep the operators constantlyaware of the state of the process. Alarms are signals used mainly to alert the operatorsabout deviations from normal operating conditions. Therefore, the alarms are informationto help the operators keep the plant operating within safe limits.

For example, alarms are generated in situations which a measured value is below (orabove) a predefined limit. Generally the levels “low” and “high” are related to alarmsand the levels “too low” and “too high” (a second stage) are related to trips, introducedbelow.

Trips are protection signals for emergency shutdown of the HGU (they generate signalsto shut off circuits and auxiliary systems). The trips can occur due to electrical faultsor mechanical faults. In the context of electrical substations the trips are associated toemergency opening of circuit breakers.

In the HGU there are different types of trips (and “stoppings”), associated to differentfaults and conditions. Besides, some maintained alarms (measures associated to the levels“low” and “high”) can become trips after specified periods of time (using timers). Manyexamples of alarms and trips are presented in this report (in the next chapters and in theappendixes).

In addition to the alarms of the process (application functions), the automation systemalso can manage the itself alarms (system functions, as stated in the Section 2.4). That isan important new resource of the modern automation systems that contributes to improvede availability.


8.6.3 Commands

The commands are orders given by the human operators to the automation system(indirectly to the equipment) do something. An automation system of HGUs must dealwith a lot of commands. They can be grouped in “direct commands” to initiate actionsand “setting commands” to realize adjustments. Those commands act in the primaryequipment controlling their functions. The commands are directed to the equipmentthrough the actuators.

The commands can be binary or analog. The binary commands can be of two types:“open/close” (also called “trip/close”) or “raise/lower”. They are used to operate theequipment, starting/stopping any action or increasing/decreasing any value, respectively.Similarly to the raise/lower commands, the analog commands change the behavior (theyset or adjust references and parameters) of the equipment. The adjust of references andlimits of the speed governor and of the voltage regulator are examples of settings.

For more details see [5], where C. A. V. Cardoso presents an extensive list of thepossible existing commands in HPPs.

8.6.4 Starting Sequence

Basically, the “starting sequence” is a procedure that leads the HGU from the state“stopped” to the state “energized” (illustrated in the Figure 8.2). First it is realizedthe starting preparation to reach the state “preparation complete”. Then the command“start” initiates a sequence of actions that leads the HGU to the rated speed with thenominal terminal voltage.

In the process of starting, when the rotation of the HGU reaches a defined percentageof the rated speed, the logics of interlocking allows to connect the excitation system,circulating electrical current in the rotor of the generator. That current (and the magneticfield) increases while the rotation continues increasing until the terminal voltage of thegenerator reaches a value close to the nominal. In that state the HGU is operating on “noload” (excited), ready for synchronization (connection to the electrical grid). During theprocess several events occur as, for example, valves opening, pumps starting, latches andbrakes releasing, wicked gates opening.

The starting sequence is presented here in a simplistic way. J. A. Jardini [4] presentsin diagrams and figures the details of that sequence.


8.6.5 Stopping Sequence

The “normal stoping sequence” (without blocking) is practically the opposite of thestarting sequence (described in the last subsection). It leads the HGU from the state“normal operation” (or “energized”) to the state “stopped”. The load is reduced, theHGU circuit breaker is tripped, the excitation system is disconnected, etc. Generallythe operators give commands to lead the HGU from the state “normal operation” to thecondition of no load (or near to it: low load), before to order the “total stop” to initiatethe stopping sequence3. At the end of the process, the wicked gates are closed and thebrakes are applied. Then, the system of pressurized lubricating oil of the thrust bearings(the “Middle Bearings (MBear)” system, analyzed in the case study) is disconnected.

Note that, in the Figure 8.2 there are other ways to stop the HGU, such as: “partialstop”, “emergency shut off (no closing intake gate)” and “emergency shut off (closingintake gate)”. The associated sequences to those events have some differences regardingthe “total stop” described above, but are similar to it.

The stopping sequence is presented here in a simplistic way. J. A. Jardini [4] presentsin diagrams and figures the details of that sequence.

8.6.6 Logical Nodes for Secondary Functions

In the IEC 61850 standard context, the functions described above are modeled byLNs related to the secondary systems. The LNs classes that contain the data models forinterfaces of those functions are used to instantiate the LNs.

In the scope of HPPs, the LNs of secondary functions belongs to the following groups(see the Section 6.5) defined in the IEC 61850 standard [116]:

• A: Automatic Control;• C: Supervisory control;• F: Functional blocks;• G: Generic Function References;• H: Hydro power;• I: Interfacing and Archiving;• L: System Logical Nodes;• P: Protection Functions;• Q: Power Quality Events Detection Related;• R: Protection Related Functions;

3Although the stoping sequence can include the generating unit discharge.


• S: Supervision and Monitoring4.

Note that, the groups associated to the protection systems are included in the list.As stated in the Section 7.2.2, the LNs of the groups listed above can be included in any

level of the proposed HPP scheme (the PowerPlant section presented in the Figure 7.2).To have a better idea, the part IEC 61850-7-510 of the standard [63] presents examples

of how to refer a start/stop sequencer of a simple HGU with an intake gate and no inletvalve.

8.7 Intelligent Electronics Devices

As cited in the Chapter 6 “IEC 61850 Standard and Communications”, the IEDs arededicated apparatus to execute functions as measurement, automation, control, protectionand communication. It is possible to implemented several functions in a single IED. TheIEDs used to execute the logics of automation are in fact PLCs5. Thus, as already stated,the terms IED and PLC are used as synonyms in this report. According to the context(automation and control) it is possible to know that the referred IED is a PLC.

To work in the proposed solution, the IEDs should be able to receive data structured inLNs from external sources (by pairs of cooper wires6 and/or by communication networks),process them and, after that, to send data also structured in LNs to other IEDs (throughpairs of cooper wires7 and/or through communication networks). This means that theIEDs should be an IEC 61850 server and also an IEC 61850 client, besides they mustbe able to receive signals and to send commands through physical inputs and outputs,respectively, to interact with the field equipment. In the practice, the IEDs also can beable to communicate using other protocols to interface with non IEC 61850 devices. Inthat case it is necessary to map the data of the LNs. Ideally, every interface would beadherent to the IEC 61850 standard.

The IEDs associated to the front panel HMI8 (for local displays and controls) shouldbe configured according to the automation system variables to be displayed and the real

4This group is also used for modelling the process.5Programmable Logic Controllers [139] [140] [10], or simply PLCs, are microprocessor based devices,

with inputs and outputs, used to automate industrial processes. They were designed to replace electrome-chanical relays in the automation systems. Observation: the modern control devices, with more than onemicroprocessor and additional resources like a personal computer are called “Programmable AutomationControllers”, or simply PACs. In the context of this research, they also can be applied in the proposedarchitecture and, thus, are called IEDs.

6In that case, the data is received conventionally and it is structured in the IED itself.7To send data to non IEC 61850 devices or equipment.8In this research it is proposed to maintain some conventional signalizations and commands in the

panel boards (see the Section C.5.1 of the Appendix C “IEC 61850 Issues”). Thus, in some cases there isno necessity of HMI, for operation, in the IEDs.


time operations and maintenance needs. The mode and location of control (introduced inthe Section 8.4) also must be considered.

8.8 Standards for Programmable Controllers

The IEC 61850 standard is applied only for the communications, it does not includeresources for the implementation of the automation functions (the automation logics). Forthat purpose, other standards can be used as, for example, the IEC 61131 “ProgrammableControllers” standard [139], specifically the part IEC 61131-3 of the standard [141] whichcontain the programming languages. Anyway, the data used in the automation logicsshould be connected to the IEC 61850 data models. The IEC 61499 “Function blocks”standard [142] also is an option, and it is introduced here, after the IEC 61131 standard.

Below there is a brief description of the IEC 61131 and IEC 61499 standards and,then, a proposed solution for integration is presented.


The IEC 61131 standard [139] contains the the first vendor independent standardizedprogramming language for industrial automation. It is being used in a variety of appli-cations for logic implementations. One great advantage is that the programming of thestandard is independent of the hardware. That feature provides flexibility and allowsre-usability.

This research applies the IEC 61131 standard for implementation of the automationlogics. More specifically, diagrams similar to the Function Block Diagram (FBD) specifiedin the part IEC 61131-3 of the standard [141] are used.

The FBD is a graphic language for the programming of controllers. The basic elementsof the FBD are function blocks. The signals and those blocks are interconnected by ori-ented signal flow lines. The part IEC 61131-3 of the standard [141] provides the resourcesto construct and to interpret the FBDs. All graphical representations are exemplified inthat document. In this report, minor changes are done to the diagrams become moreclear (using blocks with distinctive shape instead of rectangular blocks, for example).

The IEC 61131 standard presents advantages to implementation of the logics (it is aninternational widespread standard). However, in the practice the implementation can bedone using any programming language (supported by the PLC). Besides, instead to usethe FBD, the “ladder diagrams” or the “sequential function chart” specified in the partIEC 61131-3 of the standard [141] also can be adopted. The sequential function chart hasdistinctive characteristics specifically for representation of automations as the sequences


introduced in the Section 8.6.Nowadays, the IEC 61131 standard is applied in different domains and connections to

specific hardware and software may be necessary. For integration with other standards,a XML schema designed to IEC 61131 can be used. A schema like that can allow theimportation and exportation of files. There is an IEC 61131 XML scheme [143], proposedin 2005, which is an open interface between different kinds of software tools and platformsthat allows data validation. That scheme was adopted by the industry and it also can beadopted in the electricity sector.

Some manufacturers are developing tools using other ways to integrate the IEC 61850and IEC 61131 standards. That is a feature important for the implementation of IEC61850 systems using PLCs.


The IEC 61131 standard is widely applied for centralized and also distributed ar-chitectures, but it is believed that the genuinely distributed systems (introduced below)have particularities not supported by the IEC 61131 standard. The IEC 61499 “Functionblocks” standard [142] has been developed and it seems to have more advantages for largedistributed control systems than the IEC 61131 standard.

The problem is that the IEC 61499 standard is still not widespread and there are notenough software tools for systems development [144]. Besides, the IEC 61499 standardis criticized for its inability to address the intended objectives [145] (there are divergentopinions). Anyway, the IEC 61499 standard should be considered as a solution in thecontext of this research.

The IEC 61499 standard is a well elaborated written document, but in a first review itlooks that some details are missing. Some information necessary for the implementationare not very clear. It can be cited, as example: working of the I/O readers, IP addressing,port numbers and restrictions regarding the data of the publishers and subscribers. Maybesome of those data are free and can be arbitrarily defined by the users. Fortunately, somepublications (as, for example, the book “Modelling Control Systems Using IEC 61499”[146]) presents more detailed explanations. However, the standard solely should be enoughto understand the concepts.

The application of the IEC 61499 standard in the automation of HPPs can be seenas a future work. Already there are some works integrating this standard to the IEC61850 standard [147] [148]. It is supposed that the IEC 61499 will be a better solutionfor the implementation of large distributed automation systems, as the one proposed inthis research. However, it also will be a harder work, because the IEC 61499 somehow is


more complex than the IEC 61131.

8.9 Distributed Automation

Basically, in a distributed automation system the control applications are distributedto several controllers, in the context of this research, the IEDs (introduced in the Sec-tion 8.7). An IED (controller) can takes into account data of other IEDs (controllers)on its logics to produce the outputs, which are: process information, inputs for otherIEDs, commands for the process equipment, alarms, etc. Thus, the intelligence of theautomation system is freely distributed among the IEDs.

On the other hand, the part IEC 61850-5 of the standard [107] states that the “defi-nition of a local or a distributed function is not unique but depends on the definition ofthe functional steps to be performed until the function is defined as complete”. The partIEC 61850-1 [11] also states similarly.

So, to be clear, in the context of this research a “distributed function” is a functionperformed in two or more different physical devices (IEDs), using data of them. In thisway, those physical devices act as a unities to achieve a common goal. Furthermore,here the system architecture that support the IEDs to realize that function is also called“distributed” (the literature also uses the term “decentralized”, but some times withdifferent meaning).

Te automation system is modelled as a collection of physical devices (IEDs) inter-connected and communicating with each other by means of a communication networkconsisting of segments and links. A function, by its turn, is modelled as an applicationwhich may reside in a single physical device or may be distributed among several physicaldevices.

The Figure 8.3 illustrates the concept defined here, through a model of a distributedsystem. Note that, the “Application 1” is distributed in two physical devices. Besides, itis distributed in two resources9 of the first device.

Here, each IED is associated with a set of process equipment, defined in this researchas “system” of the HGU (see Sections 2.5 and 2.6). That approach is modular. Physicallyeach system (with one IED) can be seen as a module of the complete automation system.

In the industry, frequently this set of equipment is called “controlled area”. In the caseof this research, each area is defined by the systems of the HGU and has only one dedicatedcontroller (disregarding the redundancy). Besides, each area is controlled integrated withother areas (there are data exchanges).

9A physical device can have diverse resources (concept not explored here). In the example, eachphysical device has two resources.


Figure 8.3: Distributed automation system model.

In the proposed architecture, the IEDs does not directly share their physical inputsand outputs, but the input data are shared and the output data are accessible to otherIEDs through the communication networks. Thus, any IED can receive signals form theequipment that are mapped in other IED of the automation system. In a similar way,each IED can send signals to other IEDs, including commands that will be directed totheir associated field equipment.

The standardization (discussed in the Chapters 5 “Description of the Generating Unit”and 7 “Modelling of the Generating Unit”, and also in the Section 8.12 of this chapter)is specially important in distributed systems, because there are great data interchange.The standardization facilitates the designs and implementations.

8.9.1 Distribution of Systems in IEDs

Nowadays, the automation systems for HPPs normally have a single IED for automa-tion of each HGU (a “head of cell” controller) and sometimes distributed input/outputmodules. However, as stated in the Chapter 3 “Evolution of the Automation Systems andProposal”, in this research it is proposed a true distributed architecture. The processingfor automation are realized in diverse IEDs.

Yet regarding the main IED, other solutions are possible. For example, the functions ofthat IED can be implemented in the IED of the electronic speed governor. A more modernsolution is to distribute the functions of the main IED among the other IEDs (eliminatingthe main IED from the architecture). That solution is more complex, although it also


present advantages, and need adequate resources to facilitate its implementation as, forexample, the IEC 61499 standard.

The Figure 8.4 illustrates the distribution of systems in IEDs. It shows the relationshipbetween the systems and the IEDs, represented by a class diagram.

Figure 8.4: Relationship between the systems and IEDs.

The class System is defined in the Section 5.5. The classes PowerPlant and Generatin-gUnit are defined in the Section 7.2. Note that, an HGU have a set of IEDs (representedby the composition of the classes GeneratingUnit and IED).

Note in the figure, the physical and logical connections defined in the Section 6.9.The proposal is flexible. An HGU can have any amount of IEDs and it is possible to

associate any amount of systems to an IED. Nevertheless, the approach utilized here is toassociate each system (defined in Section 2.6) to a different IED (relationship one to one).That is the most distributed approach possible (disregarding the distribution of functionsof a single equipment).

Note that, as each instance of the LogicalDevice class is associated to one instance ofthe Subsystem class (see the Figure 7.1) and a set of instances of Subsystem are associatedto one instance of System, the relationship between the LogicalDevice and IEDs can beobtained through the relationships presented in the Figure 8.4. Also note that, it isconsidered that all LDs that belong to one system are hosted by a single IED (it is notpossible to “break” one system and allocate its diverse parts in different IEDs).

After some analyses as, for example, capacities of the IED (inputs, outputs, processing,memory, etc.), flow of data, reliability and performance, may be concluded that one moreIED is necessary for a specific system. That inclusion of IED can be done easily defininga new system (breaking the original system in two) and reallocating the equipment (andrespective devices and points). After that, a new modelling can be done and, in thesequence, new analyses to certify the results. In a similar way, the functions of two IEDsthat are underused can be aggregated in a single IED. In that case, other analyses involvethe data acquisition.


In the first approach of the case study presented in this work, it is considered thatthere is no need to separate the functions of a single system in more than one IED.

Some particular cases of groupings of systems in IEDs are presented and discussed inthis chapter.

8.10 IEC 61850 Issues

In this research it is proposed utilizing the data of the IEC 61850 standard to designof the logics of automation. In a sense, that design approach is similar to the design of theconventional logics utilizing electromechanical relays10. The logics are constructed usingelementary functions that have common interfaces (in the IEC 61850 standard context:the LNs). The main difference is that instead to use the wirings for signals interchangeare used messages through the network. The communications are implemented using thecommunication services introduced in the Section 6.8.

Many types of LNs (instantiated from different LN classes) are used to implement theinterfaces of automation systems for HGUs. The LNs classes presented in the Chapter 7“Modelling of the Generating Unit”) and the LNs classes mentioned in the Section 8.6are considered. As examples, it can be cited the LN classes: “Pump - KPMP” [116] and“Temperature supervision - STMP” [116] from the first group and “Hydropower unit -HUNT” [17] from the second one.

The LN class KPMP is used to represent pumps, an equipment; and the LN class STMPis used to represent devices that supervise temperatures, a sensor (together the LN classTTMP - see the Section 6.11). The LN class HUNT is the main data model regarding theautomation of the HGU. That class represents the turbine and the generator of a HGU.For example, as exemplified above, it holds information about the current operationalstatus of the HGU.

8.11 Logics of Automation

The “logics of automation”, cited in the last section, are the statements that providepredetermined sequences of operation for the equipment according to the system stateand other inputs. Sometimes they are called of “algorithms of automation” (the terms“logics of control” and “algorithms of control” are also used). The logic to perform a

10There is a question about the scope of the IEC 61850 standard... it should deal only with interfaces forcommunications (and not with implementation of the secondary systems)? Strictly speaking the answeris “yes”, but in this research the answer is “no”.


function can be built in many different ways, some of them are considered better thanothers according to the requirements.

The logics can be represented in diverse ways, for example, graphically using “functionblocks” (or “functional blocks”). Function blocks are program organization units which,when executed, yields one or more values [141]. A function block may have input, outputand internal (hidden) variables (in the context of the IEC 61499 standard it also mayhave events of input and/or output). A logic of automation may contain multiple namedinstances of a specific function block.

Note that, here the logics of automation are not including the logics or algorithmsinternal11 to the LNs classes (as example of internal algorithms the protection algorithms).The algorithms that are “inside” the LNs classes are out of the scope of this research (andare a manufacturer issue). The theme addressed here are the logics of automation usingthe signals provided by the LNs to generate the signals that will be transmitted alsothrough LNs (to reach other IEDs or intelligent equipment). In fact, that matter is nottoo clear in the IEC 61850 standard.

In this research the logics of automation are separated in two categories. They are hereclassified as “basic automation” and “generating unit automation”. That segmentationhas some advantages. For example, the logics are more clear and it is easier to modifythem. The following subsections present the contents of those two categories of logics.

8.11.1 Basic

The basic logic of automation is responsible by the interface with the processes. Itreceives and sends data from/to the field equipment. Thus, that logic realizes the rawdata consistency and the interlockings in the level of equipment (or process level).

The basic automation receives the raw data from the primary equipment (inputs of theautomation system) and executes a preprocessing and also is responsible for receiving (oralso generating) the commands to actuate in the equipment, check them and after thatsend to the equipment (in a similar way of the inputs). In the context of this research(and also in the context of the IEC 61850 standard), those raw data are used to define thevalues of the DOs (through the DAs) of the LNs associated with the primary equipment,defined in the Chapter 7 “Modelling of the Generating Unit”.

Different from the substations, the interlocks in the HPP goes beyond simple LNs in-stantiated from the LN class “Interlocking - CILO” for open/close switches. In HPP thereare diverse kind of interlocks regarding different types of field equipments and situations.

The most important issues about safety are regarding to the basic automation.11In that case, considering that a LN is not only an interface.


The modern automation systems have new concerns about reliability and safety. Incommunication network based systems, the interlocks must be implemented in a way thatthe loss of a message does not result in unauthorized or inadvertent operation of thefield equipment. Besides, in case of communication network failures, the operation ofcertain equipment must be blocked (by the automation system). Now, solutions for thoseproblems must be considered in the design. For example, J. L. P. dos Santos and M. F.Mendes [149] propose the use of “validity”12 in the logics of automation to improve thereliability and the safety.

To improve the reliability and safety, in a few specific cases, some projects of modernautomation systems keep the old wired interlockings. That strategy is discussed below.

Wired Interlockings

The application of conventional parallel pairs of copper wires for interlockings (andother signals) in modern systems is a polemic theme13. The most “conservatives” engineerssay that all the interlockings, blockings and trips should be hardwired. On the other hand,the most “progressives” engineers say that all signalling should be through communicationnetwork. Thus, that subject need more studies and facts for decisions.

Anyway, the most importante parameter for the decision is the reliability14 of thescheme. For example, if a communication system is highly reliable (as should be forinfrastructure of critical systems), the solution of the progressive engineers can be im-plemented. The possible consequences of a failure also need to be considered. In somecases were very high safety is necessary, a redundant scheme, for example using simplifiedhardwired signal transmission, also can be applied. This is a design decision.

In this research it is proposed to analise the specific cases, always considering thereliability and the safety. As already said, mainly for safety reasons some interlockings(and blockings) should be conventionally hardwired. An example is the unblock of themechanical brakes according to the turbine speed or other situations (wicked gates closed,intake gates closed). Another classic example are the high voltage switch breakers. Aminimum hardwired interlocking is yet necessary for those equipment.

It is supposed that in a near future all signals (including trips) will be exchangedexclusively through communication networks. Nowadays, with the current technology,there is no more problems with performance requirements. The main question are about

12The “validity” is an attribute (a single bit, for example) associated to each data (as a quality attribute)to indicate if the data is valid or invalid. Note that, a data can be invalid due to problems in thecommunication network.

13Here are not considered the mechanical interlockings, which can be present in some equipment.14The theme “reliability” is discussed in the Chapter 9 “Automation System Architecture”.


reliability. Failures cannot occur in the critical systems analyzed here due to the conse-quences.

In the case of interlockings through communication networks, the transmission timesof the messages is importante because the interlocking conditions may changed due toany change in the states of the involved field equipment (including changes in the dataquality). Thus, there is a risk that an operation takes place at a time when the interlockingconditions are in change.

8.11.2 Generating Unit

As the name indicates, the automation logics of the generating unit are the statementsor algorithms related to the HGU functioning. All logics necessary to realize the automa-tion of the HGU are included, considering the statuses and measures from the process togenerate the automatic actions, commands and settings. Note that, the interlockings inthe field equipment level (or process level) are not included. The starting and stoppingsequences, introduced in the Section 8.6, are examples of generating unit automations.The operators orders, or commands in manual mode, also are inputs of that category ofautomation.

The most important issues about performance are regarding to the generating unitautomation.

8.12 Conceptual Model for Automation

As described in the Section 8.9, in the distributed automation systems there is alarge number of exchange of data (signals) among IEDs. If the LNs (and DOs and DAs)defined in an IED were available in the other IEDs with the same semantics, the visibilityof the whole automation system would be greater. That approach can simplify the signalmappings in the logics. That solution is defended in this research. The solution can beachieved utilizing the conceptual data models created here for describing and modellingthe systems together a new data model defined below.

With that approach, the references according to IEC 61850 standard are used not onlyfor communications, but they are used also to identify the variables (signals and memoryvariables) in the logic diagrams. That solution is feasible for any PLC (IED) of anyvendor, it is only necessary a software tool (an IED tool) capable to create the mappingsbetween references and internal variables. “Native” products, implementing directly theproposed solution, also can be developed.


8.12.1 Automation Variables

Currently, the manufacturers of PLCs (IEDs) use different ways for defining variables.In the automation logics there are basically two kinds of variables: the input/output vari-ables and the intermediate variables. The input/output variables are the signals from/tothe process (or from the automation system itself). The intermediary variables are theinternal signals, belonging to the automation system, for the implementation of the logicsand also for signalizations.

The input/output variables are already stated in the previous chapters. Their identi-fications (sometimes called “tags”) are the references of the DOs (and DAs) defined in themodelling (Chapter 7 “Modelling of the Generating Unit”). The “names” (or descriptions)of those variables are defined in the description (Chapter 5 “Description of the GeneratingUnit”).

Note that, the defined data are not only the process values (status information, mea-sured values, metered values) and commands (controls), but also data related to thesecondary systems (common information - data objects without category) and also forconfiguration (settings).

In this research it is proposed to create the naming and references of the intermediateautomation variables using basically the same model used in the description and modellingof the primary system. To this effect, the functions (and subfunctions) of automation areadded to the conceptual models. The difference regarding the HGU modelling is that insome cases the relationship with the instances of the classes EquipmentType and/or theSubsystem can be null. The main advantage of that approach is that the calculated points(or “pseudo” points) have the same pattern used to naming the physical points.

The automation variables are associated to the functions of the secondary systems.Thus, the functions (and subfunctions) of the automation systems can be related to (acomposition) the main classes of the structure of the conceptual model for modelling(shown in the Figure 7.1 of the Chapter 7 “Modelling of the Generating Unit”) from thePowerPlant class until the Equipment class. The functions of the Device class are definedby themselves.

8.12.2 Class Diagram

The Figure 8.5 shows the proposed conceptual model for automation, represented bya class diagram. Note that, the figure is not complete in the sense of modelling15.

15It does not show all elements, which can be seen in the other figures of conceptual models: Figure 5.2of the Chapter 5 “Description of the Generating Unit” and Figure 7.1 of the Chapter 7 “Modelling of theGenerating Unit”.


Figure 8.5: Conceptual model for automation.

The LogicalDiagram class is the main class of the diagram. It is the representation ofa FBD similar to the specified in the IEC 61131 standard. Its name is not “Functional-BlockDiagram” to unlink of the standard, because they are not strictly equal.

The classes System and RealPoint are defined in the class diagram of the description(shown in the Figure 5.2 of the Chapter 5 “Description of the Generating Unit”). Notethat, the specialization RealPoint is not identified in the class diagram of the description,because in that diagram the cited specialization is the abstract class Point (the class dia-gram of description contains only real points, that is to say, the physical inputs/outputs ofthe devices). Also note that, the specializations InputPoint and OutputPoint are not rep-resented in that diagram, but they can be easily imagined (they are specialized accordingto the direction attribute).

The instances of the PseudoPoint class are internal memory points, that is to say,calculated points. In the context of the IEC 61850 standard they are points related to theDOs (and DAs) of the LN classes dedicated to the secondary system functions (listed inthe Section 8.6). Note that, the specializations BinaryPseudoPoint and AnalogPseudoPointare not represented in diagram (Figure 8.5), but they can be easily imagined (they arespecialized according to the type attribute).

Observe that, an input variable (input for the logical diagrams) is an output pointof the device (represented in the class diagram of description) and an output variable


(output from the logical diagrams) is an input point of the device. The direction changesaccording to the standpoint. Thus, an output variable (from the automation system pointof view) that is an input point (instance of the InputPoint) class can be associated to onlyone logical diagram (instance of the LogicalDiagram class).

The Literal class can be specialized in (not represented in the figure): Boolean, Integer,Real, String and Time (the Time class includes: times, times of the day, dates, and datesand times).

An instance of the LogicalDiagram class can be associated to various instances of theFunctionBlock class. By its turn, each instances of the FunctionBlock class is associatedto one instance of the FunctionBlockType class and at least one instance of the Parameterclass. Note that, a Parameter can be a Variable or a Literal.

Each type of function block, represented by the FunctionBlockType class, has oneinstance of DataStructure and some instances of the Operation class. In the practice, themaximum allowed number of instances of the FunctionBlock class associated to the sameinstance of FunctionBlockType depends on the hardware and software implementations.

The DataStructure class represents data types consisting of collections of named ele-ments. As explicit in the figure, the data are: input, output and internal variables.

The Operation class is specialized in LogicControl or DataProcessing.The LogicControl class contains: logic functions, counters and timers (for example:

NOT, AND, OR, bi-stable elements, on-delay, off-delay, up and/or down counter).The DataProcessing class contains: functions for data handling, processing, comparing

and mathematical functions (for example: addition, subtraction, multiplication, division,square root, sine, cosine, integration, equal, greater than, smaller than, moving).

Each logical diagram belongs to one instance of the System class. On the other hand,one logical diagram can have objects of the Point class related to different instances of theSystem class. One time that all logic representations are defined, those relationships canbe utilized to evaluate the data flow in the automation system.

8.13 Implementation of the Automation Logics

In the context of this research, the signals in the FBD are related to the LNs. Besides,as the automation is distributed, the signals may be provided by distinct IEDs, throughmessages from the communication network. Those IEDs are the source of the primarydata, thus they keep the most actual values of the process. It is expected that all thenecessary signals for the logics are available in the DOs (and DAs) of the LN classesspecified in the IEC 61850 standard. In this research if any signal is not specified in the


IEC 61850 standard, it is created (specified) in an existing LN classe or in a new one (alsospecified in this report).

The logics of automation are independent of the communications. Thus, it shouldbe clear that the logics of automation needs of the communications, but the logics arenot affected by changes in the communication system (for example, upgrades to newtechnologies or application of different protocols). That is an important aspect of theproposed solution.

The part IEC 61850-6 of the standard [85] explains the data flow modeling. Thephysical connections are associated to the servers (publishers) and clients (subscribers),which are IEDs. At low level, the data flow is modeled by a list of signals which shall befed into a LN. It is recommended to map the input data in the LN LLN0 of the associatedLD.

In the context of the IEC 61850 standard, generally the receivers use the data set ofthe messages and their places in the data set definition for messages interpretation. Somecomercial products are based on a mapping of the messages bits to “network inputs”which are used in the automation logics. In contrast, in this research it is proposed thatthe automation logics use the semantic of the data models. That approach has someadvantages, for example, there is no need of mappings and intermediate variables, thelogics are more clear, the integration of tools can be higher, data entry errors are avoided.

In this research, the automation logics are compliant the IEC 61131 standard andare implemented using the modeled data (defined in the Chapter 7 “Modelling of theGenerating Unit”) according to the IEC 61850 standard. In other words, the LNs andDOs (and DAs) are used as inputs and outputs. Those data are the variables of the logicaldiagrams associated to the function blocks. The IEDs (controllers) receive/send the datathrough the communication services of the IEC 61850 standard (mainly Goose messages),introduced in the Section 6.8.

For real implementations it is necessary to develop software tools which used the SCLfiles. Those tools should have a programming framework compliant to the IEC 61131standard integrated to the data models of the IEC 61850 standard. As suggested in theSection 8.8, the XML can be used for integration of the standards.

Finally, as stated in the Section 6.8, the Goose messages can be produced due to eventsor periodically. In this research it is considered that any status or measure change is anevent which generates a Goose message. Thus, if any status or measure associated to avariable in one IED change, all the others IEDs will be aware of that change.

The prioritization of the messages (discussed in the Section 6.2) is very important forthe communications performance and, thus, the proper automation working. The highestpriorities should be used only by messages requiring that type of priority, for example trip


messages. Special attention should be given to interlockings and blockings, because someof them may also require highest priorities. After the definition of the logics an analysisof overall performance must be done. That analysis should consider the dynamics of theprimary equipment (simulation software can help).

In addition to the prioritization of the messages, another resource of the IEC 61850standard that can be used to improve the logics are the data associated to the values.Besides the “value” contained in the DA stVal (which may be of diverse CDCs), ifnecessary, the “quality” (DA q) and the “time stamp” (DA t)16 can be included in thediagrams, beyond other DAs. Remember that, the quality is particularly important toevaluate the validity of the data value, cited above, in the Section 8.11.

The part IEC 61850-7-3 of the standard [121] presents details about the qualities ofthe data and the contexts of application. The type “TimeStamp” is specified in the partIEC 61850-7-2 of the standard [114].

Other attributes may be considered in the logics. For example, the health statuses ofthe devices and equipment (represented by the DO EEHealth [116]) can be included inthe automation logics.

The situations of test also can be considered. The IEC 61850 standard has manyfeatures for testing [150] [151]. It can be cited, for example, putting an IED or a specificfunction in “test mode” and/or “blocked mode” (using the DOs Beh and Mod, inheritedfrom the common LN class and of the LN LLN0, respectively), setting flags of “simulation”in Goose and sampled values messages and mirroring of control data.

8.13.1 Messages

Naturally, for the correct processing of the mensagens adequate configurations of theIEDs (and other devices) should be done. After the development of the automationlogics, it is necessary to configure all the communications. It is basically to define the“data sets” and the “control blocks” (introduced in the Chapter 6 “IEC 61850 Standardand Communications”). The control blocks associated to the generic substation events,sampled values and settings (see the Section 6.8) are used to execute the automationlogics. The report control blocks are used to send data for the station control levels.

Note that, it is necessary the definition of diverse control blocks and diverse data setsfor different destinations (distinct IEDs). The data sets can contain DOs or DAs. Defininga few data sets for different purposes is a good practice. However, in real devices thereare limitations.

The work of configuration can be done with help of engineering tools. If the config-16The DAs stVal, q and t are defined in the part IEC 61850-7-3 of the standard [121].


uration tool is integrated to the tool of the automation logics, the work can be partiallyautomatized. Thus, that is a good theme for future works.

Considering the engineering, the use of messages results in some simplifications. Forexample, now it is no more necessary to worry about the physical switches contacts ofthe automation devices (considering one contact for local indication, another contactfor remote indication and another one for the Scada system, etc.). In the proposedarchitecture, the same signal can be sent through the communication networks anywherein the installation. Thus, the design is simplified and the auxiliary relays for contactsmultiplications are not more necessary.

8.14 Case Study

In this section it is verified if the proposed conceptual model for the logics of au-tomation and the methodology for implementation are suitable to solve the problem.The chosen system is the “Middle Bearings (MBear)”, introduced in the Section 4.4 of theChapter 4 “Case Study”.

In this chapter are utilized the LNs of the HGU (defined in the Chapter 7 “Modellingof the Generating Unit”) and also the LNs specific for the automation, defined here.

8.14.1 Logical Devices and Logical Nodes

The Table 8.1 presents the LDs and the LN classes used in the automation of the“Middle Bearings (MBear)” system. The table also shows the quantities of instances ofeach LN class.

Table 8.1: Automation logical node classes of the “Middle Bearings (MBear)” system.

Logical device Logical node class InstancesMBear Aut KPMP 2MBear Aut SFLW 1MBear Aut STMP 3

The table contains only the LDs, and respective LN classes, which belong to the“Middle Bearings (MBear)” system used in the automation. The other LN classes of thatsystem (for process LNs) are listed in the Table 7.4.

Considering that the data belong to the “Middle Bearings (MBear)” system of theHGU “U01” of the Itaipu power plant (identified by “ITA”), the complete name of theLD presented in the table is: “ITA U01 MBear Aut”.


Note that, the LN classes LPHD and LLN0 are not shown in the table. Consider thatthey also are utilized.

The LN class “Functional Priority status - FXPS” was not used in the redundancy ofequipment, but it can be applied.

8.14.2 References

The Table 8.2 lists the DO references of the automation of the “Middle Bearings(MBear)” system.

Table 8.2: References of the automation of the “Middle Bearings (MBear)” system.

Data object reference Point nameMBear Aut/GuiBPad STMP.HiTrip1 Guide Bearing Pad Temperature Too HighMBear Aut/MainPump KPMP.Oper Main Pump Turn On / Turn OffMBear Aut/RsvPump KPMP.Oper Reserve Pump Turn On / Turn OffMBear Aut/ThrBPad STMP.HiTrip1 Thrust Bearing Pad Temperature HighMBear Aut/ThrBPad STMP.HiTrip2 Thrust Bearing Pad Temperature Too HighMBear Aut/WPipe SFLW.TmLoTrip1 Water Pipe Time Delay Flow Low

The references shown in the table are simplified. The complete references include theidentification of the power plant and of the HGU. For example, the complete reference ofthe first line is: “ITA U01 MBear Aut/GuiBPad STMP.HiTrip1”.

Note that, the instances associated to the LN classes LPHD and LLN0 are not presentedin the table, in spite of the fact that they are utilized.

8.14.3 Logical Diagrams for Automation

The Figures 8.6, 8.7 and 8.8 (at pages 150, 151 and 152, respectively) show the logicaldiagram of the “Middle Bearings (MBear)” system. The Figure 8.9 (on page 153), showsthe part of the logic related to the “Middle Bearings (MBear)” system that is implementedin the “Motor Control Center (MotContCen)” system.

As stated in the Section 7.2, for simplification reasons, the DAs are not explicitlypresented in the logic diagrams. Consider that, all variables contained in the logicaldiagrams of this report refer to the DAs “values” (stVal, mag, etc.) of the DOs shown.

Note that, the logical diagram follows the approach proposed in the Section 8.12. Allvariables are compliant with the proposed conceptual model. Besides, the diagram isaccording to the implementation rules presented in the Section 8.13.

Only for didactic purposes, the variables associated to pseudo-points (defined above inthe Section 8.12) are identified in the diagram by the text “(pseudo)” in the end of their


Figure 8.6: Logic diagram of the “Middle Bearings (MBear)” system - signals.


Figure 8.7: Logic diagram of the “Middle Bearings (MBear)” system - main pump.

names. The other variables, associated to the real points, have the same references andnames of the points already listed in the Chapters 5 “Description of the Generating Unit”and 7 “Modelling of the Generating Unit”.

Note that, the logical diagrams contains data (references) from other systems.In a similar way, some signals of the “Middle Bearings (MBear)” system are used by

other systems as, for example, the “Braking (Brake)” system (introduced in the Ap-


Figure 8.8: Logic diagram of the “Middle Bearings (MBear)” system - turn on pumps.


Figure 8.9: Part of the logic in the “Motor Control Center (MCCen)” system .

pendix B “Case Study of Other Systems”, at Section B.2). The other systems receivethose signals through the communication network. That availability of any signal fromone system for the automation logics of any other system allows great flexibility for designof the whole automation system.

Other example of system integrated to the “Middle Bearings (MBear)” system is the“Motor Control Center (MotContCen)”. The interchange of data of those systems are dis-cussed below.

The signals to turn on and to turn off the pumps are single points (one bit). They arerepresented by the DO Oper (“Operate”) of the LN class KPMP (which is SPC).

As already stated (in the Sections 5.6 and 7.5), the pump one (Lub/OPump1 KPMP) ispower supplied by the “Motor Control Center (MotContCen)” system. In the conventionalautomation system, the signaling (to turn on/off the pump, for example) connections aredone through parallel pairs of copper wires, here they implemented through the commu-nication network.

For reliability reasons, two indications of the HGU (turbine) speed are used. One fromthe “Electronic Governor (EGov)” system (LN class “Speed monitoring Name - HSPD” [17])and another form the “Turbine (Tur)” system (LN class “Turbine - HTUR” [17]). Thefirst one is a limit switch and the last one is the rated speed.


That approach looks to be not according the IEC 61850 standard suggestion. Thepart IEC 61850-7-410 of the standard [17] states that the LN class HSPD “shall normallybe part of a stand-alone logical device. It may act as a protective backup of the governorfrequency control, but mainly as a placeholder for various speed limits and set-pointsused by the start sequencer and other functions”. However, that statement is not to clear,because de LN class related to the speed governor (“Governor control mode - HGOV”[17]) does not have a DO related to the turbine speed.

Anyway, the turbine speed is one of the most important data for the automationsystem of the HGU. Thus, to increase yet more the reliability, another instance of the LNclass HSPD can be allocated in a different system, that is to say, in a different IED (andthe associated resources for the implementation).

The diagram presents only the interlocks of the power source for the pump 2. Theinterlockings regarding the power source of the pump 1 is implemented in another IED(in the “Motor Control Center (MotContCen)” system). As all signals of the automationsystem are available for any IED, that interlock could be implemented in the “MiddleBearings (MBear)” system. However, for security reasons it must be implemented in thesystem which host the physical devices. An intermediate solution using the available datain both systems to improve the security is also possible, but it is a more complex solution(thus, has impact in the design, implementation and maintenance).

In the part IEC 61850-7-410 of the standard [17] there is not a LN class with a DOfor selection of the control mode of the HGU (automatic/manual). There is one DO ofthis kind only in the LN class “Combinator - HCOM”17 which, according to the standard,normally is a part of the speed governor. Thus, as presented in the Appendix C “IEC61850 Issues” (Section C.4), it was specified a new mandatory DO CtlMod18 (CDC SPC)in the LN class “Hydropower unit - HUNT” (false = manual and true = automatic).

Note that, it is possible manually to turn on and to turn off the pumps remotely (fromthe HMIs at the station levels). However, there is a remark to implement it, presented inthe next paragraph.

In the IEC 61850 standard it is not too clear how to use the LN class “Human machineinterface - IHMI”. It is specified to be defined in the engineering phase and to be usedin LNs for process interface, providing the human access to the functions. But the classdoes not have any DO (beyond the common DOs). Thus, for example purposes, it wasindicated in the logical diagram (Figure 8.6) the signals given by the HMIs (consideredincoming pulses).

17The LN HCOM shall be used to represent the function that optimises the relation between net head,guide vane and runner blade positions in order to achieve best possible efficiency [17].

18If the abbreviations defined in this research are put into practice, see the Appendix A “Abbreviations”,the DO name would be: ContMode.


The IEC 61850 standard also specify other LN classes similar to the IHMI for, perexample, gateway functions: “Telecontrol interface - ITCI” and “Telemonitoring interface- ITMI”. The description and comments about those LN classes can be found in the partIEC 61850-5 of the standard [107].

Another problem is regarding the selection local/remote. To implement interlockingsand permissions considering the data of all LN involved in the process is a complex task.A general data to select the location of control (local/remote) of the HGU can simplifythe automation logics and also avoid errors and other problems.

The main aspect of the example presented in this section is not the logic (algorithm),but the conceptual models and the methodology used to create it. The logic can bemodified and improved, and sometimes it must include particularities.

8.14.4 Data Flows

As stated in the Section 8.13, the data sets and report control blocks should be con-figured for the communications between IEDs. Each system of the HGU has differentsignals and characteristics, thus each case should be analyzed separately. As example,below there is a simplified analysis of the “Middle Bearings (MBear)” system.

The data of the LD MBear Aut (which contains the general data of alarms and tripsof the “Middle Bearings (MBear)” system) is sent to the other IEDs that need those data.The data of the LDs MBear GBear and MBear TBear which contain the data of alarms andtrips of each bearing pad (“Thrust Bearing” pads and “Guide Bearing” pads of the “MiddleBearings (MBear)” system) do not need to be propagated to the others IEDs.

If desired, the detailed data of the LDs MBear GBear and MBear TBear can be sent tothe operating levels (local and centralized control levels) through MMS for supervision(values and tendency) and historian. The reporting can be trigged by the data change ofthe LD MCBear Aut.


In this chapter it was proposed a conceptual model to elaborate automation logicscompliant with the IEC 61131 and IEC 61850 standards. The solution can be applied indifferent architectures of automation. It was applied in the proposed architecture, whichis distributed utilizing one controller (PLC, or IED) for specific groups of equipment of theHGU. In this research those groups are define as “systems” of the HGU. The exchange ofdata between controles of different systems are realized through a communication networkaccording to the IEC 61850 standard. The communication network also is utilized for


other communications as, for example, to exchange data with the HMIs. The conceptualmodel for automation logics utilizes a naming approach (for references and signals names)based on an hierarchical structure, represented in the conceptual models of the previouschapters of this report.

In the IEC 61850 automation systems the data (obtained from the process and gen-erated in the automation system) are structured in data models (LNs, DOs, DAs). Acritical challenge to develop a fully IEC 61850 standard compliant automation system isto connect the data used in the logics to the standard data models (other approachesare possible). In large HGU systems there are a huge amount of data. The approachproposed in this research to implement the logics can facilitate that work. Apparently,some necessary data are missing in the models of the standard and some connections arenot so clear. Proposals of solutions are presented in this report, but deeper (and widely)analysis are yet necessary.

As mentioned above, it is proposed to identify the variables of the logical diagramsaccording to the references created based on the IEC 61850 standard rules. That approachpresent some advantages as, for example, the use of DOs (and in the practice the DAstoo) aids understanding the logics represented (due to their implicit semantics) and, thus,facilitates the system design and maintenance.

That new approach is possible using adequate software engineering tools (which aregoing be developed). No changes of hardware are necessary to apply the method of logicaldiagrams development and implementation. The internal logic operation can be doneaccording to the will of the manufacturers. Software tools to deal with the appropriateddocuments and to realize mappings also can be developed. They can use the existingSCL files of the IEC 61850 standard and also include resources to facilitate the process ofdesign and implementation.

The data referring to the logical diagrams or equipment which belongs to other systems(from other PLCS, or IEDs) come to a specific controller through Goose messages. Ifintermediate variables (communication inputs and outputs variables) are necessary, thesoftware tool can manage them in a transparente way, so that the design engineer do notneed to know. Thus, the engineer only see the high level data, with semantic meanings.

It should be clear that there are various ways to modelling (define LNs and groupingthem into LDs) to implement the automation and there are various ways to design thelogics. The solution presented in this chapter is only to illustrate the research (using theproposed models and methods) with a case study.

The use of the DOs Loc and LocKey (and LocSta), specified in the IEC 61850 standard,to manage the control authority (local/remote) is powerful, but also complicated to beimplemented. Maybe a more simple approach (not at level of LNs) could be a better


solution. For example, the selections can be associated to the systems (listed in theSection 2.6). In the same direction, a general selection of control authority of the HGUlooks to be necessary.

The development of software engineering tools and the integration between the IEC61850 standard and the IEC 61131 standard (and optionally the IEC 61499 standard) arenecessary to realize modern automation systems for HGUs. Naturally, the existence ofIEDs specific for HPPs on the market also is necessary.

The automation logics and variables presented in this chapter are not exhaustive.As the systems are complex and there are more than one way to define the variablesand to design the logics of automation (with advantages and disadvantages), more timeis necessary for analyses and for concluding about the best approach according to thedefined criteria. Specific analyses of logics for automation of HGUs utilizing the IEC61850 standard signalling are suggested as future works.

Finally, as in the past projects, the automation system should meet the requirementsand consider the restrictions established in the technical specification [6] [64]. Besides, thetesting (not too explored in this research) also must be considered in the systems specifica-tion and design. For example, the conformance testing is the basis for the interoperabilityof IEDs.

Chapter 9

Automation System Architecture

“Architecture is invention.”Oscar Niemeyer (1907-2012)

9.1 Introduction

The design of modern automation systems continues to be driven by the needed func-tionalities, considering the requirements and restrictions. However, as already discussedin this report, the new systems can apply new technologies of computing, data commu-nication and data modelling. For the new system offers the benefits of those technologies(including the IEC 61850 standard), it is necessary to rethink the traditional automationsystem architectures. Modern automation systems have different characteristics from theconventional ones, thus the architecture must be really new.

The main differences regarding the previous systems are due to the intense use of com-munication networks at all system levels and the possibility to distribute the functions.As proposed in this research, the free allocation of functions should not be done conser-vatively. Here the potentiality of the IEDs associated to the equipment, sometimes calledboundary IEDs, are explored (not only for interfaces). Besides the data acquisition, theyhost automation functions.

The architecture is defined primarily by the devices and equipment of the process level(introduced in the Section 8.3 and shown in the Figure 8.1), their functions and the waysthat they are interconnected and interact. As explained hereafter, in the modern systemsit must be considered the physical architecture, which is now relatively simpler, and thelogical architecture, which can be complex for large systems.

In the centralized architectures, all data traffic flows necessarily from/to a single centralIED. In that case, all other devices are basically input/output devices, as presented in

Chapter 9. Automation System Architecture 159

the Chapter 3 “Evolution of the Automation Systems and Proposal”. In the proposeddecentralized configuration, the data flow is distributed between diverse IEDs (and withinthe communication networks). Various types of messages are used. Thus, the logicalarchitecture is more complicated and requires more attention, as presented in the Chapters5 “Description of the Generating Unit”, 7 “Modelling of the Generating Unit” and 8“Generating Unit Automation”.

This chapter deals with the logical and physical architectures of the automation sys-tem. The logical architecture defines how the automation system realizes the functionsand communicates across the physical architecture. The physical architecture defines thedevices of the automation system and how those devices are physically connected. Theconnections for data define the so-called “communication system”.

In the case of substations, normally the physical topology of the communication systemmirrors the electrical topology. However, that approach is not really suitable for HPP.The power plants (not only hydroelectrics) are more complex than electrical substations.Thus, in this research a particular approach is elaborated for HPPs.

The basic physical architecture proposed for the automation system is introduced inthe Chapter 3 “Evolution of the Automation Systems and Proposal”. Here that architec-ture is detailed. For example, the network devices are included and the other componentsof the architecture are specified. Therefore, this chapter presents a kind of “conceptual de-sign” of the automation system, including the automation devices, the computers (serversand workstations) and the data communication networks.

As mentioned in the Section 3.6, this research proposes to unify the communicationof the first three levels of the automation systems. Fast Ethernet networks with supportfor VLANs and priority tagging (introduced in the Section 6.2) are able to achieve therequirements. The network uses, basically, TCP, UDP and IP at the lowest levels of theOSI model, and also direct messages at layer 2 of the OSI model. Therefore, from thenetwork standpoint, the solution proposed is open.

The proposed physical architecture comprises a single Ethernet network connecting alldevices of the automation system, transmitting client-server and peer-to-peer messages.As deeply discussed in the Chapter 8 “Generating Unit Automation”, among other advan-tages, that approach facilitates the implementation of the automation functions, becausethey can be distributed using any device at the different levels of the functional hierar-chy. Furthermore, there is no need for routing in the (local) control level (there is nocommunication devices at layer 3 of the OSI model).

The proposed system integrates the roles of Scada system (and allows the implemen-tation of the Energy Management System - EMS - functions). The Scada functionalitiesare provided by the automation system (different from what happened in the past, with


the conventional automation systems - see Figure 3.2).It is assumed that all devices of the automation system comply with the ambiental

requirements stated in the part IEC 61850-3 of the standard [117] as: electromagneticcompatibility, vibration, temperature, humidity, etc. Also, it is supposed that all therequirements of auxiliary services are meet according to that same part of the standard.Remember that, the electromagnetic disturbances immunity requirements for HPP aremore rigorous than the requirements for other industrial environments. Thus, specialattention should be given to the automation and communication devices.

In some power stations there are traditional automation panel boards as backup. Thosehardwired panels exit to be used during the digital automation equipment outages (failuresor maintenances, for example). In this research it is not considered the existence of thatkind of panel (there is no conventional backups). It is suppose that the automation systemis completely digital with a few electromechanical elements (relays, contactors, etc.) andit has high reliability.

Non communication connections as, for example, the power source connections andthe field devices connections are not addressed in this report. They are made usually, asin the conventional systems.

The physical layouts of installation of devices are out of the scope of this research.This issues belongs mainly to the executive project.

Some concepts and definitions regarding the architecture and its analyzes are alsoaddressed in this chapter. For example, the subject “reliability engineering”, which isutilized in diverse parts of this chapter (and in other chapters), is introduced in theSection 9.2 below.

9.2 Reliability and Safety Theory

This section introduces the theory of reliability, availability, maintainability andsafety1. Somes important concepts and definitions, for analyzes of the architecture, arepresented. More details of those subjects can be seen in the references [152], [153], [154],[155], [156]. At the end of this section, there is a discussion about some design consider-ations.

The part IEC 61850-90-4 “Communication networks and systems for power utilityautomation – Part 90-4: Network engineering guidelines for substations” of the standard[157] also presents considerations about the subjects above cited, regarding the networkengineering of IEC 61850 systems.

1Sometimes those topics are referred by the acronym “RAMS”.


9.2.1 Reliability

According to the IEC 60050 “International electrotechnical vocabulary - Part 192:Dependability” standard [158], reliability is “the ability of an item to perform a requiredfunction under given conditions for a given time interval”.

In protection systems, usually the reliability is associated to dependability2 and secu-rity3. Here the idea is similar.

Reliability is one of most the important aspects of the automation systems. For ex-ample, a survey of the opinions of several major companies of the Brazilian electricitysector [8] [159] shown that the low reliability is one of the reasons (weight around 40%)that induce the decision to modernize the automation systems of HGUs.

9.2.2 Maintainability

According to the IEC 60050 standard [158], maintainability is “the ability of an itemunder given conditions of use to be retained in, or restored to, a state in which it canperform a required function, when maintenance is performed under given conditions andusing stated procedures and resources”.

Due to the large amount of available data, communications capabilities and intelligenceof the modern automation systems, they may have extensive capability of self-diagnosis.Self-diagnosis is the process of diagnosing or identifying specific conditions in itself. Forexample, it may be verified in real-time if some IED is not responding and if there is anyperformance degradation. Those features can facilitate the troubleshooting and, then, toimprove the maintainability of the automation system (and the reliability too). Further-more, the data of the equipment can be compared to the design ratings and historicaldata for diagnosis and predictive maintenance.

Lastly, considering the above characteristics, the modern automation systems mayhave new approaches of maintenance, for example, the reliability centered maintenance4

can be applied. Other new approach that can be utilized is a test systems permanentlyintegrated to the automation system. That kind o system must be engineered togetherthe automation system

2Dependability is the probability that the function will be executed correctly when wanted.3Security is the probability that the function will not be performed when unwanted.4Reliability centered maintenance, or simply RCM, is utilized to assess the consequences of fails

of a item based on the functions of that item for purposes of maintenance. It was originated in theairline companies in the decade of 1960. The reliability centered maintenance is, basically, a processof determining the most effective maintenance approach of the physical assets considering their presentoperating context [160]. It employs real-time monitoring, reactive maintenance, preventive maintenance,predictive maintenance, and so on.


9.2.3 Availability

According to the IEC 60050 standard [158], availability is “the ability of a item tobe in a state to perform as and when required, under given conditions, assuming thatthe necessary external resources are provided”. Thus, the availability depends on thereliability and maintainability of the item.

Other standards have specific definitions regarding availability. For example, the IEC60870-4 “Telecontrol equipment and systems. Part 4: Performance requirements” stan-dard [161] defines some availability classes of severity. They can be used for specifications.

Availability is one of the most important aspects to specify automation systems.

9.2.4 Failure Rate and other Indexes

This subsection presents some indexes widely utilized in reliability engineering [154][160].

The “failure rate” (often denoted by Greek letter λ) is the expected number of failuresof an element per unit of time (hour is the most common unit). Failure rates are oftenexpressed in engineering notation as failures per million, since normally they are verysmall numbers. Usually the failure rate of an element depends on time, but frequently itis assumed that the rate is constant during the useful lifetime of that element (that is theapproach applied here). In that case, the reciprocal of the rate of failure gives the MeanTime To Fail (MTTF)5.

Another index is the Mean Time To Repair (MTTR). It is the sum of the time todetect the failure, the time for the maintenance staff be prepared to execute the repairand the effective time to realize the repair.

The last index introduced here is the Mean Time Between Failures (MTBF). It is theaverage expected interval between failures of a repairable element in steady state. Thus,the MTBF is the sum of the MTTF and MTTR. Note that, the MTBF impacts bothreliability and availability.

Using the presented indexes, the availability (introduced above and here represented bythe letter A) can be calculated by: A = MTTF/(MTTF +MTTR) = MTTF/MTBF .

9.2.5 Safety

A system is classified as “safety-critical” if a failure can result in consequences that arejudged unacceptable. The consequences may be related to the safety of persons and/or

5Some authors use MTBF in the place of MTTF and consider that MTTF is applied only to non-repairable elements, meaning the mean time expected until the fatal failure of those elements.


of environment. Sometimes the economic implications also are considered.Safety is a state which the risk has been reduced to a level (and maintained at that

level) that is as low as reasonably practicable and the remaining risk is generally accepted.Risk is a combination of the probability of occurrence of harm and the severity of thatharm. Harm is a physical injury or damage to the people or to the environment.

In addition, “functional safety” denotes the part of the overall system safety that de-pends on the correct functioning of active control and safety systems [155]. Functionalsafety relies on active safety barriers. Lastly, “safety functions” are responsible for themitigation of risk associated with functions of the system. They perform the risk reduc-tion where it is needed. In the practice, there is no zero risk (a risk cannot be entirelyeliminated).

In the context of this research, the most important standards associated to safety isthe IEC 61508 “Functional safety of electrical/electronic/programmable electronic safety-related systems” standard [96]. It has seven parts. The IEC 61508 standard can beused for the specification, design, implementation, operation and maintenance of safetysystems. All systems are considered by the standard to be control systems.

9.2.6 Failure Modes

According to the IEC 60050 standard [158], failure is “the loss of ability of an item toperform a required function”.

According to the same standard, a failure mode is “the manner in which the failureoccurs”. Thus, a failure mode can be seen as the effect by which a failure is observed ona failed item.

A failure mode that causes more than one item to fail when the contingency occurs isa “common mode of failure”.

Two or more items are “fail independent” if a single mode o failure affects only oneof them. It means that the failure modes of each item occur independent of each other.However, when a item fail, it do not necessarily have to fail independently of other items.

9.2.7 Design Considerations

Generally large HPPs have more than one HGU installed. In that case, a basic principlefor the automation systems is that common failure modes that cause more than one HGUto fail cannot exist. Thus, a single failure, for more severe that it can be, will not preventthe operation of more than one HGU. Therefore, here is required that the automationsystem of each HGU must be completely independent until (including) the local control


level. Remember that, as already explained, the centralized control level involves all HGUsof the installation.

The primary goal is to reach high levels of availability. For that purpose, the automa-tion system of each HGU must be able to withstand any simple contingency. From apractical standpoint, the loss of a basic function cannot occur, and the probability of fail-ure of an accessory function or the probability of system performance degradation shouldbe very low.

Typical values for the availability of electrical automation systems are greater than99.96%. Thus, the fundamental condition is that IEDs and other components of theautomation system must have high values of MTTF and low MTTRs. Too high values ofavailability, near to 100%, are not always possible due to high costs and complexity.

It should be clear, as presented above, that availability is not affected solely by thehardware and software, but it is also associated with a combination of several factors,including the system architecture (discussed in this chapter). To increase the availability,specific redundancies may be applied, as already indicated for the communication net-work and computers. Some considerations about redundancies are addressed in the nextsubsection.

9.2.8 Redundancy

Redundancy is the duplication of elements (or functions) of a system. The mainintention is to increase the reliability, ensuring that the system continues to operate if oneelement fails. It should be clear that, a redundant element is a resource that would notbe needed if there were no failures in the system. Thus, unfortunately, in some situationsit can be seen as an unnecessary cost by some persons.

The redundancy is widely applied in the digital electrical automation systems (speciallyfor protection). For example, G. Dogger et. al. [136] proposes a completely redundantarchitecture (all devices of protection and control are duplicated, there are two completesystems: “A” and “B”). They also implement various specific schemes of redundancy tomeet reliability and availability requirements.

On the other hand, the redundancy can not be a default rule. For example, L. R.Jonsson, K. Faber and B. Lundqvist [162] conclude that “the duplication of the commu-nication system shall only be implemented when a duplication of the entire secondarysystem is required”6.

6Anyway, here it is considered that the duplication of communication system guarantees the highreliability of the communications (as can be seen in the Section 9.10), thus it is applied in the proposedarchitecture (even though without an entire redundant secondary system).


In general terms, in this research it is believed that to guarantee high reliability (andavailability), the essential or critical components of the automation system must be du-plicated. The redundant devices must work on-line, preferably with zero switching times.Also it is recommended that somes servers, gateways, etc. are independent (separated)to avoid common failure modes.

Similarly, as stated in the Section 6.2, the communication networks should be redun-dant (mainly due to the distribution of functions proposed in this research). It is unaccept-able that failures in the network components affect the automation system. Therefore, toavoid fatal single points of failure, the devices and cables of the communication networksmust be duplicated. A design requirement is that a failure of one switch or of one opticalfiber has no effect on the capacity of communication. In the practice the financial issuesmust be considered, due to the fact that some specific communication devices are veryexpensive, but it is not subject of this research.

Beyond all, the redundancies should be considered in the design of the mechanismsof cyber security of the automation system. Note that, the redundancy also can help tomaintain the automation system working in case of pontual failures caused by attacks ormalicious activities.

Other practical design considerations are presented in [6] and [163].The redundancy is important to obtain a high availability, but it is also important to

reduce the MTTR.

9.2.9 Fault Tree Analysis

There are various methods for analysis of reliability and safety of systems [160] [156],among them can be cited “reliability block diagram” analysis and the “fault tree” analysis.

The fault tree analysis, commonly referred simply as FTA, is one of the most usedmethods to quantify the failure probabilities and the contributors. It allows to focus onan important event belonging to the system and to help minimizing its occurrence. Themethod envolves the basic concepts of failure effects, failure modes, and failure mechanisms[164].

A fault tree diagram is a graphical representation of a logical structure depictingevents of failures and their causes. The tree structure is built top-down using logicalgates (AND, OR, etc.) and events with associated reliability parameters. In the faulttrees, a particular failure condition, known as the “top event”, is considered and a tree isconstructed identifying the various combinations and sequences of other failures that leadto the failure being considered [153]. The tree has various hierarchical levels of failuresuntil a level of failures of the basic system elements.


The method of analysis utilizing the fault tree can be applied for qualitative andquantitative evaluations. There are two basic approaches for evaluation of the probabilityof the top event: combination of all events together using boolean algebra or combinationof the estimated probabilities of the basic events using rules of probability. As it couldnot fail to be, both approaches have advantages and disadvantages [153].

The numerical approach is utilized in this research, in the Section 9.10, for analysisof the proposed solution. Starting at the lowest hierarchical level, the intermediate eventprobabilities are calculate and combined until the top event.

9.3 Logical Architecture

A logical architecture represents the functional data of a system and their relation-ships. Thus, as cited in the introduction, on modern automation systems the logicalarchitecture is part of the system design [53] [57]. It define the data flows between thevarious components of the automation system already introduced. The data flows involveall horizontal and vertical communications inside and between the levels of the automa-tion system, illustrated in the Figure 8.1 of the Chapter 8 “Generating Unit Automation”.Those data streams are determined by the distributed automation functions, includingthe data acquisition.

In this work, the definition of the (logical) architecture of the automation system hasbegan in the Chapter 2 “Hydroelectric Power Plants and Hydro Generating Units”, whenthe systems of the HGU (sets of equipment of the primary system) were defined in theSection 2.6. The description and modeling of the equipment are based on that definition.Thus, all data that represents an image of the primary system is structured and distributedaccording to the established systems and, consequently, they have influence over the dataflows.

The logical architecture should permit to detail the data flows between the elements ofthe automation system (IEDs and computers). As the communications are implementedfollowing the IEC 61850 standard, the data sets and control blocks (and the addresses)for each communication service, introduced in the Section 6.8, must be determined.

Nowadays, the above cited configurations are part of the design. The details on levelof signals (or messages) replace the traditional engineering for conventional wiring. Thedetailing of the project of the logical architecture is facilitated by the inherited semanticof the IEC 61850 data models together the semantic of elements naming proposed in thisresearch. The results can be recorded in the SCD file (introduced in the Section 6.9).

The logical architecture also involves the definition of VLANs. Here it is proposed todefine at least the following VLANs (for each HGU):


1. Goose: for peer-to-peer Goose communications among IEDs (of all systems of theHGU, including protection);

2. Sampled Value: for transmission of the SVs (of CTs and VTs) to the “VoltageRegulator (VReg)” and “Electronic Governor (EGov)” systems (and protection of theHGU too);

3. Local Station: for MMS communications from/to IEDs to/from the local com-puter;

4. Centralized Station: for MMS communications from/to the local computerto/from the centralized computer.

The most important VLANs are the two first, to avoid that one IED process themessages intended for other IEDs. Besides, those VLANs allow isolating different types ofmessages to obtain higher performance (restricting the flows of multicast and broadcastframes). The bulk of IEC 61850 traffic consists mainly of SVs messages, followed by theGoose messages.

Additional VLANs can be defined for data of the engineering workstations (the desktopcomputer presented in the architecture and also notebooks), fault recordes, monitoringsystems, specifics files transfers (through File Transfer Protocol - FTP), etc.

After the data flow estimation and respective analyzes, discussed below (in the Sections9.8 and 9.9), other specific VLANs may be defined. The VLANs also may be modified todeal with the problems of cyber security (discussed in the Section 9.11).

A final comment is that the network traffic of a possible testing system must beconsidered in the overall data flow analyzes. The bandwidth and latency of the automationsystem can not be affected by the tests.

The next sections present some components, resources and ideas for the developmentof a physical architecture of the automation system and, then, the Sections 9.8 and 9.9present the physical architectures of the local control and of the centralized control zones,respectively.

9.4 Intelligent Electronic Devices - IEDs

The size of the distributed system is a basic parameter for some decisions making aboutthe IEDs (PLCs) [144]. At this point of the research, the amount of IEDs contained inthe automation system is already established. Thus, the question is to verify if the choiceis adequate. Basically, it should be verified the quantity of physical interfaces and the


capacity of communication of each IED. The processing capacity of the IEDs (PLCs) isnot a problem nowadays (looking at the present application).

The requirements for physical interfaces of the IEDs (amount and types of inputsand outputs channels and also communication ports) are defined by the allocation ofthe models of the primary functions. After the modelling (procedure of the Chapter 7“Modelling of the Generating Unit”), those requirements are known. Adjusts can be doneto find the appropriate commercial IEDs.

The requirements for communications of the IEDs (amount and types of messages)are defined, in addition to the field interfaces, by the logics of automation. After thedesigns of the logics (procedure of the Chapter 8 “Generating Unit Automation”), thoserequirements are known. As mentioned above, the data have to be organized in datasets for the transmission of messages. Thus, adjusts of the messages (data set and alsocontrol blocks) can be necessary to harmonize with the IEDs. The maximum amounts ofconcurrent client-server relationship and messages between peers must be considered toreview the data flows.

In the practice, the capacity of IEDs to send/receive Goose messages (maximum quan-tity of publications/subscriptions of messages) and the number of bits contained in thosemessages are very important to achieve the proposed architecture. It requires too muchbits exchanges through Goose messages between the IEDs. The Goose messages shouldbe designed to handle the necessary data of the diverse IEDs in a efficient way. Besides,according to the part IEC 61850-90-4 “Network engineering guidelines for substations”of the standard [157], a technical report, it is recommended to use fixed-length fields toreduce encoding and decoding overhead.

With the level of details describe above, the capacities of each IED to support therequired communications can be verified (or defined). When the type of message permit,it must be defined the messages that should be point to point (unicast) and the ones thatshould be sent to multiple receivers simultaneously (through multicast or broadcast). Inaddition, the VLANs cited in the logical architecture (Section 9.3) to divide data streamsover the network also must be reviewed. The messages should arrive preferably only intothe receivers which need them. Those tasks must be done to ensure the expected systemperformance.

Note that, on the proposed architecture, the IEDs can be reached from any point ofthe network. Thus, to prevent unauthorized accesses, all the IEDs must have strong pass-words (default passwords are forbidden). Nowadays, there are applications for passwordmanagement that includes policies for generating the passwords and also auditing of pass-word access [165], which can be applied. The theme cyber security is broadly discussedin the Section 9.11.


A final comment is that the operation through the HMIs of the IEDs also should beconsidered. In specific cases they can work as backup of the main HMIs. All the informa-tion from the IEDs shown on the HMIs computers of the station levels also can be madeavailable in the selves IEDs (if there are sufficient resources) in a less friendly way. Besidesthe visualization, some IEDs can be programmed with interfaces to allow performing thebasic operation of the equipment (sending local commands). Those interfaces also areimportant during the maintenances, to facilitate the tests. Only for information, in thisresearch it is proposed to maintain some conventional HMI resources in a few panel boardsof the process (see the Section C.5 in the Appendix C “IEC 61850 Issues”).

9.5 Computers

This section presents the computers (servers and workstations) contained within theautomation system.

Nowadays, there are a lot of kinds of high performance industrial computers with agreat variety of cards/modules on the market. Thus, there are several options to set thosecomputer up for any need in the automation systems. There are specific settings for real-time servers, database servers, historians servers, communications servers, workstations,etc. The servers should be rack-mounted.

The capacity of the computers, their software and how they are applied in the au-tomation systems have changed in the last decades. The Chapter 3 “Evolution of theAutomation Systems and Proposal” shows in brief those changes.

In the older projects, often master-slave relationships where applied for communicationwith the highest levels of the automation system, where were the computers. In the newprojects a change to client-server communication are occurring. That is the relationshipused by the IEC 61850 for vertical communications. Therefore, it is the form of commu-nication from the devices of the lower levels (process and unit) with the computers at thestation levels of the proposed architecture.

The client-server communication offers flexibility and facilities to updating the client,when compared with the master-slave relationship. For example, a HMI (a client) can bereplaced or a new HMI can be easily included in the architecture. Moreover, that type ofcommunication provides better performance.

The next subsections present specific characteristics of the main computers, accordingto their roles in the automation system.


9.5.1 Station Computers

The proposed system has two levels of station computers, containing the real-timedatabases7. The first one is at the local control level of each HGU: the “local stationcomputer” or simply “local computer” (it also can be called “unit computer”). Thesecond one is in the centralized control level: the “centralized station computer” or simply“centralized computer” (it also can be called “central computer”). Both station computersare redundant, because they are fundamental for the automation system working andoperation of the power plant.

The centralized computer receives data from all HGUs of the HPP (and it may alsoreceive data from the electrical substations, when the automation systems are integrated- that is being proposed here).

The local computer has features for supervision and control. It maintains the real-timedatabase near to the process. Thus, this computer acts as an intermediary (proxy8) forother clients that need those data. The IEDs, which have the most actual data of theprocess, should properly update the local computer data.

The local computer also can store the displays9, but it is preferable that they arestored in the HMIs computers (described below). Moreover, that computer can includesthe local database, the historian and possible the applications of the local level. Accordingto the amount of data and applications, more than one computer can be used (however,with the current hardware technology, it is seldom necessary).

It is important to select the data that will “rise” towards the real time database onthe station computers, avoiding unnecessary communications and storages. The amountof real-time data which rises to the centralized station level may be lower than that usedfor local control. The data necessary in the centralized control level depends on thegranularity of supervision and on the applications. Likewise, often the data that go tothe off-site control center is a subset of the centralized control level data. The necessarydata is selected according to the applications in the off-site station (control) level. Notethat, the last communication, maybe realized through the IEC 61970 standard [138], isout of the scope of this research.

The configuration of the station computers may be done using the proposed datamodels of this research. The diverse lists commonly present in automation systems (events,alarms, etc.) and their groupings (area, importance, etc.) can be generated automatically

7Some automation systems utilize more than one real-time database. In that case, normally all ofthem can be hosted in the same computer.

8Proxy is a server that acts as an intermediary for requests from clients seeking resources from otherservers.

9Display, in this case, is a collection of images and data being displayed on a computer.


using the data of the modeling and description. The possibly necessary additional datacan be aggregated to the conceptual models, as stated in the Section 5.5. That ideaapplies in both station levels (local control and centralized control).

9.5.2 Operation Workstations

The operation workstations are the HMI computers to operate the HGUs (and otherprocesses of the HPP). Although there are two HMIs in the proposed architecture ofthe local control level (Figure 9.1 presented below), that configuration is not mandatory.There is no necessity of local HMI redundancy because it is used only in cases of failureof the centralized control level and in other rare situations. However, as the cost of anHMI is relatively low and the integration is simple (as commented in the last subsection),that redundancy can be kept to facilitate the operation and maintenance10 (and increasethe reliability of the local level).

At the centralized control level, the amount of HMIs is established by the needs forthe HPP operation and for the load dispatching (that number is related to the quantityof HGUs and operators working simultaneously). So, that regular configuration alreadyprovides redundancy of HMIs.

Most of the HMI displays designed to be used in the local level also applies to thecentralized level. Some adaptation can be necessary due to difference of granularities.The video walls of the control rooms can work like a common HMI.

As proposed in the Section 9.3, it is considered that the HMI computers ask for real-time data and send commands through specific VLANs.

9.5.3 Historian Servers

The proposed automation system architecture has two database for operational his-torians11. The first one, which can be called “primary historian”, is installed within thestation level of each HGU, for local data. The local station computer can host it. Thesecond one is installed in dedicated redundant servers, more powerful, within the central-ized control level. It can be called “secondary historian”, but, in fact, it is the principalhistorian (perpetual) of the system and it is referred in this report simply by “historian”.It stores the historical data of all HGUs of the HPP (and of the substations, when thesystems are integrated).

10For tests and to be utilized as a engineering station, as described afterward.11Operational historian, or simply historian, is an application for historical time-based process data

storage.


It is proposed to have identical data structure in both historians (primary and sec-ondary, in the levels local and centralized, respectively). That strategy provides somefacilities, for example, it reduces the time and effort for configuration and the same appli-cations can run in both levels. In addition there are two ways to populate the databases:the local historian is replicated to the centralized one, or the data go simultaneously toboth historians.

The historical database of the local control level can be circular, losing the old records.The historian of the centralized control level is perpetual: maintained for future queriesand retrievals (with safe backups, etc.). The periods of the circular database, backupsand so on should be established according to the amount of data, frequency of population,mass storage capacity, performance, etc.

Also it is proposed a database which contains a third of historian, which can becalled “intermediate historian” or even “public historian”, used for external accesses (dataretrieval only). That database is referred here as “intermediate database”. It can beaccessed by the corporate systems, including systems that support the operation andmaintenance activities. That database stores historical data (it can be a full mirror ofthe historian or it can contain part of the historian) and also any other data required forexternal systems and users.

The intermediate database also can be an input way for the automation system toreceive data, which are necessary on applications, from the external systems. To commu-nicate with external systems, it is important to consider the security. For example, thetraffic of external messages must not enter in the operation or control networks (real-timenetworks). Thus, firewalls must be provided for cyber-security. Other security resourcesare necessary (as discussed in the Section 9.11).

9.5.4 Other Computers

The automation system should have at least one engineering workstation in the cen-tralized control level, for configuration and maintenance purposes.

In the local control level it is proposed to use the workstations of operation also asengineering stations, if necessary (naturally including authentication and authorization ofusers). Normally, they will be utilized for engineering only in the maintenance periods.Besides, the normal operation level is the centralized.

The computers used in the corporate level are usual desktop computers. A few mayrun HMI software to visualize the process and any other kind of application which utilizesthe process data from the intermediate database.

The automation system can have environments other than the production (real-time).


For example, infrastructures for software developments and tests and for operators train-ings can be necessary. They are not addressed in this research, although they can beimportant. Basically, that kind of infrastructure contains servers and computers withsimilar functions of the ones of the centralized control level, including the communicationnetwork equipment.

9.5.5 Redundancy of Computers

As cited in the Section 9.2, redundancy of items can be necessary to increase thesystem reliability. The redundant servers should be configured in a “hot standby” modeto minimize the failover times. Thus, one of the redundant servers is active at the time andthe other is ready to work as fast as possible if the first fails. Besides, as the communicationnetworks are redundant, the servers should have dual links for connections to the network.

In the centralized control level all redundant computers work in parallel and obtaintheir real-time data from the centralized station computer (the active one). It is possibleto implement consistence checks between different servers of the same application.

As cited above, if there are more than one HMI computer for operational reasons,that situation can be also considered a redundant configuration. In that case, all theHMIs computers should run in parallel to obtain (distinct) real-time data. Thus, anyHMI can be used and if one fails the others will be available (changes of configuration cabe necessary).

9.6 Communication Networks

This section deal with the networks of the communication system (defined in theSection 6.212) associated to the IEC 61850 standard to apply in the system architecture.

The proposed architecture allows two basic types of communication introduced inthe Section 6.8. The first one is the peer-to-peer communication between IEDs to runthe automation logics (including some interlockings and blockings). The second type ofcommunication is the client-server communication between the IEDs and the local controlstation computer for supervision, commands and other functions.

The peer-to-peer communications allow the distributed implementation of the automa-tion logics proposed in the Chapter 8 “Generating Unit Automation”. Many IEDs canwork together, each one with its part of the automation logic, to realize the discrete eventautomation of the HGU. That is the main goal of this research.

12This section also introduces some concepts that are applied here.


To implement the automation architecture, two main data communication networksare defined: control network (or “control LAN”) and operation network (or “operationLAN”)13. The first one is responsible for the messages regarding the control and automa-tion (and local operation) of each HGU. The second one is responsible for the functionsnecessary for the centralized operation of the HPP. More details about the functions ofthose communication networks are presented below, in the Sections 9.8 and 9.9. The nextsubsections discuss the topologies of the communication networks (other considerationsof the networks implementation, as redundancy, are addressed thereafter).

Besides the communication networks, as discussed in Section 8.11, in some specificcases, mainly for safety reasons, some hardwired communications (using parallel pairs ofcooper wires) can be necessary for exchange of data (signals).

Just to remember, the connections to the communication networks should use fiberoptics as much as possible.

9.6.1 Networks Topologies

There are many applicable network topologies for automation systems. For example,the part IEC 61850-90-4 of the standard [157] presents some solutions and specifications.It also presents somes analyzes considering the advantages and disadvantages of eachsolution and also tests issues. Besides, another document (the part IEC 61850-90-410 ofthe standard) to provide a technical specification for communication networks within aHPP to be used in IEC 61850 systems is being developed.

The logical architecture has influence in the physical architecture (including the com-munication system), but does not completely define it. Considering the communications,one segment of the physical network can contain multiple data streams in “parallel” ofthe logical architecture introduced in the Section 9.3. Thus, there are many physicalarchitectures of communication that can support the proposed logical architecture. Thechoice here is a simple solution. The simplicity in this case is an advantage.

The main requirement of the solution is that all IED be accessible through the commu-nication network. Remember that, as stated in the Chapter 7 “Modelling of the Generat-ing Unit”, the IEDs names are unique in the network and each one can have an IP addressassociated to it. Also remember that, each IED has two access points, to implement theredundancy of communications.

This research proposes a unique communication network for control combining theprocess bus (not strictly in the sense of the IEC 61850 standard) and the local station

13The control LAN and operation LAN are illustrated in the Figures 9.1 and 9.2.


bus14. All IEDs are connected in that communication network. In the proposed architec-ture there is no distinction between process IEDs or unit (bay) IEDs. Thus, the Goosemessages are used not only for “horizontal” communications as normally is defined, butsomehow also for “vertical” communications.

As the definition of IP addresses is free, it is proposed to use fixed IPs for all devices andcomputers of the automation system. The definition of IPs can be based on the physicallocation of the components. For example, a range of IP addresses can be allocated foreach HGU in a structured way. One more time: the standardization is very important.

9.6.2 Control Network

The physical communication network for the proposed automation system can betreated in a simplistic way. As the Ethernet networks can be configured freely and theysupports client-server and peer-to-peer relationships, any topology that interconnects allthe IEDs is a communication structure able to achieve the functional requirements (ofautomation). Thus, the proposed physical communication architecture for control is anEthernet network connecting all IEDs (unit level, and maybe in the future including theprocess level) and all the automation devices of the local level. However, the determi-nation of the topology is influenced by other subjects such as availability, performanceand security. Thus, more deep analyzes to the choice of the best topologies may be done,causing changes in the simple proposed solution.

Considering the characteristics, advantages and disadvantages of the topologies citedin the Section 6.2, the tree topology was chosen for the control network (used in the locallevel and in part of the centralized level). That topology provides great flexibility forcommunications in the process and unit levels and also for integration with the stationlevels.

N. Yadav and E. Kapadia [101] present analyzes and comparisons of topologies forIEC 61850 systems on Ethernet. It is concluded that the redundant tree topology offersadvantages over a ring topology. For example, the tree topology has superior QoS (definedin the Section 6.2).

As stated in the Section 9.3, it is proposed to create VLANs for the communicationsof the centralized level with the local levels of the HGUs. The VLANs must consider eachHGU.

14Beyond the MU, in fact other IEDs of process are not truly presented in the figures, because all theequipment - primary system - are conventional. However, as stated in the introduction of the solution (inthe Chapter 3 “Evolution of the Automation Systems and Proposal”), the architecture allows to includeIEDs with process bus communications.


9.6.3 Operation Network

The ring topology was chosen for the operation network (part of the centralized controllevel). That network is not directly connected to many devices and the latencies are notso critical (in addition to the possibility of using higher communication speeds - due tothe nodes of the network).

As the number of nodes in that ring network is fixed (because the quantity of HGUsis unalterable and the quantity of real-time workstations predefined), there is no futureproblems of performance due to the growth of the network. In addition, the dual ringnetwork ensures that during the maintenance of one ring, the other one has intrinsicredundancy. That aspect is important for the high availability necessary on the centralizedcontrol level (normal operation level of all the HGUs).

As a matter of fact, various network topologies work well for the operation networkrole. The star (or tree) topology also can be applied in that network. For example, onestar can be used for each defined operation room (one star for each room: centralizedoperation room, dispatch room, backup room, and so on).

One of the reasons to use the tree topology in the other network (the control network,involving the local levels and part of the centralized level) is the definition of VLANs.The ring topology, from a physical perspective, does not provide clean traffic separation.However, that is not a big problem here, because in the part of the centralized controllevel in which the ring is used is not imperative to create VLANs. In that part of the levelthere is no Goose messages.

9.7 Time Synchronization

In the proposed architecture, the IEDs perform data acquisition and put time-stampsin all status and synchronize all measurements using a global reference time. This ensuresthat all data of the process are “globally time valid”.

As mentioned in the Section 6.4, the time synchronization here is based on the IEEE1588 standard. It was chosen the PTP instead of SNTP due to time requirements andcharacteristics of the PTP presented in that section. It is proposed to have a single sourcefor all synchronization: a GPS master clock (also known as grandmaster clock), installedin the centralized control level (presented in the Section 9.9 below - see the Figure 9.2).It provides the time reference for the automation (and protection) systems of all HGUsand for the substations automation systems. In addition, this clock may be a reference toany other systems in the HPP that require this resource.

If it is desired to increased the reliability, a redundant clock synchronization scheme


can be used [56]. In that scheme, when a failure of the active clock is detected, theother clock automatically becomes active and continues to provide the data/signals fortime synchronization. Some manufacturers also provide a backup function to maintainthe protection performance during the time of interruption of clock synchronized by GPSsatellites [166].

Remember that, even without the synchronism signal, the IEDs continue using theirinternal clocks (which generally have high accuracy). Therefore, the use of redundancy inthis case should be thoroughly assessed.

Ordinary clocks can be included in the architecture. For example, one slave ordinaryclock (receiving time from the grandmaster clock) can be used for the time synchronizationof the whole substation (one clock per substation).

9.8 Local Control

Utilizing the physical communication structure chosen in the Section 9.6, each IED isdirectly connected to a switch. Thus, there are no collisions in the physical medium. If thenetwork has high speed and priority procedures to order the sequence of the frames in theswitches (see the Section 6.2), the communication system can be considered deterministic(for the application). Moreover, the switches should be capable of creating VLANs, asstated in the Section 9.3.

9.8.1 Process and Unit Levels

The process equipment (conventional) are connected to the IEDs through parallel pairsof copper wires. The signals from the process are mapped to the IEC 61850 standardmodels in those IEDs. They have the boundary LNs (including LNs of the group S) toprovide an image of the process.

Each IED is associated to a set of equipment (defined in the Section 2.6 as “systems” ofthe HGU). Besides the data acquisition, the processing of the acquired data is distributed.The logics of automation associated to each set of equipment (system) is realized in thosededicated IEDs. Thus, the automation is genuinely distributed and the IEDs also containLNs for the secondary system functions, as stated in the Chapter 8 “Generating UnitAutomation”.

In the solution without process bus (in the IEC 61850 standard sense), some con-nections of boundary LNs with automation LNs are internal (they do not pass throughcommunication networks). Those connections are among LNs of the same IED (were arethe boundary LNs). The external connections, with other IEDs, are realized through com-


munication networks. In a high level of abstraction (application layer of the OSI model),those internal and external connections are seen in the same way.

It will be considered that the CTs and VTs are interconnected to the communicationnetwork through a MU. To simplify the synchronization of the current and voltage samplesof all phases, all instances of the LN classes “Current transformer - TCTR” and “Voltagetransformer - TVTR” are allocated in a single MU. It also is important to create VLANsincluding the consumers of such data, as possibly the “Voltage Regulator (VReg)” and“Electronic Governor (EGov)” systems (as stated above, in the Section 9.3). In the proposedphysical architecture, the sampled values are restricted to the local control level (they donot go to the centralized control level - although it is possible).

If it is possible, optical instrument transformers [38] should be used instead of con-ventional ones. In those new instruments, the optical signals representing the currentsand voltages are transformed to sampled value messages and sent to the IEDs throughthe communications networks. In the practice, that instruments have their our integratedMUs. This approach presents a serie of advantages as, for example, safety and reductionof the amount of needed instruments (for different applications).

The main transformer (or bank of single-phase main transformers) of the HGU is onthe boundary of the generator and substation. The side which the automation of thatequipment will be integrated must be chosen. Here, it is considered that it is part ofthe HGU automation system (it is represented by one of the systems on bottom of theFigure 9.1 and listed in the Table 2.1). That choice should be based on the interactionof the transformer automation system with the HGU automation system, on the phys-ical locations, etc. Therefore, the automation of the main transformer has a dedicatedIED (that could be part of the substation automation system too). That IED has theautomation logic controls the cooling system of the transformer.

In the case study there are three IEDs, one per phase, since the main transformer is abank of three single-phase transformers (systems: “Main Transformer - Phase A (MTraPhA)”,“Main Transformer - Phase B (MTraPhB)” and “Main Transformer - Phase C (MTraPhC)”).Those IEDs can be installed in the same panel board. As discussed below, the three IEDsare connected to the automation system network through the same (redundant) physicalconnection (a switch - not shown in the figure - may be necessary). Furthermore, as alsodiscussed below, maybe it is possible to have a single IED for the three phases.

As stated in the Section 2.6, in the proposed architecture, the circuit breaker (andassociated disconnectors) of the HGU belongs to the substation automation system (it ismodelled in the system “Unit Bay (UBay)”). Therefore, it is necessary a communicationchannel with that system (as shown hereafter on the bottom of Figure 9.2).

In the proposed architecture the manual synchronization of the HGU is not possible.


It is planned only the automatic (and semi-automatic) synchronization scheme, using a“synchronism check relay” (adherent to the IEC 61850 standard) to verify and control thesynchronizing conditions, i.e., voltage, frequency and phase. An instance of the LN class“Synchronism-check - RSYN” and one instance of the LN class “Synchronizer controller -CSYN” should be used.

Different schemes for synchronization of the HGU are possible. The details of thoseschemes are not presented in this report.

As the speed of the HGU is a very important information, to increase the reliabilityin the proposed solution there are two sources for that information. The main measure isprovide by the speed governor (which may have redundant sensors and redundant IEDs).The second is provided by an independent speed sensor. To that scheme be effective, theIEDs also must be independent. That solution is suggested in the Chapter 8 “GeneratingUnit Automation” (Section 8.14). The last cited speed measure can be used directly inthe control logics (together the other speed measures, for example, in a majority votingalgorithm) or it can be used in case of loss of the other measurements (using validatinginformation - see the Section 8.11).

That is an example of necessity of redundant measurements. Analyses of reliabilitymay show that other measures must have similar approach (redundant sensors in differentIEDs). The proposed physical architecture facilitates to implement that kind of solution.

9.8.2 Station Level

The local station level basically consists of the local station computer and local HMIs.The functions and characteristics of those computers are presented in the Section 9.5.They receive data from the IEDs and send commands, through MMS messages (introducedin the Section 6.8).

The transmission of data for supervision and operation from the process to the cen-tralized control level (and vice-versa) pass through the local computer. If the local controllevel is lost (the automation system fails), it is not possible the operation through the cen-tralized level, because the primary real-time database is at local control level (it works asa proxy for the centralized level). On the other hand, the local control level is completelyindependent of centralized control level.

As it is considered that que local control level has a very high availability, the ques-tion discussed above is not a problem. Anyway, as future work, an alternative solutionproviding total independency of the two levels may be studied (all the advantages anddisadvantages must be addressed). In advance, it is supposed that the main drawbacksare related to the data integrity and unnecessary redundancies.


9.8.3 Redundancy of Communications

The subject redundancy of communications already was introduced in the Section 6.2.Here it is discussed focusing in the solution of communications for the local control level.

A basic redundancy requirement is that each IED has two access points (communica-tion ports with different addresses) forming independent network segments. Thus, if anycomponent of a segment fails, just that segment does not work. Moreover, every solutionmust have good switch-over performance, preferably the reconfiguration time should bezero.

For the redundancy of the communication structure, there must be at least two inde-pendent switches for each HGU at the local control level. If one switch fails, the otherone will ensure the communications for the normal operation of all local functions. Be-sides, with two switches dedicated to one HGU, the maintenance and error detection areeasier. Thus, as already stated (here and in the the Section 9.6), all devices must havetwo communication ports to be connected to both switches. It makes little sense to havethat redundancy if the devices do not have two independent communication ports. A notideal solution is to include a small switch (with PRP) for each IED that has only onecommunication port, but can be utilized in specific cases to maintain IEDs with a singleport.

As the system proposed here has a fully redundant network, the redundancy schemeof the PRP (introduced in the Section 6.2) can be applied.

9.8.4 Proposed Architecture

Considering the statements above, one model of a basic physical architecture for thelocal control level of the automation systems of large HGUs was created. The Figure 9.1shows that conceptual architecture, including the IEDs and the local station. The pro-tection system is outside the scope of this research (although there are interconnections).

Note that, in the figure there are redundant communication links of optical fibers.Some links are represented in red continuous lines and the corresponding ones representedin blue dashed lines.

The panel boards, or cabinets, on the bottom of the Figure 9.1 represent the systemsdefined in Section 2.6 of the Chapter 2 “Hydroelectric Power Plants and Hydro Gener-ating Units”. In principle, each panel has an independent IED for localized automationfunctions, naturally, including the data acquisition. Note that, they are connected toeach upper star switch (“Switch 2 - A” and “Switch 2 - B”) through another star switch(“Switch 1 - A” and “Switch 1 - B”). Thus, that topology is like a tree.

The major systems of the HGU, the “Electronic Governor (EGov)” and the “Voltage


Figure 9.1: Conceptual physical architecture of the local control level.

Regulator (VReg)” (represented in the Figure 9.1 on the right middle) in fact are not onlyan IED, but complex systems (specially the last one). Anyway, they must have interfacescompliant with the IEC 61850 standard. Thus, from the physical and logical standpoints,those systems can be viewed as single IEDs. They should continue redundant (internally)for high reliability, as they are in conventional approaches.

Note that, the redundancies of IEDs are not represented in the Figure 9.1, only forsimplicity do the figure.


The local control network is a 100 Mbit/s Ethernet (or higher)15. That bandwidth isenough for all communications of the automation system of the HGU, including situationsof avalanche (considering only one MU providing data of one circuit). Thus, the switchesof the HGU communication network must reach at least 100 Mbit/s (it is suggested 1Gbit/s for inter-switch communications).

The local control network comprises four Ethernet switches. That configuration al-low to split the communications in two completely separated networks (network “A” andnetwork “B”). As the networks are not interconnected, they can be considered fail inde-pendent (see Section 9.2). That redundant configuration increases the reliability and alsofacilitate the maintenance (although, normally the maintenance of the automation systemis done when the HGU is stopped).

Note that, each component of the automation system is connected to both networksthrough different communication ports. Remember that, as the PRP is used in the system(see Section 6.2), all IEDs and computers (including the installed in the centralized leveldiscussed below) always receive two messages and discharge one of them (the second).Also note that, as the switches of each network are not themselves connected, there areno problems of loop of messages.

The redundant IEDs and computers must work in a “hot standby” mode. The neces-sities of redundancy of sensors and actuators should be analysed for each specific case.Besides the turbine speed sensor and the stopping solenoids of the turbine speed governor,here is not proposed other redundancies of sensors or actuators.

The “Hydraulic Governor (HGov)” system has a redundant direct communication linkto the “Electronic Governor (EGov)” system. The “Excitation (Excit)” system has aredundant direct communication link to the “Voltage Regulator (VReg)” system. Thoseconnections are not shown in the Figure 9.1, for simplicity.

The systems “Electronic Governor (EGov)” and “Voltage Regulator (VReg)” by theirturn, are connected to the switches (“Switch 2 A” and “Switch 2 B”) that are directedconnected to the the centralized control level. The main IED of the HGU (associated tothe “Generating Unit (GenUnit)” system) also is connected to those switches.

All IEDs of the other systems are connected to the switches one degree below (“Switch1 - A” and “Switch 1 - B”). Those systems together have almost the same interchange ofdata than the IEDs of the last paragraph.

The MU, which provide the sampled values of the measures of the instrument trans-formers, is illustrated on the left side of the Figure 9.1. As already commented above,that MU is connected through one specific VLAN to the systems “Voltage Regulator(VReg)” and “Electronic Governor (EGov)” (and to the HGU protection system). Note

15Nowadays almost all LANs are implemented using Ethernet at 100 Mbit/s or higher [101].


that, electrically that MU is connected to the generator output terminals (it is not theMU in the high voltage side, after the main transformer).

The following sets of systems have a single redundant physical connection link (eachset) to the local control network (that can be implemented through dedicated smallswitches not represented in the Figure 9.1):

• “Lower Bearings (LBear)”, “Middle Bearings (MBear)” and “Upper Bearings (UBear)”;

• “Main Transformer - Phase A (MTraPhA)”, “Main Transformer - Phase B(MTraPhB)” and “Main Transformer - Phase C (MTraPhC)”.

The subject “panel board” is not explored in this research. There is only one remark:if necessary (for any reason as layout or economical questions, for example), more thanone system can share the same panel board. Thus, some panel boards can host more thanone IED with different functions. On the other hand, some systems can require more thanone panel board, for connections16, for example.

For distributed automation, the main controller of the HGU (the old head of cell,defined in the Chapter 8 “Generating Unit Automation”) is an IED with processing andcommunication capacities necessary to coordinate the HGU automation (containing oneinstance of the LN class “Hydropower unit - HUNT” and the necessary instances of theLN class “Hydropower unit sequencer - HSEQ”). Note that, it may be a controller muchsimpler than those used for traditional centralized architectures.

The conceptual models developed in this research (for modeling and logics of automa-tion) allow realizing estimations and analyses about the data flows. For example, thequantity of outgoing and incoming Goose messages may be analyzed. Nevertheless, usingthose models, the analyses require a great effort do identify all the messages and theirrespective sources and sinks, but it is feasible with the help of software tools. Due to thelack of time (and appropriated tools), detailed analyses of data flows were not realized inthis research. It is a good suggestion for future works, because those analyses can indicatepossible problems and imply modifications in the automation system design.

Recapitulating, the PTP is the method chosen for time synchronization. Thus, thetiming is done through the communication network, providing greater flexibility. Thegrandmaster clock is at the centralized control level (shown hereafter, in the Figure 9.2).

The actual technologies allow the integration of the automation and control systemswith the protection system. A. P. S. Meliopoulos and A. Bose somehow assent to thatstatement [29]. Thus, it is not necessary a separated infrastructure of communications for

16It is possible to use IEDs (for the systems - not a centralized one) with remote inputs/outputsmodules, but that subject is not discussed in this report.


automation and protection. For example, the protection system can use Goose messagesin the same way that the automation system uses.

For illustration purpose, the protection IED is represented (in fact the system canhave more than one protection IED) in the Figure 9.1. To implement the redundancy ofprotection, each protection system (“Main A” and “Main B”) may be connected to bothswitches (“Switch 2 - A” and “Switch 2 - B”), to avoid common modes of failure.

The power source for the components of the automation system must be reliable.Usually direct current power sources, containing battery banks, are used for supplyingthe devices (in the case study, the “DC Power Supplying (DCPowSup)” system). Com-puters (servers and workstations) may also use that power source or be powered by aspecific uninterruptible power supplying systems (the system “Uninterruptible Power Sup-plying (UPowSup)”), likewise dedicated small uninterruptible power suppliers (the popular“no breakers”).

The same communication network may be utilized for synchronized phasor measuringcommunications. In that case it is necessary to include at least one Phasor Data Con-centrator (PDC) [167] in the architecture. The configuration of a specific VLAN for thatpurpose is highly recommended.

9.9 Centralized Control

The centralized control level is defined in the Section 8.3 and represented in the Fig-ure 8.1. That level hosts the devices for supervision and control of the whole HPP (inthis research, including the substations).

In this section the physical connections and integration of the centralized control levelwith external systems are commented and, then, the architecture is presented.

9.9.1 Main Interconnections

In the traditional (or past) solutions, the gateways17 are used to translate the datafrom/to the local control level (HGU automation level) to/from the centralized controllevel (HPP automation level). Generally intermediary protocol as IEC 60870-5-101 “Tele-control equipment and systems - Part 5-101: Transmission protocols - Companion stan-dard for basic telecontrol tasks” [168] and IEC 60870-5-104 “Telecontrol equipment andsystems - Part 5-104: Transmission protocols - Network access for IEC 60870-5-101 using

17Gateway is a general-purpose or dedicated device with a mechanism that attaches communicationnetworks to connect devices with different protocols. The gateway can be seen as a protocols translationinterface.


standard transport profiles” [169] are used [170]. If the centralized control level is adherentto the IEC 61850 standard, as proposed in this research, that translation is not necessaryanymore.

One advantage of that approach is the standardization of the data: all points in thelocal level and in the centralized level can use the names and references defined in theChapters 5 “Description of the Generating Unit”, 7 “Modelling of the Generating Unit”and 8 “Generating Unit Automation”. Note that, some points (same references and names)can coexist in both levels.

In the proposed architecture, switches are used to connect the local control to thecentralized control. Thus, there is only one communication network (there is anothernetwork - for centralized operation - presented in the next section).

The automation system of the electrical substations can be connected to the abovecited switches. Thus, if the substation automation systems are adherent to the IEC 61850standard, the proposed physical architecture allows full integration with them. It is pos-sible to send/receive Goose messages from/by the HGU (local control level) to/from thesubstations. That characteristic can be utilized, for example, for the HGU synchroniza-tion, interlockings and protection functions.

9.9.2 Integration with Other Systems

The physical architecture of the automation system should also include “external”communication channels. External systems can be other automation systems and corpo-rate systems within the HPP and off-site, for example the regional control centers (definedin the Section 8.3 and represented in the Figure 8.1).

Generally, one gateway function for each type of protocol (not included in the IEC61850) is required. The gateways must have resources of an IEC 61850 client and, in somecases, server, as well as the corresponding functions for the others protocols.

As already mentioned, in this research it is considered that there are separate automa-tion systems for the substations of the HPP (outside the scope of the research). However,it is considered that they are integrated to the centralized level of the automation systemof the HPP (centralized control level of the HGUs). Thus, the real-time operation of thesubstations is done in the same workstations and share other resources (as historian, forexample).

As it is supposed that the automation system of the substations are compliant withIEC 61850 standard, a common reality nowadays, gateways are not necessary.

The corporate systems (or enterprise systems) can be technical and/or administrative.The process and production data of the automation system can be reused in the appli-


cations of those systems. The applications can be related to strategies of operation ormaintenance, for example. The amount and high availability of the process data bringsopportunities to create infinity applications, some examples can be seen in [171]. Onetime that the data are available, it is possible to produce many useful information. Thedata usefulness does not finish once the purpose for which it was collected was achieved[172].

Normally, the old automation systems were not connected to the corporate (or busi-ness) LAN. In some cases, existing connections are adapted to support specific necessities(not foreseen in the original project).

The possible additional communication connections necessary for wide area protectionare not addressed in this report and, therefore, are not represented in the figure of thearchitecture.

9.9.3 Proposed Architecture

The Figure 9.2 shows the basic physical architecture of the centralized control level(centralized station: control and operation), which comprehends all HGU, and its inter-connections.

Note that, in the figure there are redundant communication links of optical fibers. Foreasy identification, some links are represented in red continuous lines and the correspond-ing ones represented in blue dashed lines.

The specific components and interfaces for automation of the spillway are not repre-sented in the figure.

Note that, the operation LAN presented in the figure is different of the station LAN(or bus) specified in the IEC 61850 standard.

The centralized control level has two communication networks, control LAN (the sameof the local level) and operation LAN, interconnected by a router. The networks areGigabit (1 Gbit/s) Ethernet, due to the larger volume of data (disregarding the sampledvalues of CTs and VTs, existing in the local level). In a brief analysis that bandwidthis enough for the applications. Besides, an advantage of using Gigabit Ethernet is thatthe network will be prepared for the coming functions (future applications, which canrequire more communication capabilities). Naturally, faster communication networks canbe utilized.

The first network, the control LAN (the stars in the bottom of the figure), comprisestwo main Ethernet switches. That configuration allows the independency of networksdescribed in the last section (local level). In fact, that network is the same of the locallevel (presented in the Figure 9.1). All the messages of hard real-time stack are restricted


Figure 9.2: Conceptual physical architecture of the centralized control level.

in the network below the router.The second network (the rings in the top of the figure) comprises many small Ethernet

switches. That configuration allows the easily connection of any device. As it is clear inthe figure, that network is interconnected to the first one by the routers. Thus, for thetime synchronization of the elements of the second network the routers must implementboundary clocks (see the remarks about the clock below).

Note that, the routers also connect the redundant networks (“A” and ”B” - red anddashed blue in the figure). That configuration allows the simultaneous work of the tworouters even if one network of the local level fails.

For cyber security reasons, the firewall function (access control lists) of the routersshould de activated. As the IPs of the elements of the network are fixed (see the Section 9.6above), it is possible to configure firewall rules to allow data traffic between specific


components and ports. For example, the firewall can keep access control lists managingdata flows in a secure manner.

Note that, the VLANs defined in the Section 9.3 ensure that the communicationsbetween HGUs is not possible, although they are in the same physical communicationnetwork.

It is possible the creation of a “backup” centralized control level, for contingencies.It can have similar architecture (maybe reduced) and same configuration and should bephysically connected to the switches of the figure (A and B). The switches must workin the situation to guarantee that the contingence centralized control will work properly.Thus, additional switches (in another safe place) can be used.

The central computer (redundant) has features similar to the local station computer,excluding the database and historian and maybe including some real-time applications (asthe joint controls, for example). It is possible to include different servers in that level forspecific real-time operation applications, but as can be seen in the top of the Figure 9.1,there are application servers in the second network of the centralized control level for thatpurposes (considering that they are very soft real-time applications, with response timesgreater than a second).

As already defined, the redundant computers must work in a hot standby mode. Notethat, all computers have dual links, through different switches, to the communicationnetwork. As stated above, all devices and computers use the PRP; thus, they alwaysreceive two messages and discharge one (the second one). All data for supervision andoperation pass through the central computer.

In the first network there is a clock synchronized by GPS satellites (shown in the bot-tom of the figure). It is the main clock of the HPP. Thus, it should be a very precise clockand have to have the necessary interfaces and protocols to support the synchronization oftime in the whole HPP (including the substation).

Note that, each local control level of the HGUs is connected to the central computerand to the master clock through the same quantity of switches. That was one reason tothe choice of the network topology.

The architecture foresees various workstation for the HPP (and substation) operation.The central HMIs (and video walls) can be installed in different places in the HPP, as forexample in a “centralized control room” (real-time HPP operating room), in a “dispatchroom” (operation of the interconnection of the HPP with the regional/national powersystem), in a “contingence room”, etc.

At the centralized control level there is a dedicated computer (redundant: A and B)for historian functions. It can be supplied with the data sent by the centralized stationcomputer (from the real-time database) or by the local station computer (local historian).


The data that go into the historian should be selected, as already mentioned.As show in the left upper corner of the Figure 9.2 the automation system is intercon-

nected with the corporate network. That network is accessible by the corporate computersand have diverse computacional systems. The level of those systems can be called of “En-terprise Level” (it is not represented in the Figure 8.1).

The corporate systems may need to access the historical database cited above. Theconnections must be secure, and thus it should have at least a firewall, as show in thefigure. A good idea is to create a new historical database out of the militarized zone. Thatis the proposed solution here (the “intermediate database” introduced in the Section 9.5).The actualization of the intermediate database must be continuous. Thus, the corporatenetwork can have desktop computers able to visualize the process data almost in real-time.

The architecture foresee applications servers. They can run diverse applications uti-lizing the real-time process data. For example, all software of the Energy ManagementSystem (EMS) and specialist systems of support for the real-time operation and loaddispatch can run on those servers.

It is required a data actualization time on those last computers (historian, applicationsservers and HMIs) around 1 second (usually 1 or 2 seconds). That means that, a changeof the data in the field (sensors) should be actualized in the computers in a time less thanaround 1 second. Note that, it is the actualization time and not the resolution time.

Nevertheless, the Figure 9.2 has a computer for engineering, utilized for analysis,configuration and parameterizations of the automation system.

The figure also illustrates the printers, accessible by all the clients across the network.As already discussed, in most cases, in addition to the data exchange internal to the

installation, the automation system also sends information to and receives commandsfrom outside the HPP (remote control centers). That functionality is performed by thegateway shown on the right side of the figure. As the IEC 61850 does not supportthat communication, it is suggested to use the IEC 61970 standard [138] (depending onthe remote control centers characteristics). As cited above, there are evidences that anharmonization between IEC 61970 and IEC 61850 is going to occur. By other side, someauthors consider that the IEC 61970 and the IEC 61850 standards are complementary.

The figure does not show the IED for the spillway and/or sluice automation, whichmust be redundant. Each one must have a simple local HMI and an independent com-munication channel with the centralized station. The connection of those IEDs shouldbe in the first network of the centralized level. Although it is the same local controlnetwork, note that, there is no need of communication between the spillway and/or sluiceautomation system and the local control system of the HGUs.

It should be clear that the Goose and sampled values messages are restricted to the


local control level and part of the centralized control level (the first network, presented inthe bottom of the Figure 9.2). The second network of the centralized control level, afterthe router, receives only states, root mean square values and filtered values. Lastly, thesampled values are not sent to the centralized level (they are restricted to the local level).

The proposed approach is quite possible, because the interchange of data with thesecond network (presented in the bottom of the Figure 9.2) is through MMS messages.The MMS protocol operates in the network layer (layer 3 of the OSI model), thus themessages can cross the routers.

As discussed in the local control level (last section), the data traffic is an importantaspect of the system. Thus, the data flow to/from the centralized control level requiresattention. Studies and analyses of the necessary data and the frequency of their transmis-sions may be realized to improve the performance. Different types of data and differentstation applications have diverse requirements. The data size can be since bits to kilo-bytes; and the frequencies can be since seconds to one day. Those analyzes can be includedin the future works suggested below.

Only to cite the case study, in the very specific case of the Itaipu Binacional, in thepractice the HPP can be seen as two independent HPP (on the same dam): one in 50Hz and another one in 60 Hz. Thus, the physical architecture of the centralized controllevel must be modified to consider that particularity. The most simple solution is theduplication. Independent communication networks, devices, computers, panels and soon should be used for each sector of the HPP. Specific data interchange can be realizedbetween the systems; or also a more elaborated integration can be implemented. Thesame idea can be applied in other HPPs which require some separation like that.

9.10 Reliability Analyses

Along this chapter, some considerations about reliability were discussed. The reliabil-ity of the whole automation system should be evaluated and, if necessary, improved. Thissection introduces an example of analysis of reliability using the case study system. Theanalyses regarding other systems are similar.

9.10.1 Reliability of the Case Study

As example, this subsection presents studies of the reliability regarding the “MiddleBearings (MBear)” system. The approach utilized is the fault tree, introduced in theSection 9.2.

The values of MTTF utilized in the calculations presented in this report are listed in


the Table 9.1. It is assumed that all IEDs have the same MTTF value. Note that, herethe MTTF is applied to reparable items.

Table 9.1: Typical MTTF values.Element MTTF (years)Computer 15IED 90Switch 30

Supposing that all devices are monitored and on site there are a maintenance staffand all necessary spare parts, the value of the MTTR utilized in the calculations (for allelements) is 12 hours, a conservative value.

The analyzes and figures includes only events related to the local automation system(failures of equipment and field devices are not included). Besides, only the main elementsof the automation system are considered. For example, the failure of the clock is notconsidered. It is admitted that it is a very reliable element (besides, the automationdevices have internal clocks). That example has one more detail: the lack of a precisetime synchronization is not fatal in the functions analysed here.

The next subsection presents a simplified example of analysis of failures.

9.10.2 Global Unavailability

The Figure 9.3 shows a fault tree of the automation system associated to the “MiddleBearings (MBear)” system. Note that, the figure includes only events of that system.

Also note that, the figure (and analyses) considered only the general failures of theIEDs18, computers and switches. The failures of specific components as, for example,power supplies, fiber optics connections and wire connections are not considered. In spiteof the fact that some details as, for example, dual power supply can cause great changesin the MTBF values of the elements. The reliability of the software also is not explicitlyconsidered here. The main idea is only to show an example of analysis.

The circles on the bottom represent basic events. They are basic initiating failuresrequiring no further development. The rectangles represent intermediate or top events.The AND gates are utilized where the output failure occurs if all input failures occur. TheOR gates are utilized where the output failure occurs if at least one of the input failuresoccurs.

18Considering that the unavailability of both switches is very small, the fault tree was simplified in thecalculation of the probability of the event “IED Communication Failure”.


Figure 9.3: Global Fault Tree of the “Middle Bearings (MBear)” system.


The values presented in the Figure 9.3 are the unavailabilities. Note that, they shouldbe multiplied by 10−6.

The box “Midle Bearings System Global Failure” is a top event that represents anyfailure in the “Middle Bearings (MBear)” system (including failures due to failures ofthe associated IEDs, local computer and communications). Note that, as the analysis isglobal, the failure of the IED of the “Turbine (Tur)” system is not included (it must beincluded in a specific fault tree for the “main pump turn on” function).

As can be seen in the fault tree, due to the redundancy of communications (dualswitches), the effect of the failures of the switches have little impact in the availability ofthe “Middle Bearings (MBear)” system. The same occurs for the redundant local computer.Therefore, the probability of the intermediate event “Local Computer CommunicationFailure” to occur is almost null, as planned (see the sections 9.5, 9.6 and 9.8) and theavailability of the system depends mainly of the IEDs.

The system unavailability is 0,0061% (or a downtime of 32,01 minutes per year, oryet, an availability of 99,9939%). Note that, the value was obtained considering anyfailure in the whole automation of the “Middle Bearings (MBear)” system, therefore, it isconsidered that a failure in any associated IEDs results in a failure of the “Middle Bearings(MBear)” system (even though most of the functions keeps running). For example, if dataof another IED is included in the logical diagrams of the “Middle Bearings (MBear)” system,the new value of unavailability is 0,0076% (representing a downtime of 40,01 minutes peryear and an availability of 99,9924%), a value 25% higher (worse).

In a similar way, a function implemented in one specific IED can be duplicated, asredundancy, in another (existing) IED. Thus, a fail of one of the IEDs will no make theautomation unavailable. In that case, the new value of unavailability for the exampleabove is 0,0046% (representing a downtime of 24,01 minutes per year and an availabilityof 99,9954%), a value 25% lower (better). Note that, if all functions implemented in theIEDs are redundant, the unavailability will be almost zero (1.34 × 10−8). In that case,the weakness is in the sensors and actuators (not considered in the figure and in thecalculations).

The failure analysis of each function of the “Middle Bearings (MBear)” system can berealized separately. That approach allows to verify the parts of the system that shouldbe improved to obtain greater availability, utilizing, for example, redundancies.

9.11 Security Zones

In this section, the zones and conduits (introduced in the Section 9.11) of the proposedarchitecture are defined. They are created considering the devices common functionality


and common security requirements. Thus, the creation of zones is driven by the levelsof the automation system (defined in the Section 8.3) and the physical architecturespresented in the Figures 9.1 and 9.2. In fact, the assets of the zones are the componentesof those figures. The model is used to assess the cyber security of the automation system.

The Figure 9.4 (on page 195) shows the architecture broken down into zones and theirconduits. The zones presented in the figure are an initial approach. The definition ofzones is an interactive process, thus new zones can be created as the analyses of securityare conducted.

Five main zones are defined: Process Control Zone; Centralized Operation Zone; Off-Site Operation Zone; Intermediate Zone; Information Zone. The figure also show foursub-zones: Equipment Zone; Local Control Zone (one for each HGU); Centralized ControlZone; Substation Control Zone. Note that, the “operation” zones area associated to the“station levels” defined in the Section 8.3 (see the Figure 8.1).

The Process Control Zone has the time-critical network that connects the automationdevices, including the control computers and the local HMIs. That zone is on the industrialarea of the HPP. Here it is considered only one security zone because it is assumed thatthe four sub-zones has the same level of security. Thus, there is no necessity of separatedanalyzes for the sub-zones and internal conduits represented in the figure (U119 and S1).Besides, according to the proposed architecture the zone has only one communicationnetwork (shown in the Figure 9.1 and part of the Figure 9.2).

The Centralized Operation Zone has the network that connects the automation systemcomputers to the historian, application servers and consoles of operation (HMIs). Nor-mally that zone has physical access control (only authorized personal is allowed). It isrepresente in only one box in the figure, but it can occupy different physical areas in theHPP (for example: a HPP operation room and a dispatch room).

The Off-Site Operation Zone is the NCC outside the HPP (see the Section 8.3).The Intermediate Zone contains only the intermediate database introduced in the

Section 9.5. It can be seen as an industrial/enterprise DeMilitarized Zone20 (DMZ).The Information Zone has the corporate network. It has a connection with the inter-

mediate database for interchange of data, as described in the Section 9.9. That zone hasdesktop computers to run the applications related or not to the process. The assets areinside the HPP, normally in the administrative area. The physical access is controlled,but not too rigorous. Naturally, other DMZs can be implemented.

In fact, the Information Zone represented in the figure can contain other communica-19There is one conduit like U1 for each HGU.20The DMZ is a network segment that is logically between internal and external networks. Its purpose

is to support an additional layer of security.


Figure 9.4: Zones and conduits of the proposed physical architecture.

tion networks. However, here it is considered that they have the same security level, thusone zone is enough. In the practice, according to the security policies of the company canbe defined different zones (one of them the Information Zone defined here).

It will be admitted that the Information Zone has a DMZ part, which is connectedto the Internet (an “Public Zone”, shown in the upper left corner of the figure). Thus,the Information Zone showed in the figure has, at least, one “corporate network” and one


“corporate DMZ network”.Also it is possible to create a specific network (an “information network” isolated

from the corporate network) for connection to the intermediate database, once that notall corporate users need to access the process data. In that approach, the informationnetwork deal with the systems for operation management and the corporate network dealwith the enterprise systems, including the bushiness planning.

Note that, four conduits were defined (identified in the figure as C1, C2, C3 and C4).The next subsection presents the requirements of security.

9.11.1 Security Analyses

For a qualitative approach to address the security, three security integrity levels weredefined: “low”, “medium” and “high”. Those levels define the required protection factorsof security. The last one means that it is strictly forbidden the access to the zone, becausethe consequences are drastic.

This is an initial approach; thus, other intermediate levels can be defined. The IEC62443 standard [84] presents several definitions and types of security levels and how theycan be used.

Considering the three levels define above, the Process Control Zone has level high;the Centralized Operation Zone and Off-Site Operation Zone (out of the scope) have levelmedium; the Intermediate Zone and Information Zone have level low.

The potencial consequences (loss of data integrity, loss system availability, equipmentdamage, personal injury, etc.) related to the assets also are rated considering three qual-itative levels: “low”, “medium” and “high”.

As example, a document for “security requirements” of Process Control Zone is pre-sented in the Table 9.2.

Sophisticated attacks means require advanced knowledge of security, domain or of thetarget system, or any combination of those knowledge.

Now it will be verified if the system meet the security assurance levels or if modifica-tions are necessary.

Once the security requirements are defined, the appropriate security services for eachconduit can be defined. As stated in the Section 6.3, the most used resource of securityis the firewall.

Foreseeing the security requirements, the proposed architecture also has the necessaryfirewalls. Note that, all the conduits are defined from a firewall (considering the firewallfunction of the router). On the other hand, the internal conduits of the Process ControlZone are defined from switches, due to the fact that they are inside a security zone,


Table 9.2: Characteristics of the “Process Control Zone”.Characteristic Description

Name Process Control Zone.Definition This zone includes all security integrity systems for the control

of the HGUs and in site centralized control.Physical Boundary Located within the process equipment (panel boards), local con-

trol room and centralized control room (devices area).Physical Access Points Doors to the rooms and doors of the panel boards (in the indus-

trial area).Connected Zones Centralized Operation Zone and Off-Site Operation Zone.Logical Boundary Interface with the two connected zones through two distinct con-

duits.Logical Access Points Centralized Operation Zone / Conduit C1 (router); Remote Op-

eration Zone / Conduit C2 (router).Data flows Centralized Operation Zone and Off-Site Operation Zone: read

only data (statuses and measures) of IEDs through the local com-puter; data writes from centralized computer to local computerand them to the IEDs (binary commands and set points).

Assets / Consequences IEDs (high); Local Computer (high); Local HMIs (high); Central-ized Computer (high); Engineering Station (high); Master Clock(high); Switches (high); Router (high); Gateway (high); Firewall(high).

Security Level Target High.Security Objective To protect the integrity and availability of the HGUs automation

systems (process data and automation, control and protectionfunctions).

Security Capabilities ofAssets

It is assumed that the assets have some services for security,thus they are capable of withstanding unsophisticated attacksand malwares. However, the assets are not capable of with-standing with moderately sophisticated or sophisticated attacksor malwares.

Vulnerabilities Absence of antivirus software; off site accesses; no passwords orweak passwords; unfettered user accesses; access to the devicesports; absence of data traffic analysis.

Threats Malware (malicious code); internal or external unauthorized ac-cess; reprogramming of automation (and protection) functions;denial of service attack (loss of data communication and/or au-tomation functions).

as explained before. That is particularly important for the performance of the controlmessages.

The applicable security policies for the analyzed zone - Process Control Zone - are (atleast):


• all connections to the zones must be through the defined conduits (C1 and C2);

• the router and firewall must be configured to allow only the essential services;

• specific rules for the firewalls must be created considering best practices;

• the firewalls rules must consider the test systems;

• white lists must be defined (and utilized);

• off site virtual private network accesses can not be allowed;

• installation and actualization of software antivirus in the computers;

• rules for creation and utilization of accounts and strong passwords must be definedand applied;

• auditory and online monitoring of the data traffic through the conduits must bedone and analysed;

• all devices replacement or installation must be previously approved;

• all configuration and programming must be internal to the zone;

• rules for backup of the configurations of the devices and computers must be define(and realized);

• inhibition of the external connections of the computers (as USB ports) - or rules forutilization of them, if necessary;

• rules for utilization of the notebooks for maintenance must be defined;

• physical access control to the industrial area and specific rooms must be installed;

• access control to the panel boards, rooms and devices must be installed;

• the staff must have cyber security experts.

The rules cited above can be integrated in the company security policies. The new rulesshould be build upon existing rules (modification of the existing rules can be necessary).In addition, it is mandatory to follow those policies.

The generation of audit logs, which should be checked periodically, is important forthe security too.

After all, it is recommended to use other security features, as the ones listed in [7] [8].


The analyzes presented here should be detailed. Other information can be aggregated,as the characteristics considering each asset of the automation system. For example, onetable for each asset with the threats, consequences, likelihoods, risks, and so on may becreated.

Similar analyzes can be realized for the other security zones showed in the Figure 9.4.Remember that, they have lower level of security.

F. C. B. Farias, P. P. G. F. Garcia, and M. F. Mendes present other examples of cybersecurity analyzes in [102]. They can be utilized as references or starting points.

9.12 Critical Analyses

Applying the proposed architecture, all the control functions related to the HGUs canbe integrated. The costs are not addressed in this research, but according to J. Orth [27],“with the integration of process control and electrical control in power plants, cost savingscan be achieved in engineering, operation and maintenance”. Thus, there are indicationsthat the costs can be smaller.

The proposed architecture provides supervision and control at three levels: centralizedcontrol, local control and unit control. The last one is a limited control, used only insituations of contingences or maintenances. Those different possibilites of operation helpto increase the availability of the HGUs (generation of energy).

As can be seen in the figures of the physical architecture (Figures 9.1 and 9.2), itwas sought a simple solution. The simplicity in the present case provides conveniencesfor engineering and for reliability analysis, reduces the required maintenance, facilitatesfuture modifications or extensions and, possibly, results in low cost (equipment and im-plementation).

Due to the large amount of communication network devices and due to their impor-tance for the system, the use of applications for network monitoring and management isrecommended. For example, the Simple Network Management Protocol (SNMP) [173]may be applied.

All the automation and interlocking logics of the associated equipment can be held inthe IEDs (PLCs), eliminating the use of other devices (e.g., electromechanical relays). Inaddition, the solution has the intrinsic advantages of the IEDs and now with high semanticmeanings (the proposed models of this research together the IEC 61850 standard).

The intelligence near to the process equipment can be used for situations of contin-gency, increasing the reliability and reducing the risks. That strategy was not realized inthis research, but the proposed architecture allows realizing it (indeed there are appropri-ated solutions for each equipment and installation [149]).


During the maintenances, each system of the HGU can be isolated. It is an advantage,once that normally the maintenance of the main electromechanical equipment (systems)are realized by different maintenance teams.

The architecture can help to achieve the interchangeability. Whereas it is possiblethe total standardization of the data identification and of the data exchange in the logicsof automation (variables of the algorithms), also it is possible replacing an IED with adifferent one. Thus, a independently complete replacement of parts of the automationsystem can be a reality.

An integrated test system can be utilized (possibly permanently connected to theautomation system). In that case, the test system must be specified and engineeredtogether the automation system. The philosophy and scope of tests must be clear defined,in the beginning of the process.

The above cited characteristics of the proposed system facilitates the maintenanceand the upgradability, providing longer system lifetime. According to I. De Mesmaekeret al. [26], “one of the most important aspects during the life cycle time is the facility forextensions or the refurbishment of existing parts”.

The proposed distributed architecture presents other advantages. As a contrastingexample, A. P. S. Meliopoulos and A. Bose [29] present a serie of limitations and disad-vantages for the centralized systems.

Certainly, the proposed architecture also has drawbacks. But, it is believed that theyare less than the advantages.

One of the disadvantages of the proposed system is the increase of the complexity ofthe logics of automation. The distributed logics are more complex and require more care(in the design and maintenance). The concurrent programming has intrinsic problems as,for example, the deadlocks [174]. However, nowadays there are technologies and tools tohelp solving that kind of problem, as for example the Petri Nets [175].

Another problem is the deep interchange of data. Although the IEC 61850 standardalways suggest (and presents it as an advantage) the distribution of functions, throughthe free allocation of LNs in IEDs, in the HGU systems the approach is not too simple.To implementing a full free distributed automation system, the access to some variableswhich actually are internal (“internal” to the LNs) can be necessary. Thus, a review ofthe LN classes is necessary. By other way, that approach can increase the complexity ofthe data models and difficult the implementation, so that the modification may be notjustifiable.



The IEC 61850 standard is full applied in the proposed architecture, exploring all thebenefits of the standard including the process bus (under other viewpoint). All data areshared through a single communication network, including the centralized control. Thus,the “data islands” that are common in the previous systems do not exist anymore.

The proposed physical architecture for the automation system is relatively simple. Itwas based on the necessity of accessing all system components and on the ability of thecommunication network to exchange the necessary types of messages reliably and safely.On the other hand, the logical architecture is more complex. Thus, it is becoming themore important part of the project in the modern automation systems (supposing thatthe problem of communications is well solved) .

Anyway, the communication networks are now critical resources of the automationsystems due to the distribution of functions. To meet the global requirements, the systemdepends on the correct transference of messages through the communication networks.Therefore, those networks must have very high availability. In this sense, the proposedcommunication networks are over-dimensioned (have more devices than necessary - func-tionally). A fail of any switch does not degrade the communications, all devices (mainand reserve) continue connected. An analysis of costs was not realized, but it is believedthat this over-dimension is justifiable.

More detailed analyzes of the network topologies, considering diverse aspects (com-munications reliability, data flow, latencies, throughputs, etc.), can be done. As clearlystated in this chapter, there are several possible solutions for the physical communicationnetworks.

The redundant networks are independent, i.e., disconnected. They can be connectedto increase yet more the reliability. But, there are other consequences, as the loop ofmessages. A deeply analysis can be realized to conclude the best choice.

Besides the redundancy of the communication networks, some IEDs and some comput-ers (servers, HMIs, gateways, etc.) are redundant and independent (separated) to avoidcommon failure modes and, thus, to increase the reliability (and then the availability).Furthermore, the communication networks have firewalls and other security mechanisms.

The proposed architecture guarantees that on the total fail of the centralized controlstation, the HGUs continue to operate with all the resources in the local control level ofeach one (only the centralized applications and, possibly, part of the historian are lost).

The physical architecture allows the communications between all IEDs using Goosemessages. That characteristic provides high flexibility to develop logics of automationand interlocks (described in the Chapter 8 “Generating Unit Automation”). The logical


architecture allows a semantic interpretation and application of the data from any IED(the process and system data).

Any data from the process can be sent directly to the control levels (the local andcentralized station levels). Thus, the proposed architecture allows the access to a hugeamount of data of all parts (the “systems”) of the HGU. All data are available in thesame place in the same format. That situation provides a complete view of the state of(all parts of) the HGU and of the automation system in the supervisory level.

The control levels also can use those data as inputs for applications. Thus, the appli-cations can work on-line with valuable data from all equipment of the HGU. Those datacan be transformed in information to improve the real-time operation and also to be usedin the monitoring of the equipment (and of the automation system itself). The data alsocan be used off-line, for example, it is possible to realize a detailed analysis after faultevents and the data also can be used for maintenance and asset management. There areinfinity applications for the data, one time that they are available there are not limits touse them.

The proposed system is flexible. The physical architecture allows a relatively easy sub-stitution of IEDs, in theory from any manufacturer. Those substitutions can be necessaryfor maintenance or technological actualizations (retrofit). Minimum engineering effort isnecessary, once the data identification and logics of the automation system are completelystructured and standardized. Besides, it is supposed that the necessary software tools torealize the tasks are available.

In a similar way, the devices and equipment at the station levels (local and centralized)can be updated in the future without need of adjustments in the devices of the unit andprocess levels. That fact is important because the station level devices have short lifetime(than the unit and process devices). Such actualizations also, in theory, can be done withindependent choice of manufacturers.

Note that, the intrinsic advantage of the IEC 61850 standard to update the communi-cation technologies also applies in the proposed system. Besides, the performance of thenetwork can be improved through the choice and configuration of particular communica-tion devices based on the analysis of the data traffic (performance testing).

Concluding, the proposed architecture has long term stability. It allows followingthe evolution of the communication technologies, and facilitate following the evolution ofdevices and also equipment.

In case of not too large HGUs, the computerized supervision and control functionsof the local level (the local station) can be shared. More than one HGU can utilize thesame local computer and HMIs. That configuration presents some advantages, but it alsopresent disadvantages. The principal disadvantages are related to the availability and


maintenance. In the case of very small HGUs, the computerized supervision and controlof the local level can be omitted. In that case, the functions of the centralized level areenough and, thus, the architecture can be simpler (without the local stations).

Considering the possibility of supplies of independent manufactories, the proposedarchitecture provides an opportunity to use the best of each world (specific devices fromdedicated manufactories for each system, for example, CCM, bearings, brakes, intakegates, speed governor, voltage regulation, purified water etc.).

On the other hand, nowadays the greatest difficulty to implement the proposed ar-chitecture is that there are no options on the market of IEDs compliant with IEC 61850applied to automation of large HGUs and to all the auxiliary services. That situation ismainly due to the fact that the HPP part of the standard (the more suitable revision,the edition 2.0) is relatively recent. Besides, some complements and improvements in thestandard are necessary to implement a complete HPP automation system.

The architecture do not foresee infrastructure for closed-circuit television. Besidesvideo surveillance function, nowadays that is a new resource to assist the real-time op-erations. However, it is suggested that it be completely separated from the automationsystem. As suggestion, it can be integrated to an enterprise security (property security)system of the HPP (including other video cameras and sensors).

Due to the redundancy proposed for the architecture (communication networks andcomputers) the availability of the automation system functions practically depend of theIEDs. As already stated, some redundancies of IEDs can be necessary to improve theavailability of specific functions.

Finally, the feasibility of the proposed architecture can be verified through simulationsand tests in laboratories.

Chapter 10

Technical Skills and Education

“Blessed is that one who transfers what he knows and learns what he teaches.”Cora Coralina (1889-1985)

10.1 Introduction

As can be seem in the Chapter 3 “Evolution of the Automation Systems and Proposal”,the electrical automation systems evolved a lot in recent years. Thus, the education re-lating those systems should evolve as well. To be effective, the educational contents, andmaybe the educational methodology, have to change. In fact, the subjects should be con-stantly actualized to avoid gaps of knowledge due to the rapidly changing of technologies.

The evolution is not only in the automation of HPPs. According to a report of theSC B5 WG 401 of Cigre [176], “it is well recognized that the legacy skills of the existingworkforce are not sufficient to deal with the modernization trends in the electricity grids”.Thus, the concern with the education should be more broad.

As already stated, one of the main causes of the evolution is the digital technology,a fact corroborated by other authors. According to Z. Nedic and A. Nafalski [177], “thepower industry is currently going through unimaginable transformation due to new devel-opments in digital technology...”. They conclude that the Universities need to modernisethe power engineering curricula for the modern power industry.

Together the digital automation (and protection) specific devices, the modern automa-tion systems have diverse computers. Concern about the inclusion of computers in theindustrial systems of the utilities already has nearly two decades. For example, in 1998 S.

1The Working Group (WG) 40 “Education, Qualification and Continuing Professional Developmentof Engineers in Protection and Control” of the Study Committee (SC) B5 “Protection and Automation”was formed in 2010. The cited report includes a “thorough discussion of all issues related to training andeducation of protection and control engineers, and offer guidelines and recommendations” [176].

Chapter 10. Technical Skills and Education 205

Humphreys [178] has alerted that the utilities must have people to develop and maintainthe new HMIs based on computers. Nowadays some Universities are revising their powerengineering curricula to include topics related to computing [177].

Finally, other factor that changes the required skills of the nowadays graduated engi-neers are the new standards. For example, according to A. Apostolov [179], a new set ofskills from the workforce in utilities and suppliers are required in order to deal with thecomplexity of the IEC 61850 standard (introduced in the Chapter 6 “IEC 61850 Standardand Communications”).

Additionally, the preoccupation with the lack of professionals for the electrical au-tomation area is not recent. Other areas of the electrical engineering have attracted moreprofessionals. The power systems are not so attractive to young people. Thus, somemotivation to get new engineers should be created.

Basically the new electrical automation engineers need “to understand both primaryand secondary systems (the modern ones) and how they interact”2. The problem is thatsingle quote contains quite some subjects (maybe not possible to teach in a graduationprogram if included the base knowledge: calculus, physics, etc.). That involves elec-tromechanical equipments, sensors, actuators, automation, control, data acquisition, dataprocessing, data communications, computing and, of course, Electrical Engineer. If thepractical issues are also considered, it is necessary to include many standards knowledge.Note that, in addition to the knowledge resumed above, associated to the technical skills,the engineers also need non technical skills.

This chapter deals with that challenging task of graduating the future engineers towork with HPPs (and substations) automation systems. The first approach is to identifythe necessary technical skills. The technical skills3 describe the knowledge about thetechnologies and associated abilities and how they can be applied to solve problems. Afterthat, the skills are associated to educational subjects to be included in the engineeringcurricula. The focus is on the curricula organization.

Considering the curriculum, this work is limited to its contents (selection and orga-nization). Thus, teaching methods, learning experiences, evaluation strategies and so onare not included in the scope. Extracurricular activities also are not addressed.

Only skills of technical nature are addressed, although the engineers should have com-petencies of other areas as, for example, management, administration, economics, envi-ronmental and social. In fact, engineers need a mix of competencies. That fact is eachday more evident.

2The concepts “primary system” and “secondary system” are introduced in the Chapter 2 “Hydro-electric Power Plants and Hydro Generating Units” (Section 2.4).

3In the context of this report, the word “skill” includes knowledge and ability.


Just for clarify, in this report the “graduation” program is a five years post-secondaryeducation for a student pursuing a bachelor’s degree (in electrical or related engineering,i.e, an “engineer’s degree”), as the Brazilian system. Note that, that terminology isdifferent of the one used in the United States: “undergraduation”4. In addition, theterm “post-graduation” (or postgraduate program) refers to specializations, master’s ordoctoral programs after the graduation.

The focus of the discussion presented here are the new engineers, but part of thecontents (as, for example, the continued education) also applies to the existing workforce.

10.2 Aspects of the Profession

The professional electrical engineers have many aspects regarding their actuation.Some of those aspects have influence over the engineer necessary skills, thus, they areimportant in the discussion about the qualifications. In this section the more relevantaspects are identified. Some of the terms and definition created here, for better under-standing the subjects, are not common in the literature5.

10.2.1 The Engineer

According to P. J. da Silva et al. [180], “the engineer, classically, is seen as a technicalexpert in solution of specific problems limited to certain fields of interest. Nowadays, theyneed to be seen as polyvalent professionals able to contribute to the solution of a widerange of human problems...”6. Naturally, the engineer also has to identify and formulatethose problems.

W. A. Bazzo [181] presents the general skills and qualifications necessary for the en-gineers.

Traditionally, the electrical engineer graduation programs emphasize the hardware, butnow the engineers also need to think in abstraction from the hardware. The computingskills are every day more relevant. One solution is to align the electrical engineeringprograms with the computer engineering graduation programs to supply some specifickind of knowledge. That approach allows the electrical engineering students additionalcontact to computing topics.

4The system in the Russian Federation also is different.5More studies to define an appropriate nomenclature are necessary, and it can be a future work. Note

that, some references utilized in this research are in Portuguese.6Free translation.


10.2.2 Areas

The required skills (mainly knowledge) are strongly related to the area of actuation.The engineers can act in diverse areas of knowledge in the electrical utilities and associatedmanufactures (any company related to the power grid). That can be seen as specializationsof the engineers. Among them can be cited [179]: power plant specialist, automationspecialist, telecommunications specialist and information technology7 specialist 8.

10.2.3 Categories

The categories are associated to the functions developed by the engineers. The follow-ing categories can be cited:

• Research and development engineer;

• Project or design engineer;

• Integration engineer;

• Operation engineer;

• Maintenance engineer;

• Training and education engineer.

According to the category, the required skills and experience can be somehow differ-entiated [176].

In the modern automation systems there are integrations of various components ofhardware and software. Thus, the integrator engineers are too important. Many respon-sibilities have been assigned to them [6] [26] [12] [58]. Besides, with the new technology itis believed that the integration extends over the system lifetime. That is one more reasonfor the active participation of the utilities in the integration. Thus, the employees ofthe concessionaires must be prepare for that activities. Note that, the integrator is moreimportant in situations with multiple suppliers and/or manufacturers, a scenario that islikely to be more common with the expected success of the IEC 61850 standard.

7Here, information technology involves computers and computer networks.8The design engineers and the integration engineers must have a wide not too deep knowledge, as

cited below.


10.2.4 Species

Some activities regarding the automation systems require specialized services whileothers are more general activities. Therefore, two kinds of species9 of engineers are re-quired.

The specialists focus all effort in one area of specialty. Thus, the skills developmentare concentrated and they are highly skilled in a specific field. On the other hand, thegeneralists are interested in a broad spectrum of subjects, in the present case, limited bythe electrical automation systems areas. Thus, they are knowledgeable in many fields ofstudy and may not been able to realize specific activities deeply.

As discussed in the last subsection, the system integrator must be a generalist. Theengineers of the other categories can be specialists or a mix of both (a new specie...).

10.2.5 Sides

Basically, the engineers can work in three distinct sides: utility, manufacturer (orvendor) and consultant. Different of the distinct aspects introduced above, technically,those sides do not require too different skills (considering the same area, category andspecies). Other non technical skills, somehow distinct, are important for the three sides.

The differences according to the side are subtle. The point of view regarding a samesubject can change. For example, considering a technical specification, when in the utilityside the engineer should create it, when in the manufacturer (or vendor) side the engineershould understand and follow it. On the other hand, the project must be designed by theengineers in the manufacturer side and analyzed by the engineers of the utility side. Theconsultant can act under different viewpoints.

The system integrator can be an engineer of the utility, manufacturer or third part.This must be clear in the technical specification.

10.3 Curriculum Contents

Typically the first semesters of any engineering graduation consist of foundationalcourses in mathematics, physics and other sciences. Generally those contents are called“common curriculum”. Those courses are prerequisites for the other part of the curriculum(other courses can not be taken without prior completion of the prerequisites).

In this section are listed the contents for a modern curriculum of electrical engineeringwith emphasis on automation of power plants and substations. The choice of contents is

9The term “species” was utilized here only as a ludic reference to the animal species...


one of the fundamental steps in the teaching learning process.Besides the information (to know the subjects), the students should know how to use

those information in the context of the electrical automation systems. For example, theyshould be able to evaluate the impact of their solutions in a broad way.

10.3.1 Initial Considerations

There are some core subjects involved in the modern automation systems of HPPs(and substations), among them can be cited:

• Electromechanical equipment;

• Sensors, actuators, signal processing and data acquisition;

• Automation and control;

• Computing (programming and databases);

• Data communications (interfaces and networks);

• Supervisory systems.

Those areas involve many topics and also various standards. Besides the fundamen-tals of those areas, the engineers also need know the state-of-the-art (the stage of thetechnologies).

The new engineers need to have specific technical knowledge, relating the technologiesabove listed, as well as generic knowledge of engineering, basis of electrical engineering andother areas (as management, administration, economics). The last ones can be developedthrough a competencies approach. Thus, those competencies should be considered in thedevelopment of the course syllabuses.

The focus of the study presented here is the technical skills. The types of knowl-edge necessary to the engineers are organized in subsections, presented in the followingsubsections.

10.3.2 Basic

Naturally, the basic knowledge of the engineering graduation programs remains veryimportant. Thus, the following issues should be explored in depth in the graduationprograms:

• Calculus;


• Engineering Mathematics;

• Elementary Physics (including laboratories);

• General Chemistry;

• Linear Systems;

• Probability and Statistics.

One aspect that can be changed to improve some courses is to use a more appliedapproach instead of pure sciences in the teaching process. That approach also is importantto avoid the school dropout10.

Yet considering the basic knowledge, the ability to communicate effectively (writtenand verbal communication) is very important for any engineer. Thus, the curriculumshould include topics relating communication in the courses, as elaborating reports anddoing verbal presentations. In addition, dedicated courses for technical communicationas, for example, an “expository writing” course can be required.

10.3.3 Professional

Below are listed some subjects, organized by areas, necessary for the electrical engi-neers.

Reliability and Safety Engineering

In this topic is included the theory of reliability, availability, maintainability and safety.The students have to know the concepts and tolls necessary to evaluate the availability andto develop the risk assessment of the automation system. Some examples of applicationsare presented in this report, at the Chapter 9 “Automation System Architecture”.

Data Acquisition and Signal Conditioning

The data acquisition, conditioning, conversion and transmission are basic knowledgefor the modern automation systems. The new technologies as, for example, the MUs11

should be addressed.10Leaving the university without completing the graduation... or to leave the engineering program and

start another one (in other area).11Remember that, MUs stands for “Merging Units”...


Sensors and Actuators

The operation principle of the main sensors and actuators used in automation of HPPs(and substations) should be addressed. New kind of sensors, the non-conventional ones(as, for example, the optical CTs), also should be presented.

Basic Computing

In current traditional electrical engineering graduation programs the students are notlearning enough programming; and that subject is very important in modern automationsystems.

As presented in the previous chapters of this report, the modern automation systemsare based in digital devices with different kind of software. Thus, the principles of com-puting is important for the engineers, to design, implement and maintain the software ofthe automation system. It is not possible a too deep approach in an electrical engineeringgraduation program, therefore, some engineers may need complementary courses aboutthis subject.

The following topics should be included:

• Introduction to Computing;

• Basic software: operational systems, word processing, spreadsheets, and presenta-tion software12;

• Computer-aided design software;

• Programming logics (flowcharts and algorithms);

• Data structures.

Control systems

This topic envolves the classical theory of continuous and discrete time control. Themodern theory of control (the state variables approach) also can be included or can beaddressed in the specific topics.

Basics of Automation

This topic should be an introduction to automation. It should address themes as:hardware (electromechanical relays, microprocessor based relays, contactors, PLCs - orIEDs, etc.), diagrams of relays, basic logics of automation, interlockings, etc.

12Maybe nowadays those topics are not necessary anymore. But, some verification should be done.


Others Knowledge

Besides the topics above listed, normally the engineers have deep knowledge in onearea and basic knowledge in the related areas, according to the engineering branch. Thusthe electrical engineers need to have some knowledge of civil engineering (strength ofmaterials, for example) and mechanical engineering (basic mechanics, for example)13.Those topics are not listed here (they are the classical ones - in Brazil the inclusion ofthose topics in the engineering programs are regulated by laws).

10.3.4 Specifics

This subsection presents the knowledge specific for the profession (necessary for theprofessional action). The contents are scientific, technological and instrumental knowledgeaccording to each type of engineering program, in the present case: electrical engineering.

Below are listed the specific subjects, organized by areas.

Power Systems

Single phase and three phase power systems, electric machines, power generation,(basics of) power systems analysis, (basics of) power systems protection.

Note that, sobe subjects listed here have intersection with the topics of the next twosubjects in the following.

Substations

Concepts, definitions, main equipment and operation principles of substations.

Hydroelectric Power Plants

Concepts, definitions, main equipment and operation principles of HPPs14.

Communication Networks

As can bee seen in this report, the data communication networks are resources presentat all levels of the modern automation systems. Thus, now the network is a subjectfundamental for electrical automation and the new electrical engineers (acting in theautomation of power plants) need to have deeper knowledge of this subject. They must to

13The other types of engineering programs (civil, mechanical, etc.) also include introductory coursesin electrical engineering.

14In the context of thermal power plants other kinds of knowledge are necessary.


know at least the network components (hub, switch, router, firewall, etc.), the OSI layers,Ethernet, TCP, UDP, IP and VLAN’s.

Computing

According to the category of the engineer (see the Section 10.2) the needed computingskills can vary widely. On the other hand, the education in the graduation should beunified for all engineers (it is not possible to create specific curricula for each categoryof engineer. In fact, normally during the graduation the students yet do not know theircategories...). Thus, the depth of knowledge of the subject presented here should bemedian.

Note that, most engineers do not need to be a “software developer”. For example,some maintenance and operation engineers only need to have a superficial knowledge ofspecific subjects as, for example, UML and XML.

Some items related to computing are presented in the subjects below.

Modelling

As can be seen in this report, and stated in other works [176] [182], in the modernautomation system the modelling is required.

As can be seen in the chapters 5 “Description of the Generating Unit” and 7 “Modellingof the Generating Unit” the problems representations, modellings and abstraction are veryimportant to deal with the modern automation systems. Thus, those subjects should beexplored in the courses.

According to H. Dawidczak and H. Englert [66], “the creation of the data model andthe configuration of the communication system represent essential tasks of engineeringsubstation automation systems”. The same is applied to the power plants.

The XML have been used a lot for implementation of secondary systems (mainlyconfiguration) and also for integration of standards. This is an importante subject tobe explored in the electrical engineering graduation. Besides, there is an advantage: theXML can be addressed in a very didactic approach.

Databases

The project engineers need to know the theory of databases. Some products have opendatabases and other have proprietary (closed) databases. In all cases, the project engineersshould understand those products, so they need to have knowledge about databases.

The maintenance engineers need to have practical knowledge about databases, besidethe basic theory. Normally the databases are used in the maintenance of the system. In


fact, usually are simple tasks, basically modify, include and exclude specific records. Cre-ating or deleting fields or tables are not common tasks. Thus, the maintenance engineersneed to know how to execute basic tasks in some specific database management system.Besides the modifications cited here, naturally the basic and advanced searches tasks arenecessary.

The operation engineers only need to have a superficial knowledge about databases.In some power utilities, the operation area also develop software tools for post operationand also real time operation. In that case, a complete knowledge of database is necessary,but not for the real time operators/dispatchers.

Automation of Substations and Power Plants

The main concepts and solutions for automation of substations and power plantsshould be addressed.

The automation logic and algorithms involved in the development of automation sys-tems (including some programming language as, for example the ones defined at the IEC61131 standard) should be taught.

Standards

The standards are domain specific knowledge. Some considerations about standard-ization are presented in the Section 10.5. It is important to teach the students the basicideas of standardization and application of international standards.

One way to facilitate the application of standards for modelling and communications,as the IEC 61850 standard for example, is the development of user-friendly tools thatexplore the possibilities of abstraction. However, all basic concepts and knowledge (whichare not few) continue to be necessary for the users to understand what they are doing andto explore the full potential of the standards.

The software tools are very important to apply the new technologies and standardsof automation. Those tools are responsible not only for the implementation of the sys-tems, but also for design, analises, maintenance, documentation. For example, one majorconcern stated in the report of the SC B5 WG 40 [176] is relating to “the tools usedfor building and storing engineering drawings, relay settings, relay data sheets, and relaymanuals”. Various files are involved in the modern automation systems.

Thus, beside the standards the new engineers need to know how to utilize the softwaretools (and in some specific cases, also to develop them). It is not possible to select whichsoftware tools to teach, therefore, the new engineers have to be familiarized with softwaretools applied in power systems.


Others

Others topics relating to electrical engineering graduation can be included, or ex-tended, according to the institutions objetives. Among them can be cited:

• Power transmission and distribution;

• Power systems dynamics and stability;

• Power systems operation;

• Power systems protection;

• Electric power quality;

• Energy markets and planning.

Those topics can be left out of the graduation program discussed here.

10.3.5 Non-Technical

Beside the topics presented above, there are other non-technical topics essential forengineers as, for example:

• management;

• professionalism;

• ethics;

• environmental issues.

Many educator consider those topics important. For example, according to I. Rocha[183], the education needs to be expanded to develop versatile skills such as listening,negotiating, cooperation, responsibility, honesty and ethics.

10.3.6 Critical Analysis

Nowadays there are a myriad of devices in the electrical automation systems. It is notpossible to study each one in a graduation program. A key point is to understand the basicfunctions concepts. For example, if the student understand the data acquisition functionand also the communication function, the student knows exactly for what a PIU15 and a

15Process Interface Unit.


RTU16 are used for and how they work. Thus, the main characteristics, differences andapplications of those devices can be discussed.

In a similar way, to know how to configure the various IEDs for various applicationsit is necessary understanding how those devices work. However it is not necessary toknow how to use the software tools of each manufacturer of IEDs. If the engineers knowthe concepts, they can use any software tool with a little training. The specifics of thesoftware tools can be learned on the fly.

Considering all the topics suggested for an electrical engineering graduate curriculum,it turns out that there are a large number of subject to a graduation degree. Thus, toadapt the curriculum matrices to contemplate all issues in a timely fashion (usually fiveyears) is a challenge.

On graduation is tricky driving the program for the occupation area of the engineer.For example, the profundity of specific issues may be different for a project engineer,a maintenance engineer and an operating engineer. In fact, frequently the students donot even know in which of those three occupations they will act. Thus, the graduationprogram have to give the basis for the three occupations and the engineer can expand itsqualification while working (with the defined occupation). Similar situation occurs withthe other aspects (see Section 10.2).

An alternative solution to the problem mentioned in the previous paragraph wouldbe the completion of the training engineer with professional post-graduate programs (orcourses). But that can not be mandatory. The graduate degree alone should preparethe professionals for the labor market. The post-graduate courses should be viewed ascomplements (when the purpose is to work in the industry).

A better solution is the continued education in the companies. Consider that, the so-lution may involve formal courses outside the companies including post-graduate courses.Some specific activities of the companies require specialized professionals for better results.The cost of those courses must be see as investments and not as expenses.

There are many knowledge and a large number of specific areas (basically: automa-tion, control, protection, monitoring, communication networks, electric power system,electromechanical equipment) in IEC 61850 standard. It is not feasible that a profes-sional master all those areas. Thus, the work teams must be multidisciplinary and eachprofessional should has a specific depth knowledge of his/her area and a minimum knowl-edge of other areas.

For example, it is complicated for a professional understands the details of a bear-ing lubrication system (the main case study of this research) working, acquisition andprocessing of data, the various ways that a network switch handles packages to manage

16Remote Terminal Unit.


VLANs, temporal synchronization of electronic systems, redundancy protocols, softwarefor HMIs, modeling and database. Cyber security is a world apart.

Finally, the profile of the engineer describe here is more near to an “automation engi-neer” than a “power system engineer”.

10.4 Experimental Teaching

The teaching methods are not deeply addressed in this report. They can be since tradi-tional classroom lectures in blackboard until distance education using Internet. However,it is considered that the diverse methodologies are used together and the students shouldhave active participation in the process. Besides, experimental activities can improve theefficiency of the learning process and they are indispensable in any engineering graduationprogram.

Some authors have proposed innovations on control and automation engineering grad-uation programs in Brazil. For example, R. T. Pena, F. G. Jota and C. S. Filho [184]propose to reduce the total time spent in lectures and to realize multidisciplinary projects.Those projects require an active attitude by the student, especially in laboratories. Theybelieve that a more practical approach is better to learn engineering.

As cited above, the teaching methods applied in the classroom are not discussed here.On the other hand, some issues related to experimental teaching approaches are presentedbelow.

10.4.1 Laboratory Lessons

W. A. Bazzo [181] presents the general objectives of laboratory classes. He emphasizesthe process of experimentation. One of the main goals of this kind of class is to drawconclusions from experimental results. A series of skills developed in lab activities arepresented. One of them, the development of the spirit of teamwork, is a skill very necessaryfor working in the modern electrical automation systems.

Many professors agree with the importance of laboratory lectures. For example, ac-cording to N. I. Sarkar [185], the laboratory classes have positive impact on the per-formance of the students and normally the students are highly favorable to laboratoryclasses.

In the same line of thought, the contact with commercial IEDs is important. A keypoint is that the specialist engineers must know the capabilities and limitations of thenew devices and systems. Thus, for the training of experts in modern technologies it isimportant to develop practical skills with systems and equipment close to real conditions.


Yu. P. Gusev et al. [186] discuss important issues about methodology and technicalsupport for trainings of substation automation systems in laboratory. Z. Nedic and A.Nafalski also present important points about the development of a modern power systemslaboratory.

It is expect to change some classes from traditional hardware based laboratories tosimulation software based laboratories. It is easier for the institutions to create andmaintain that kind of laboratory. Besides, the possibilities to develop experiences (withoutrisks) in a virtual laboratory are greater. Hardware in the loop also can be used in thesimulations.

Finally, the simulators also are useful for partial tests of real systems and developmentof applications. Thus the new engineers could be prepared to that type of work.

According to the SC B5 WG 40 [176], “the university education for the emergingworkforce should be closely coordinated with industry”. Thus, the universities should havethe hardware and tools utilized in the industry, beside traditional educational resources.

10.4.2 Internships

The internships are unique opportunities to know the equipment and devices used inreal applications. They also allow to know the hierarchical structures and working formsof the companies.

In schools of engineering, as the ones of Germany, there are more internships hours intheir graduation program. That tradition is the result of long term cooperation betweenuniversities and industries.

Another good example of integration university and industry is the cooperation of theItaipu Binacional and the Western Parana State University - Unioeste. The graduation inElectrical Engineering (besides the graduations in Mechanical Engineering and ComputerScience) is developed in buildings in the area of the power plant and has other supportsas, for example, participation of the professionals of the Itaipu in the teaching and re-sources for the laboratories. The Itaipu also offers every year the opportunity for morethan 20 students to training in the power plant (in diverse areas, including: engineering,maintenance and operation). The results are satisfactory for all involved.

10.5 Standardization

According to A. Apostolov [179], the engineering process envolves knowledge of theproblem domain and also knowledge of the state of the art technology. For example,to apply the IEC 61850 standard, it is necessary knowledge about the process (equip-


ment and functions) and also the modeling principles of the standard and the productscharacteristics.

The high level of standardization of the automation systems in the companies, as pro-posed in this research, reduce the necessity of specific courses or training for the engineersthat work in those companies (and consequently also reduces the costs). On the otherhand, previous capacitations in the standards are necessary and can be time consuming(and money consuming). The new engineers must be familiarized with the standards.

One way to facilitate the study and to gain experience in the standards is to reducethem. However, that solution is extremely complex. Thus, a more feasible solutionis looking for an unification of the standards. Remember that the IEC 61850 standard(presented in the Chapter 6 “IEC 61850 Standard and Communications”) aims to unify thestandards for communication in power utility automation. At least if the basic conceptsand language of the standards are unified, the learning process can be easier.

Besides the knowledge of the standards, as already said, the software tools also areeach day more important. The modern automation systems require modern software toolsto design and configurations. The engineers need to know to use those tolls (and in somecases, also to develop them).

Part of the complexity of the IEC 61850 standard can be hidden by the engineeringsoftware tools. However it is very important to know the concepts and working of thestandard. The software tools allow a high level of abstraction, fact that has advantagesand disadvantages.

In spite of the abstraction, the engineers must know exactly what the software toolis doing. The tool is a way to facilitate the work, executing procedural and repetitiveactions. For example, the users do not need deeply know the whole SCL, because thesoftware tools can provide friendly interface to manipulate the files. However, the usermust have a sense of what the tolls are doing in the files.

10.6 Continued Education

As stated above, during the work carrier the engineers need to continue to study. It isassumed that statement is a consensus. For example, according to the report of the SCB5 WG 40, it is expected that if the engineers have only a graduation degree (bachelor),they will have to go through additional intensive training to acquire the needed skills towork with protection, control and automation of power systems. That idea is not new.For example, in 1996 I. Rocha [183] already stated that time education should be orientedto learning in the working life and to enable the student to practice that learning.

Naturally, the engineering graduation programs must have the appropriate content to


train professionals for the industry. There must be a balance between what the universityteaches and what the market demands. However, the graduate should be prepared for theworking day-to-day. Knowledge to realize more specific activities can be developed afterthe graduation.

To realize that specific activities, specific knowledge and skills are necessary. Thus,complementary courses may be a solution. Those complementary courses can be offeredby universities, manufacturers, third parts, experts, etc. For example, particular devicesmay require specialized trainings by the their manufacturers.

The continued education can mainly be realized through “short courses”. As indicatedabove, they are courses outside of mainstream graduate and post-graduate programs.Although, the short courses can be offered by universities. The short course can befocused on practical activities.

Another aspect of the continued education is to prevent obsolescence of knowledge.The engineers should be prepared to keep up with technological advances. Note that, thebasic sciences (that must be deeply explored in the graduation programs) have obsoles-cence much smaller than the professional subjects.

10.6.1 Corporate Education

Losing the in-house expertise in the utilities, mainly due to the retirements, is a bigproblem [176] [8] [187]. Thus, the companies must have programs to keep the knowledge,through a transference from the experienced engineers to the new ones. That strategyalso is important to understand the company internal technical occurrences and solutions.

The “knowledge management” 17 is important for continued education. The knowledgeof the existing staff is a strategic asset and it is necessary for the continued education.That knowledge must be captured and documented using texts, spreadsheets, photos,videos, etc.

The knowledge management is particularly important for education of the new engi-neers (just graduated), mainly when the experienced engineers are retired. For example,in the Itaipu Power Plant there was a great experience of knowledge management duringthe construction of the last two HGUs (identified by 9A and 18A generating units).

The corporate education is not restricted to the corporation. The utility can haveagreements with partners to offer the education. All kind of courses or programs canbe utilized in the process (as the post-graduation cited above). For example, the Itaipupower plant has developed post-graduation programas with regional universities and other

17Knowledge Management, or simply KM, is the process of capturing, archiving and using organiza-tional knowledge, for improving performance, integration, innovation, etc.


institutions, as an IEC 61850 standard specialization program. That approach allows tooffer formal educational programs of renowned institutions for the staff of the utilities.


First of all, the focus of this chapter are the new engineers (more precisely the gradu-ation program of those engineers), but some findings also are applied to the experiencedengineers that work with the modern automation systems.

This report presents briefly some important concepts and definitions belonging theelectrical automation area. Those subjects are the minimum that should be addressedin the graduation programs. Note that, some fundamental subjects (not explicitly pre-sented in this report) are necessary to introduce the cited concepts and definitions. Thenew electrical engineering programs should combine classical theoretical subjects and newtechnological subjects.

The communication networking, computing and information technology has becomeeach day more close to the electrical power engineering. For example, those subjects aremore evident in this report than the equipment of the process. Thus, the engineers needknowledge in that area. Some very specific knowledge in those areas as, for example,cyber-security, also are necessary for a few engineers.

There are graduation programs for power systems and for industrial automation sys-tems. In the case analyzed, the program should be a mix of the two and also includingspecific matters of electrical automation (not seen in usual industrial automation pro-grams). The protection systems are a case apart. Before the existence of the digitalprotection technology, additional courses for that subject were already required. Theengineers who will work in the protection area should study other subjects instead ofcontrol and automation. Concluding, to form an engineer who has knowledge of the pro-cess (generation, transmission, distribution of energy) as well as automation, computing,communications, and so on is a major challenge.

The diversity of standards, technologies and equipment has grown enormously (despitethe efforts to have a single standard for electrical automation... which in its turn havedozens of parties and reports with hundreds of sheets), which hinders to know them. Itis very difficult for an engineer to know, and principally deeply understand, that range ofdiversity of information. Thus, it is believed that the most important is that the engineerhas a strong foundation of science and technology. That basis will allow the professionalto have a global view of systems and make possible to specialize on particular topics.

By other way, the new electrical engineering graduation program can not be trans-formed in one specialization program. The graduation must give to the students the ba-


sis (general concepts) for future developments through other educational processes (postgraduation programs, short courses, etc.).

Experimental lessons and internships (stages in the labor market) continue to be es-sential to graduate engineers.

There are other challenges to establish an engineering graduation curricula. Accordingto the area, category, species and positions (defined in this chapter) of the engineer therequired skills can be somehow different. Thus, it is necessary to define a “generic”curricula.

Considering the different categories and the diverse roles of the engineers (introducedin the beginning of this chapter), it is necessary to graduate “basic” electrical engineers.It is practically impossible to have an electrical engineering graduation curriculum thatcontemplates those diversity.

There are several roles, various areas of actuation and many necessary knowledge.The solution is forming an engineer with diverse solid base (electrical engineering, powersystems, automation, computing and telecommunications) able to continue developing(alone, informally or formally). The new engineers have to have the ability to engage inlifelong learning. The graduation programs should prepare the engineers for specialization.

Those “basic” electrical engineers should know a solid base of engineering fundamentalknowledge, all the automation core concepts, and to be prepared for develop themselves.This development could be in formal courses (specialization, master’s, doctoral programs)in universities and other educational institutions and also in the company.

The modern electrical automation field is very extensive. Thus, multidisciplinarygroups (with specialists in each area) are necessary to realize the tasks. In addition,experts have to get a sense of the other areas for harmonization and working together.The new engineers have to have the ability to work on multidisciplinary teams.

To work with the modern automation systems, the engineers have to know manyconcepts and technologies. Some of them change quickly. That is the main challenge forthe new engineers and one the most difficulty aspect for the new graduation programs.

The education of engineers have to make them capable of continuously following theprogress in their occupation area. Thus, they must be able to assimilate new informationand technologies and applying them (including using specialized tools). In this way, theengineers will be able to work in the continuous changing environment of the automationof HPPs and substations.

Chapter 11

Conclusions and Recommendations

“Success is not final, failure is not fatal:it is the courage to continue that counts.”

(No attribution found.1)

11.1 Introduction

Theoretical and practical aspects of the automation systems for HPPs are discussedin this report. The implementation is based on the IEC 61850 and IEC 61131 standards.

This chapter presents the conclusions and recommendations, including suggestions forfuture works. As the scope of this research is too wide, the subjects are separated bysections for better organization.

This report presents the following achievements and results of the research:

• briefly analysis of the evolution of the automation systems for HPPs;

• creation of a conceptual model for description of automation systems (primary sys-tem structure and signals) for HGUs;

• creation of a conceptual model for modelling of automation systems (functions andinterfaces) for HGUs, compliant with the IEC 61850 standard;

• creation of a conceptual model for development of automation systems (implemen-tation of logics) for HPPs, integrating the IEC 61850 and the IEC 61131 standards;

• constructive critical analysis of the IEC 61850 standard for applications mainlyregarding HPPs, including suggestions for extensions and improvements;

1Possibly: George Tilton; Joe Paterno; John Wooden; Mike Ditka; Sam Rayburn; Winston Churchill.

Chapter 11. Conclusions and Recommendations 224

• creation of an architecture (physical and logical) of a modern automation systemfor HPPs;

• first analyses of feasibility, reliability, performance, safety and cyber security of theproposed architecture;

• realization of a case study of an automation system for a large HGU considering areal plant (the Itaipu power plant);

• creation of a list of engineers’ required technical skills to work with modern automa-tion systems and elaboration of a brief proposal of educational approach (graduationdegree).

Some aspects and conclusions related to those realizations are presented in the follow-ing section.

11.2 Conclusions

The next subsections present the main conclusions and recommendations of this re-search.

11.2.1 Description and Modelling

In this research are proposed methods for functional naming: a descriptive name(string) and a identifying name (mnemonic for reference) compliant with the IEC 61850standard. The names and references are utilized in the description and modelling of thesystems associated to the HGUs. The methods utilize conceptual information modelscreated in this research. Those models allow to define all necessary points (or signals)of automation systems for large HPPs. The names can be defined by the users and theresults are very uniform, due to the patterns established by the data models.

The methods and models were used to describe and modelling a real large HGU. Theresults are satisfactory and the particularities are described in this report. The study casehas shown that the conceptual models, for description and for modelling, are suitable tosolve the problem. Anyway, extensions and improvements can be done in the conceptualmodels. Besides, other different solutions are possible, but a pattern of solution hasadvantages. Some possibilities and their advantages and disadvantages are addressed inthis report.

The description and modelling of the case study are very extensive and require along time to be properly elaborated. Thus, the results presented in this report are a first


approach and they will be revised in the future. Amends and corrections may be necessary.Furthermore, the conceptual models also can be improved or modified, considering newrequirements and improvements.

The modelling utilizes many abbreviations to define the references (identifications). Itwas decided to create the own abbreviations in this research, instead to use the abbrevia-tions defined in other standards, because it is considered that they are very important forthe success of the modelling (although it is a simple task). A review to look for errors andto make improvements of the abbreviations is necessary. Some terms also can be changeddue to better meanings (remark: the author’s native language is the Portuguese). A mul-tilingual approach for abbreviations is possible including the necessary attributes, classesand relationships in the proposed data models.

It is proposed use a single functional name in all engineering activities during all lifecycle of the automation system. According to the examples (case study) analyzed in thisresearch, that approach is possible. It is considered that the advantages are greater thanthe disadvantages. The unification of the naming to identify the functions and productsreduces all necessities of translations. Anyway, the manufactures are free to use anyinternal product based naming.

Even if the IEC 61850 standard is not used for implementation of the automationsystem, the proposed descriptions and modellings can be used for specification and designand also to aid the implementation. Mappings for objects that will be implemented inthe PLCs (IEDs) are needed (the necessary information must be added to the proposedconceptual models). Besides, also are necessary mappings to the communication protocols.

The proposal of design do not limit how the functions are divided into LDs. Moreover,the presented PDs are considered a good solution, but in the same sense, they are onlysuggestions. Thus, there is no limits of design and diverse alternatives are possible.

Some specific IEC 61850 modelling conclusions are presented in the next subsection.


Considering the author’s experiences in other projects and activities and also the thirdparties published works, the IEC 61850 standard is a feasible and advantageous solution forautomation (and protection) of substations, but the situation regarding HPPs is different.Some issues and suggestions of improvement developed in this research are presentedbelow.

To obtain automation systems for HPPs fully adherent to the IEC 61850 standard(with correct LNs) some LN classes should be modified (extended) and others shouldbe created. The IEC 61850 standard does not have all the necessary LN classes (and


DOs) to model a large HGU automation (without using the LN class “Generic ProcessI/O - GGIO”). However, it is necessary to assess the data models that must be in thestandard. If all required LN (or DO) for any equipment of any installation is included inthe standard, it can get very large, creating other problems.

It is suggested to modify the specification of 11 LN classes. Considerations aboutthose modifications are presented in the Appendix C “IEC 61850 Issues”, at Section C.4.

It is suggested to to create (specify) 14 LN classes. Considerations about those newLN classes are presented in the Appendix C “IEC 61850 Issues”, at Section C.5.

Besides the alterations above, it is recommended a complete revision of the parts ofthe IEC 61850 standard relating to the data models (not only in the scope of HPPs) toachieve uniformity. Before the revision should be defined directives of standardization sothat the data models follow an unified pattern.

Another noticeable example is the utilization of abbreviations in the standard (thereare many small problems). It is suggested to review (and to think about re-defining) theabbreviations used in the IEC 61850 standard.

The IEC 61850 standard has been growing enormously, for several hands of differentworking groups and, therefore, it is necessary to take a break to think about its organi-zation and, naturally, in the standardization.

Those problems difficult the implementation and would be solved, but they are notimperative problems. The main problem of the IEC 61850 standard regarding HPPs isconsidered here conceptual: a lack of a hierarchical structure dedicated for HPPs.

The IEC 61850 standard was conceived for substations (in the light of protection) andthen the scope was extended to HPPs (including the automation). However, it seems likethe standard was not enough adapted to deal with HPPs. It can be seen in various partsof the standard, were the subjects are approached specifically for substations, practicallyignoring the existence of particularities for HPPs. The part IEC 61850-6 of the standardis an example. Just creating a new part of the standard (the part IEC 61850-7-410)specifying the LN classes for the HPPs scope is not a complete solution.

Using the actual edition of the IEC 61850 standard is not possible to create an au-tomation system for a large (complex) HGU with complete semantic meaning (includingthe primary and the secondary systems). Solutions with incomplete semantic or solutionswith structure restrictions are feasible.

An automation system (supervision and control) of a large HGU is more complexthan the automation of a substation bay (considering the diversity of equipment involvedand their respective signals). Of course, there are very complex protection algorithms forsubstations, but they are virtually contained in a box getting a few signals (from a setof not too diverse types of equipment). Thus, the automation problems are different and


require distinct solutions.This report presents a solution for semantic modelling of HPPs, which requires some

small modifications in the naming specified in the IEC 61850 standard. That solutionrequires to increase the length of characters of the LN prefix (of the LN name). That isthe greater impact in the implementation. Considerations about that change are presentedin the Section 7.3.

Besides the semantic, the hierarchical structure and the levels of control in HPPsare different from substations. Strictly, the IEC 61850 standard does not consider thosedifferences, it specifies a structure based on substations. Thus, it is recommended tothink about those differences and support them in the next editions of the standard (thesolution should include other kinds of power plants).

This report presents a possible solution. It is proposed to specify (to create) a HPPstructure: a “PowerPlant section” (similar to the existing “Substation section”). Thatnew concept aims to improve the organization and relationships (or interactions) of thebasic entities of the standard (PDs, LDs, LNs). Considerations about the proposed newmodel are presented in the Section 7.2.

The definition of some LDs is proposed in the report, as case study. They could beused as reference, not as a standard. As explained in this report, to standardize the LDshas disadvantages. The free definition of LDs is a flexibility for implementation offeredby the IEC 61850 standard.

By the other side, it was concluded that the protocols of the IEC 61850 are enough forthe implementation of the automation system for HPPs. Thus, it can be considered that atcommunication level (communication services) the IEC 61850 standard is an appropriatesolution for any HPP. Besides, as it was admitted that all the IEDs necessary in theautomation system are IEC 61850 compliant devices (note that is a theoretical hypothesis),other protocols are not necessary in a green field project2. For integration with off-sitecontrol centers it is suggested the IEC 61970 standard, due to its current applications andthe works of harmonization with the IEC 61850 standard.

The Appendix C “IEC 61850 Issues” presents a series of additional issues related tothe IEC 61850 standard. For example, it is suggested to re-define and to organize thegroups of LN classes, considerations are presented in the Section C.8. Also it is suggestedto clarify some items of the standard, listed in the Section C.2.

The IEC 61850 standard has grown substantially (new parts and technical reports),thus a review of the structure of the standard considering the new scenario would be good.The organization of the standard (contents of each part) also could be improved. Sometexts could be grouped and other could be eliminated (or they could be moved to the

2Completely new project disregarding legacy devices.


technical reports). The organization facilitates the understanding.A more drastic suggestion of changes in the IEC 61850 standard are presented in the

Sections C.3 and C.8 of the Appendix C “IEC 61850 Issues”. They basically consists in anew guideline for definition of the data (the DOs of the standard) that should be presentin each LN class. As that suggestion has a great impact in the standard, it is cited hereonly as a theme for discussion.

The criticisms about the IEC 61850 standard presented in this report have only onepurpose: to be constructive. The innovations and modifications proposed for the standardare only suggestions. Besides, it should be clear that they are a personal opinion. Nat-urally, to be considered in the standard they need to be analyzed and revised by groupsof experts, in some cases of diverse areas. Some of the proposals can have no value andbe discarded, but it is hoped that some of them help to improve the standard, especiallyfor HPP applications. Anyway, some points of the critiques can serve to start a broaderdiscussion about the application of the IEC 61850 standard in automation of HPPs.

The IEC 61850 standard was created for communications, but often it is cited in thesense of automation functions and systems implementations. Frequently “algorithms in-side the LNs”3 are mentioned . In addition, the IEC 61850 standard does not clearlyaddresses the logics “outside the LNs”. Therefore, sometimes the interface (scope of thestandard) is confused with the implementation (which looks to be out of the scope of theIEC 61850 standard, because its functional description is at interfaces level). That ap-proach can become a natural tendency (to apply the IEC 61850 standard in the externalimplementation - together other standards), as is the case of this research. Thus, discus-sions about that issue (maybe a new working group could be created) can be realized orat least some clarification is suggested.

The existente of a generic hardware of IED (like a PLC) that can have any LN of thepart IEC 61850-7-410 would be a good solution for HPPs. Thus, the same IED (hardware)could be applied in the different systems of the HGU. The case study presented in thisreport can be utilized as reference for the necessary LN classes in such IED.

A tendency in the modernization of the conventional installations is to apply the IEC61850 standard. Thus, when possibly the primary equipment were substituted for modernones the integration of them is natural, since the automation system is already preparedfor the new technology. Moreover, applying the proposed approach it is expected totake advantage of current technologies of automation and data communication, providingbenefits for the operation and maintenance of the HPP.

Lastly, the modern automation systems also require modern software tools. Those3Note that, from the software point of view, the LNs can be interpreted as “layers” instead of “boxes”

(although normally they are graphically represented by boxes).


tools are used to specification, design, configurations, simulations, tests, etc. The bibliog-raphy review shown that there is a lack of software tools dedicated to IEC 61850 systems.Besides, it is considered that the tools are very important resource for the success of theIEC 61850 standard. Thus, more attention to the software tools is necessary.

Only as a final remark to emphasize, the IEC 61850 standard should consider thedifferences between HPPs and electrical substations.

11.2.3 Automation

The more feasible way to implement the logics of automation is applying the IEC61131 standard (and the IEC 61499 standard). The IEC 61131 standard is a establishedeffective standard for that purpose. As discussed in this report, the IEC 61499 standardis a better choice for large distributed systems; however it is a less common and morecomplex solution. Anyway it must be considered and can be a better solution for complexdistributed systems.

The report presents a new approach to design and implement the logics of automation,applying the IEC 61131 standard together the IEC 61850 standard. The conceptual modelcreated looks to be adequate to support any logic of automation present in typical largeHGUs (admitting that the IEC 61850 has the adequate data models). The proposedapproach facilitate the engineering processes, because it uses the same references (andnames) defined for interface (utilizing the IEC 61850 standard). However, more proofs ofconcept and analyzes are necessary to a final conclusion.

More analyzes regarding the LN classes specified in the IEC 61850 standard for thesecondary system (automation functions) also are necessary. That is a complex themeand the effectiveness was not completely verified in this research (due to deadlines4).Besides, the diversity of solutions is a challenge to define the LN classes for the automationfunctions. Studies and simulations of real cases (and practical applications) are suitableways to verify and to test the data models specified in the standard and then indicatewhat is missing and what can be improved.

Finally, in the literature, the terms “automation” and “control” have several mean-ings, sometimes they are interchangeable. Would be good a rigorous definition of thoseterms to avoid misunderstanding (in addition to the terms: protection, supervision andmonitoring).

4The author intends to continue this research.


11.2.4 System Architecture

The proposed architecture can be seen as an alternative to the widely used architec-ture of one single controller with multiple input/output remote units for the whole HGUautomation system. In the proposal, the automation data is propagated to the IEDs,mainly through Goose messaging. That approach allows implementing localized automa-tion logics (regarding the specific systems of the HGU), which can simplify the automationin the panel boards of the equipment and has other benefits, some of them presented inthis report.

The proposed architecture utilizes more IEDs than a traditional solution (a centralizedone). It is due to the very distributed approach. On the other hand, the necessary IEDscan be simpler than the main IED (head of cell) of the old solutions (the system functionsare distributed, and then the processing and memory capacities can be lower). A specificIED may concentrate the coordination of the main automatisms of the HGU (host theLNs associated to the turbine-generator set and the sequencers). Other configurations arefeasible.

Considering the amount of required LDs and data sets, in general the current com-mercial IEDs (for substations) does not support the necessary amount of message. Touse those IEDs, the proposed messages should be grouped in larger messages, which losesthe sense of the modelling work presented in this report and it is not efficient from thecommunication point of view (transmitting unnecessary data). Thus, for implementationof the proposed distributed architecture the communications capacities of the IEDs shouldbe greater.

The solution for the communication system presented in this report works, but it wasobtained in a simplistic way. More studies and better solutions for the communicationsystems may be developed. The basic requirements are that all IEDs of one HGU mustbe able to reach each other in a reliable and efficient way and also the existence of areliable and security communication link with the centralized control level. That subjectis a suggestion for future works.

One reason to do not worry too much about the communications implementations isthe fact that the current technology can easily meet the IEC 61850 standard requirements,using appropriate commercial network devices. In addition, several works have shown thatall types of messages defined in the IEC 61850 standard can be implemented and that theperformance is not a problem.

One important point discussed in the report is the application of redundancy to avoidcommon mode of failures and to improve the reliability of the system. That subject isdiscussed and an example of analysis using the fault tree method is presented in the


Section 9.2.The cyber security of automation systems is a new challenging. It is required extensive

communication networks technical skills to find the more adequate solution. The existingexperience and solutions of the information technology area can be applied in the modernautomation systems. The problem is the impact that some of those solutions can causein real-time critical systems, mainly regarding the performance. Besides, the devices ofthe automation system must be adequate to implement the solutions. The good news isthat currently the concern with the cyber security of electrical automation systems havegrown and, thus, the solutions are emerging.

The report presents, in the Section 9.11, a solution for analysis and design of the cybersecurity of the proposed architecture using the approach of zones and conduits of the IEC62443 standard. It is believed that the result is a system with proper security, consideringthe established requisites.

It is possible that some requirements or solutions of the protection system (that are outof the scope of this research) can result in minor modifications of the proposed architectureof automation. The total integration with the protection system is recommended and thattheme is indicated for future works.

11.2.5 Education

The modern electrical automation systems, with new technologies, create a need ofknowledge and technical skills not required before. The problem is that most of theantique knowledge and skills are yet necessary. Thus, the new engineers should study andlearn more than before. Another challenge is to determine how depth each subject shouldbe studied.

Possible solutions are new approaches of the graduation programs and also additionaland/or continued education. The new courses demand from the universities human re-sources, new curricula, laboratories and maybe new teaching-learning approaches. Infact, some institutions are already thinking about that new context and are adaptingthemselves.

Nowadays, there are a lot of international standards applied directly or indirectlyto the automation of HPPs (and substations). It is too difficult for a design engineerto know in deep all those standards, which normally are large documents. Thus, thestandardization, supposed applied to facilitate, may be a trouble. The difficulties arereflected in the graduation of the engineers.

As illustration, the IEC 61850 standard helps to improve various aspects of the elec-trical automation systems. However, on the other hand, it is required a large effort of the


engineers (in the diverse sides: utility, manufacturer, consultant) to know and to under-stand the standard for effective applications. Thus, additional capacitation is necessaryfor the professionals (after the graduation). That is an area to be explored.

Finally, a more feasible approach to work with the modern electrical automation sys-tems is the work in team, with engineers specialized in some specific subjects. Anyway,those experts have to be graduated by modern engineering courses and need continuededucation due to the diversity of standards and fast evolution of the technologies asso-ciated to the systems. Naturally the experienced engineers (graduated many years ago)can update themselves. Besides the experts, some engineers should have a global visionto coordinate systems integrations.

The standards, and naturally the new technologies, are the main reasons of the neces-sity of continued education during the engineers work carrier life.

11.2.6 General

It is not the intention of this research to present a final solution for automation ofHPPs. The intention is to discuss about the subjects involved in the modern automationsystems and present suggestions of solutions and identify some subjects that require moreattention. As can be seen in this report, sometimes it is presented a proposed (recom-mended) solution and also alternatives solutions. Besides, each particular solution shouldbe detailed and also deeply analyzed to possible improvements. The proposed architec-ture is the main global result which can be utilized to develop the specific solutions fordifferent scenarios.

Many subjects are addressed not too deeply, sometimes superficially, in this report.The idea is only to involve in this research all the aspects of a modern automation sys-tem. Thus, those subjects should yet be more studied for improvements and for realimplementations.

The present practice for automation of HPPs is not close to the vision presented inthis report; however with the existing technology the implementation of the proposedarchitecture is totally feasible.

To implement a distributed automation system as the proposed here, it is desirablethe interoperability of diverse software tools. The different tools involved in the pro-cess (system specification, system configuration and IED configuration tools, besides theautomation implementation tools) should be able to work in an integrated manner.

The total standardization of the description, modelling and automation allows thereutilization in HPPs containing more than one similar HGU (and also in different HPPsof the same utility or same supplier). Once that a typical design is realized, implemented


and debugged, it can be copied and adapted to diverse HGUs. Minor adjusts may benecessary. That reduces the engineering efforts and costs. If the vendor independencybecomes true, the advantages of the proposed methodology are yet greater.

It should be clear that, for the realization of the proposed architecture, the develop-ment of new devices as well as new applications and software tools are needed. Fortu-nately, all of them are feasible with the current technology. It is hoped that those potentialdevelopments will be done by manufacturers, utilities and other actors.

The proposed architecture increases the data availability of the primary and secondarysystems. That results in a high visibility of the HGU state for operation and maintenance,improving the decision-making. Besides, diverse applications for real-time operation, post-operation, maintenance and enterprise activities can be developed to use the huge amountof available data. The high visibility opens many opportunities to develop new applica-tions and obtain more availability, efficiency and safety in the generation of electric energy.

The proposed architecture has high reliability. As cited in various parts of this report,some elements of the architecture can be redundant to the system keep working in caseof single failures. Another important characteristic of the architecture is the completeindependency of the automation system of each HGU (within a HPP). Although thecentralized control is common for all HGUs of the installation, the local control of eachHGU is autonomous; therefore, there are no common points of failure within the HGUs.That characteristic also is important for maintenances actions, the intervention in oneHGU does not affect the others.

The reference architecture, conceptual models and engineering processes and methodspresented in this report may be useful for the utilities, manufacturers, vendors and thirdparts. Besides, the education issues presented in this report may be useful for those com-panies and mainly to the electrical engineering faculties direct their courses and trainings.

11.3 Future Works

This section presents the suggestions of future works based on this research. Thesuggestions are mainly regarding modelling, reliability, performance, real cases, simulationand implementations. Most of the suggestions are concern the data traffic and some ofthem are interrelated.

Each specific topic of this report can be a theme for deeply studies, in post graduationprograms. Some of then are already studied but others require more deeply studies thanthe presented in this report.

It is suggested specific analyses and improvements of the description, modelling andlogics of automation of each system, as cited at the end of the Chapters 5 “Description


of the Generating Unit”, 7 “Modelling of the Generating Unit” and 8 “Generating UnitAutomation”, considering real systems.

Creating a method for the analyzes of the data traffic, based on the conceptual models,is a good work. Some new classes and relationships can be included in the models forthat purpose. Besides the analyzes, studies of the impact that changes in the physicalarchitecture causes in the data flow can be realized. That is an important aspect to obtainbetter performance and reliability.

In this research, the data sets and control blocks were defined in a simply way. Acreation of a more elaborated methodology to define the data sets and control blocks,considering the conceptual data models (or similar) specified in this report is a veryuseful future work. That work can be integrated with the data flow analysis cited in thelast paragraph.

Diverse studies about the performance of the automation system can be realized.As the example cited above, studies of the the impact of small changes in the physicalarchitecture over the performance of the communications can be done.

In a similar way, diverse studies of reliability can be realized. For example, the impactof particular redundancies in the whole reliability of the automation system. Anotherinteresting work is to analyze how the distribution of functions can be made in a waythat the need for data from other devices (different points of data acquisition) is reduced.Thus, the dependencies of the communication networks can be minimized. A similar workis the study of the impact of the redundancy of data acquisition in the reliability (thestudy can indicate the points - sensors - that should be redundant).

Other aspects of the IEC 61131 standard can be explored as, for example, the Se-quential function chart (SFC). The application of the IEC 61499 standard also can beconsidered for future works and the results can be valuable for the business.

In this research some tools necessary to develop modern automation systems wereidentified. They can be developed as future work.

The application of data mining and business inteligency can be integrated in thepresented system (using the proposed models - modifying them). That is a very actualtheme for future works.

The present research do not addressed costs. Detailed cost-benefits analyzes of themethods and solutions proposed in this report can be realized. It is considered that theyare difficult analyzes, but they can be made in a not too deep and rigorous way.

Before adopting the proposed new architecture in a real HPP a proof of conceptthrough implementation in laboratory should be done. The system can be in a smallerscale, but exhaustive simulations and analysis should be performed. That allows to verifyif the architecture is really feasible and also to find any subject that was forgotten in this


research and should be clarified. That is a relevant (and time consuming) future work. Acomplete simulation is useful for most of the analyzes cited above.

The integration of the architecture developed in this research with the protection sys-tem also is indicated as future work. It is believed that the same physical network canbe used and there is no necessity of additional networks relating the HGU. Specific com-munication links should be necessary to connect MUs (of CTs and VTs) to the protectiondevices. The utilization of MUs is a subject that can be studied.

Besides the suggestion of future works explicitly presented in this section, in this reportthere are many specific questions that can be explored in future works. Above all, severalissues were addressed but not explored in the report, which also can be themes for futureworks.

A future work related to this work is a research about new technologies of the processequipment for HPPs. After a selection of new process equipment to be applied in a HPP,analyzes about the impacts of those new equipment in the automation system can berealized, including the effect in the data models of the IEC 61850 standard.

In the education part, a future work can be to include the competencies of other areas,as social, communications and interactions. The peripheral subjects not addressed in thereport as, for example, environmental and economic issues also can be included. Thepresented course can be detailed by experienced professionals and professors.

As can be seen in the proposal of future works above, it looks like at the end of theresearch there are more questions than answers. This is normal when new engineeringtechnologies are being studied. The engineering always look forward, aiming reach the fu-ture. Anyway, at least the research have lighted relevant points of the modern automationsystems of HPPs to be explored.

Appendix A

Abbreviations

A.1 Introduction

The purpose of the abbreviations used in this research is to save space (in the refer-ences). The abbreviations were defined following a pattern created here. It is assumedthat using that approach the result are abbreviations with unquestionably meanings andclear to the readers of this report. It is supposed that the readers work in the area, thusthe terms are familiar.

There are two patterns for the abbreviations, one “short” and another “long”. Thereport presents the short ones.

The abbreviations presented in this appendix are not related to the IEC 61850 stan-dard; in fact, they are very different.

A.2 Abbreviations Utilized

The Table A.1 list all (not IEC 61850 standard related) abbreviations. They are thestrings1) utilized in this report to create the references and, thus, to identify the objects.

Table A.1: Abbreviations utilized in this report.

Term Abbreviation125 Volts Direct Current 125Vdc13.8 kilo Volts - 460 Volts 13.8kV-460V18 kilo Volts - 460 Volts 18kV-460V

Continue on next page...

1String is a linear sequence of characters.

Appendix A. Abbreviations 237

Table A.1 – Continued from previous pageTerm Abbreviation

220 Volts Alternating Current 220Vac24 Volts Direct Current 24Vdc460 Volts Alternating Current 460Vac48 Volts Direct Current 48VdcAir AirAir Pipe APipeAir Valve AValveAlkali AlkAlternating Current AltCurAlternating Current Power Supply ACPowSupAutomation AutAuxiliary Power Supply APowSupAuxiliary Transformer ATraAuxiliary Transformer Cooling ATCoolBatery BatBearing Pad BPadBrake BrakeBrake Monkey BMonBusbar BusbarBush BushBypass Valve BValveCarbon Dioxide CarbDioxCircuit CircCircuit Breaker CircBreakCollector Ring CRingControl ContControl Power Supply CPowSupCooling CoolCuno-Flo CunofloCylinder CylData Fault Recorder DataFaultRecDirect Current DirCurDirect Current Power Supply DCPowSupDisconnector Discon




Distribution DistrEarthing Switch ESwElectronic Governor EGovEmergency Power Supply EPowSupEmergency Transformer ETraEven Brake EBrakeExcitation ExcitExpansion ExpanExpansion Tank ETankFan FanFeed FeedFilter FilterGas GasGate GateGenerating Unit GenUnitGenerating Unit Automation GUAutGenerating Unit Bay GUBayGenerating Unit Cooling GUCoolGenerating Unit Protection GUProtGenerating Unit Synchronization GUSyncGenerator GenGenerator Fire GFireGenerator Power Supply GPowSupGenerator Transformer GTraGuide GuiGuide Bearing GBearHeat Exchanger HeatExchHigh HighHuman Machine Interface HMInterHydraulic Governor HGovInput InIntake Gate IGateIons Exchanger IExchLow Low




Lower Bearing LBearLubrication LubMagnetic MagMain MainMain Transformer MTraMain Transformer Cooling MTCoolMain Transformer Phase A MTraPhAMain Transformer Phase B MTraPhBMain Transformer Phase C MTraPhCMechanical MecMiddle Bearing MBearMotor MotMotor Control Center MotContCenMotor Control Center Unit MCCUnitMotor Power Supply MPowSupNitrogen NitrNormal NormOdd Brake OBrakeOil OilOil Pipe OPipeOil Pump OPumpOil Tank OTankOutput OutPanel Board Interface PBInterPanel Board Power Supply PBPowSupPhase A PhAPhase B PhBPhase C PhCPipe PipePower Plant Automation PPAutPower Transformer PTraPrimary PrimPump PumpPump One Pump1




Pump Two Pump2Purified Water PWaterRaw Water RWaterRectifier RectReposition ReposReposition Tank RTankReserve ResRotor RotSecondary SeconServomotor ServomShaft ShaftSolenoid SolenStator StatorSubstation Automation SAutSupplementary SupplemTank TankThrust ThrThrust Bearing TBearTransformer TraTransformer Fire TFireTurbine TurUninterruptible Power Supply UPowSupUpper Bearing UBearValve ValveVoltage Regulator VRegWater WaterWater Pipe WPipeWater Tank WTankWater Treatment WTreat

Note that, some abbreviations do not have difference from the terms (so, in fact, theyare not abbreviations, but strings utilized in the references).


A.3 Concluding Remarks

The abbreviations listed above need to be reviewed. A detail to consider is the fact thatthe native language of the author is not the English. Naturally, equivalent abbreviationscan be created in other languages for applications in countries that do not speak English,as in Portuguese for Brazil. After that, the translation can be automatic.

It is possible to use abbreviations shorter than the presented above (for example,they can be created using only the initial letters, as acronyms), but would be difficult tounderstand the references created using them.

Finally, also it is possible to utilize “long” abbreviations (spending more memoryspace), not presented in this report.

Appendix B

Case Study of Other Systems

B.1 Introduction

As introduced in the Chapter 4 “Case Study”, during the development of the researchwere realized cases studies as proofs of the concepts. The results about the “MiddleBearings (MBear)” system are presented in the specific chapters of this report. Thisappendix presents some results about other systems for exemplification. There are stillsystems of the HGU not presented here.

For simplicity, the names and references presented in this appendix are not complete(they do not include the identifications of the HPP, HGU and system). Note that, thedata are organized by system.

In the cases of too much similar instances of a equipment or device, only some samplesare shown, for simplicity.

The tables of equipment and devices presents the physical data, thus there are onlysingle points. In the cases of double points (considering the CDCs), there are the twostates in the names of the points listed in the tables of references and names.

For each LN of the group “S - Supervision and Monitoring”, it is considered that existone associated LN of the group “T - Instrument Transformer and Sensors” (they are notpresented in this appendix, for simplification reasons).

The names and identifications of the HPP, HGU and systems are not included in thenames and references (for simplicity).

The LN classes LPHD and LLN0 are not presented in the tables.

Appendix B. Case Study of Other Systems 243

B.2 Braking - Brake

The “Braking (Brake)” system of the HGUs of the Itaipu power plant is, in fact, abraking and lifting system.

Thereafter are presented the results regarding the “Braking (Brake)” system.

Equipment and Devices

The equipment and devices of the “Braking (Brake)” system are shown in the Table B.1(on page 243).

Table B.1: Equipment and devices of the “Braking (Brake)” system.

Equipment Devices125Vdc Circuit 1 DC Mini CB125Vdc Circuit 2 DC Mini CB24Vdc Circuit Under Voltage Relay

Air Pipe 1

Pressure Sensor (switch) 1 (Low)Pressure Sensor (switch) 3 (Low)Solenoid ValveThree Way Valve

Air Pipe 2

Pressure Sensor (switch) 2 (Low)Pressure Sensor (switch) 4 (Low)Solenoid ValveThree Way Valve

Brake Lift Monkey 01 Limit Switch 1 (Applied)Limit Switch 2 (Disengaged)




... ...



Panel Interface

Button 1 (Lifting)Lamp 1 (Failure)Lamp 2 (Braking)Lamp 3 (Lifting)


Logical Nodes

The Table B.2 (on page 244) presents the LN classes necessary to model the “Braking(Brake)” system. The table also shows the quantity of instances of each LN class.

Table B.2: Logical node classes of the “Braking (Brake)” system.


KBLM 32KSVV 2KTWV 2PTUV 1SPRS 4XMCB 2

Subsystems or Logical Devices

The subsystems or LDs defined for the “Braking (Brake)” system are listed in theTable B.3 (on page 244).

Table B.3: Subsystems of the “Braking (Brake)” system.

Subsystem AbbreviationControl Power Supply CPowSupEven Break EBrakeHuman Machine Interface HMInterOdd Break OBrake

References and Names

The DO references and the names of the points created for the “Braking (Brake)” sys-tem are listed in the Table B.4 (on page 245), sorted by LD.

Schematic Diagram

The Figure B.1 (on page 246) shows a simplified diagrama of the “Braking(Brake)” system (with the references listed in the Table B.4).


Table B.4: References and Names of the “Braking (Brake)” system.

Data object reference Point nameCPowSup/125VdcCirc1 XMCB.Op 125Vdc Circuit 1 DC Mini CB OperatedCPowSup/125VdcCirc2 XMCB.Op 125Vdc Circuit 2 DC Mini CB OperatedCPowSup/24VdcCirc PTUV.Op 24Vdc Circuit Under Voltage Relay OperatedEBrake/APipe2 KSVV.Op Air Pipe 2 Solenoid Valve OpenEBrake/APipe2 KTWV.PosA Air Pipe 2 Three Way Valve BrakingEBrake/APipe2 KTWV.PosB Air Pipe 2 Three Way Valve LiftingEBrake/APipe2 SPRS2.LoAlm1 Air Pipe 2 Pressure 2 LowEBrake/APipe2 SPRS4.LoAlm1 Air Pipe 2 Pressure 4 LowEBrake/BMon02 KBLM.Pos Brake Lift Monkey 02 Applied DisengagedEBrake/BMon04 KBLM.Pos Brake Lift Monkey 04 Applied Disengaged

... ...EBrake/BMon32 KBLM.Pos Brake Lift Monkey 32 Applied / DisengagedHMInter/PBInter ICPB.But1 Panel Interface Button LiftingHMInter/PBInter ICPB.Lamp1 Panel Interface Lamp FailureHMInter/PBInter ICPB.Lamp2 Panel Interface Lamp BrakingHMInter/PBInter ICPB.Lamp3 Panel Interface Lamp LiftingOBrake/APipe1 KSVV.Op Air Pipe 1 Solenoid Valve OpenOBrake/APipe1 KTWV.PosA Air Pipe 1 Three Way Valve BrakingOBrake/APipe1 KTWV.PosB Air Pipe 1 Three Way Valve LiftingOBrake/APipe1 SPRS1.LoAlm1 Air Pipe 1 Pressure 1 LowOBrake/APipe1 SPRS3.LoAlm1 Air Pipe 1 Pressure 3 LowOBrake/BMon01 KBLM.Pos Brake Lift Monkey 01 Applied / DisengagedOBrake/BMon03 KBLM.Pos Brake Lift Monkey 03 Applied / Disengaged

... ...OBrake/BMon31 KBLM.Pos Brake Lift Monkey 31 Applied / Disengaged


Figure B.1: Schematic diagram of the “Braking (Brake)” system.


B.3 Hydraulic Governor - HGov

The “Hydraulic Governor (HGov)” system is the hydraulic turbine governing system.It has high pressure oil pumps, pressure air and oil tanks, air compressors, sump tanksand piping to provide the pressure supply. The servomotors (hydraulic actuators) areincluded.

Thereafter are presented the results regarding the “Hydraulic Governor (HGov)” system.


The equipment and devices of the “Hydraulic Governor (HGov)” system are shown inthe Table B.5 (on page 247).

Table B.5: Equipment and devices of the “HydraulicGovernor (HGov)” system.

Equipment Devices120Vac Circuit 1 AC Mini CB120Vac Circuit 2 AC Mini CB125Vdc Circuit AComp DC Mini C. Breaker125Vdc Circuit Pump DC Mini C. Breaker

460Vac Circuit 1AC Mini CBMini Disconnector

460Vac Circuit 2AC Mini CBMini Disconnector

Air Compressor 1ContactorLevel Sensor (switch) OilTemperature Sensor (switch)

Air Compressor 2ContactorLevel Sensor (switch) OilTemperature Sensor (switch)

Air Pipe Control ValveAir Tank Pressure Sensor (switch)Closing Servomotor Solenoid ValveMain Pipe Pressure Sensor (switch)Oil Filter Auxiliary Contact



Table B.5 – Continued from previous pageEquipment Devices

Air-Oil Tank

Control ValveLevel Sensor (switch) 1 (High)Level Sensor (switch) 2 (Too High)Level Sensor (switch) 3 (Normal)Level Sensor (switch) 4 (Low)Level Sensor (switch) 5 (Low)Level Sensor (switch) 5 (Too Low)Pressure Sensor (switch) 1 (High)Pressure Sensor (switch) 1 (Normal)Pressure Sensor (switch) 2 (Low)Pressure Sensor (switch) 2 (Too Low)Pressure Sensor (transmitter) 3

Oil Pipe

Control ValvePressure Sensor (switch)Solenoid Valve 1Solenoid Valve 1 (Closed)Solenoid Valve 1 (Opened)Solenoid Valve 1 (Test)Solenoid Valve 2Solenoid Valve 2 (Closed)Solenoid Valve 2 (Opened)Solenoid Valve 2 (Test)

Oil Pump 1

AC Mini CBAuxiliary ContactContactorMini Disconnector

Oil Pump 2

AC Mini CBAuxiliary ContactContactorMini Disconnector

Oil Pump 3

AC Mini CBAuxiliary ContactContactor




Mini Disconnector

Oil Pump AContactor RelayThermal Overload Relay

Oil Pump BContactor RelayThermal Overload Relay

Oil Tank

Level Sensor (switch)Level Sensor (switch) 1 (Too Low)Level Sensor (switch) 2 (Too High)Temperature Sensor (switch)

Panel Interface ACompSelector Switch 3 (Automatic)Selector Switch 5 (One)

Panel Interface Pump

Button 1 (Pressed)Button 2 (Pressed)Button 3 (Pressed)Selector Switch

Water Pipe Flow Sensor (switch)

Logical Nodes

The Table B.6 (on page 250) presents the LN classes necessary to model the “HydraulicGovernor (HGov)” system. The table also shows the quantity of instances of each LN class.


The subsystems or LDs defined for the “Hydraulic Governor (HGov)” system are listedin the Table B.7 (on page 250).


The DO references and the names of the points created for the “Hydraulic Governor(HGov)” system are listed in the Table B.8 (on page 251), sorted by LD.


Table B.6: Logical node classes of the “Hydraulic Governor (HGov)” system.


KACO 2KPMP 8KSVV 5KVLV 3PTTR 2SFLW 1SLEV 9SPRS 6STMP 3XMCB 11XSWI 5

Table B.7: Subsystems of the “Hydraulic Governor (HGov)” system.

Subsystem AbbreviationAir Compressors AComprAir-Oil Tank AOTankAutomation AutoHuman Machine Interface HMInterOil Reservoir OReserOil Tank OTankPumps PumpServomotors ServoSolenoid Valves SValve

Schematic Diagram

The Figure B.2 (on page 254) shows a simplified diagrama of the “Hydraulic Governor(HGov)” system (with the references listed in the Table B.8).


Table B.8: References and Names of the “Hydraulic Governor (HGov)” system.

Data object reference Point nameACompr/ACompr1 KACO.Oper (Turn On) Air Compressor 1 Contactor Turn OnACompr/ACompr1 KACO.Oper (Turned On) Air Compressor 1 Contactor Turned

OnACompr/ACompr1 SLEV Oil.LoAlm1 Air Compressor 1 Oil Level LowACompr/ACompr1 STMP.HiAlm1 Air Compressor 1 Temperature HighACompr/ACompr2 KACO.Oper (Turn On) Air Compressor 2 Contactor Turn OnACompr/ACompr2 KACO.Oper (Turned On) Air Compressor 2 Contactor Turned

OnACompr/ACompr2 SLEV Oil.LoAlm1 Air Compressor 2 Oil Level LowACompr/ACompr2 STMP.HiAlm1 Air Compressor 2 Temperature HighACompr/125VdcCircAComp XMCB.Pos 125Vdc Circuit AComp DC Mini C.

Breaker ClosedACompr/460VacCirc1 XMCB.Op 460Vac Circuit 1 AC Mini CB Oper-

atedACompr/460VacCirc1 XMCB.Pos 460Vac Circuit 1 AC Mini CB Closed

(2)ACompr/460VacCirc1 XSWI.Pos (Closed) 460Vac Circuit 1 ClosedACompr/460VacCirc2 XMCB.Op 460Vac Circuit 2 AC Mini CB Oper-

atedACompr/460VacCirc2 XMCB.Pos 460Vac Circuit 2 AC Mini CB Closed

(2)ACompr/460VacCirc2 XSWI.Pos (Closed) 460Vac Circuit 2 ClosedACompr/PBInterAComp ICPB.Sw3 (Automatic) Panel Interface AComp Selector

Switch 3 AutomaticACompr/PBInterAComp ICPB.Sw5 (One) Panel Interface AComp Selector

Switch 5 OneACompr/APipe KVLV.Pos (Open) Air Pipe Control Valve OpenACompr/APipe KVLV.Pos (Opened) Air Pipe Control Valve OpenedACompr/ATank SPRS.LoAlm1 Air Tank Pressure LowACompr/ATank SPRS.LoAlm2 Air Tank Pressure Too LowAOTank/AOTank KVLV.Pos (Close) Air-Oil Tank Control Valve CloseAOTank/AOTank KVLV.Pos (Open) Air-Oil Tank Control Valve OpenAOTank/AOTank KVLV.Pos (Closed) Air-Oil Tank Control Valve ClosedAOTank/AOTank KVLV.Pos (Opened) Air-Oil Tank Control Valve OpenedAOTank/AOTank SLEV1.HiAlm1 Air-Oil Tank Level 1 HighAOTank/AOTank SLEV2.HiAlm1 Air-Oil Tank Level 2 Too HighAOTank/AOTank SLEV3.Ind (Normal) Air-Oil Tank Level 3 Normal (2)AOTank/AOTank SLEV3.Ind (Normal) Air-Oil Tank Level 3 Normal (1)AOTank/AOTank SLEV4.LoAlm1 Air-Oil Tank Level 4 LowAOTank/AOTank SLEV5.LoTrip1 Air-Oil Tank Level 5 LowAOTank/AOTank SLEV5.LoTrip2 Air-Oil Tank Level 5 Too Low


Data object reference Point nameAOTank/AOTank SPRS1.HiAlm1 Air-Oil Tank Pressure 1 HighAOTank/AOTank SPRS1.Ind1 (Normal) Air-Oil Tank Pressure 1 NormalAOTank/AOTank SPRS2.LoAlm1 Air-Oil Tank Pressure 2 LowAOTank/AOTank SPRS2.LoAlm2 Air-Oil Tank Pressure 2 LowAOTank/AOTank SPRS2.LoTrip1 Air-Oil Tank Pressure 2 Too LowAOTank/AOTank SPRS.Pres Air-Oil Tank Pressure 3Auto/PrimPump KPMP.Oper (Turn On) Primary Pump Turn On (pseudo)Auto/PrimPump KPMP.Oper (Turned On) Primary Pump Turned On (pseudo)Auto/ResPump KPMP.Oper (Turn On) Reserve Pump Turn On (pseudo)Auto/ResPump KPMP.Oper (Turned On) Reserve Pump Turned On (pseudo)Auto/SeconPump KPMP.Oper (Turn On) Secondary Pump Turn On (pseudo)Auto/SeconPump KPMP.Oper (Turned On) Secondary Pump Turned On (pseudo)OReser/120VacCirc1 XMCB.Pos 120Vac Circuit 1 AC Mini CB ClosedOReser/120VacCirc2 XMCB.Pos 120Vac Circuit 2 AC Mini CB ClosedOReser/460VacCirc1 XMCB.Pos 460Vac Circuit 1 AC Mini CB Closed

(1)OReser/460VacCirc2 XMCB.Pos 460Vac Circuit 2 AC Mini CB Closed

(1)OReser/OPumpA KPMP.Oper (Turn On) Oil Pump A Turn OnOReser/OPumpA KPMP.Oper (Turned On) Oil Pump A Turned OnOReser/OPumpA PTTR.Op Oil Pump A Thermal Overload Relay

OperatedOReser/OPumpB KPMP.Oper (Turn On) Oil Pump B Turn OnOReser/OPumpB KPMP.Oper (Turned On) Oil Pump B Turned OnOReser/OPumpB PTTR.Op Oil Pump B Thermal Overload Relay

OperatedOReser/OTank SLEV.HiAlm1 Oil Tank Level HighOTank/OPipe SPRS.Ind (Normal) Oil Pipe Pressure NormalOTank/WPipe SFLW.LoAlm1 Water Pipe Flow LowOTank/OTank SLEV.LoTrip1 Oil Tank Level 1 Too LowOTank/OTank SLEV.HiAlm1 Oil Tank Level 2 Too HighOTank/OTank STMP.HiAlm1 Oil Tank Temperature Too HighPump/125VdcCircPump XMCB.Pos 125Vdc Circuit Pump DC Mini C.

Breaker ClosedPump/PBInterPump ICPB.Sw (Remote) Panel Interface Pump Selector Switch

RemotePump/PBInterPump ICPB.But1 (one) Panel Interface Pump Button 1 (one)Pump/PBInterPump ICPB.But2 (two) Panel Interface Pump Button 2 (two)Pump/PBInterPump ICPB.But3 (three) Panel Interface Pump Button 3 (three)Pump/MainPipe SPRS.LoAlm1 Main Pipe Pressure LowPump/MainPipe SPRS.LoAlm2 Main Pipe Pressure Too Low


Data object reference Point namePump/OPump1 KPMP.EEHealth Oil Pump 1 FailurePump/OPump1 KPMP.Oper (Turned On) Oil Pump 1 Contactor Turned OnPump/OPump1 XMCB.Ther Oil Pump 1 AC Mini CB OperatedPump/OPump1 XSWI.Pos (Closed) Oil Pump 1 ClosedPump/OPump2 KPMP.EEHealth Oil Pump 2 FailurePump/OPump2 KPMP.Oper (Turned On) Oil Pump 2 Contactor Turned OnPump/OPump2 XMCB.Ther Oil Pump 2 AC Mini CB OperatedPump/OPump2 XSWI.Pos (Closed) Oil Pump 2 ClosedPump/OPump3 KPMP.EEHealth Oil Pump 3 FailurePump/OPump3 KPMP.Oper (Turned On) Oil Pump 3 Contactor Turned OnPump/OPump3 XMCB.Ther Oil Pump 3 AC Mini CB OperatedPump/OPump3 XSWI.Pos (Closed) Oil Pump 3 ClosedServo/ClosingServo KSVV.Op (Disapply) Closing Servomotor Solenoid Valve

DisapplyServo/ClosingServo KSVV.Pos Closing Servomotor Solenoid Valve

DisengagedServo/ClosingServo KSVV.Pos Closing Servomotor Solenoid Valve

EngagedSValve/OPipe KSVV.Mod Oil Pipe Solenoid Valve 1 TestSValve/OPipe KSVV1.Op (Open) Oil Pipe Solenoid Valve 1 OpenSValve/OPipe KSVV1.Pos Oil Pipe Solenoid Valve 1 ClosedSValve/OPipe KSVV1.Pos Oil Pipe Solenoid Valve 1 OpenedSValve/OPipe KSVV.Mod Oil Pipe Solenoid Valve 2 TestSValve/OPipe KSVV2.Op (Open) Oil Pipe Solenoid Valve 2 OpenSValve/OPipe KSVV2.Pos Oil Pipe Solenoid Valve 2 ClosedSValve/OPipe KSVV2.Pos Oil Pipe Solenoid Valve 2 OpenedSValve/OPipe KVLV.PosSpt Oil Pipe Control ValveSValve/OPipe KVLV.PosVlv Oil Pipe


Figure B.2: Schematic diagram of the “Hydraulic Governor (HGov)” system.


B.4 Intake Gate - IGate

The “Intake Gate (IGate)” system have a gate built inside the dam. The water fromreservoir reach the turbine from that gate. Normally it works only in fully open or fullyclose positions (it is not a control gate, but a emergency and maintenance gate).

Thereafter are presented the results regarding the “Intake Gate (IGate)” system.


The equipment and devices of the “Intake Gate (IGate)” system are shown in theTable B.9 (on page 255).

Table B.9: Equipment and devices of the “Intake Gate(IGate)” system.

Equipment Devices125Vdc Batery 1 Under Voltage Relay125Vdc Batery 2 Under Voltage Relay

125Vdc CircuitContactor RelayFuse

125Vdc Rectifier Selector Switch

460Vac CircuitCircuit SwitchUnder Voltage Relay

Gate

Limit Switch 1 (Totally Open)Limit Switch 2 (Replenishment)Limit Switch 3 (Replenishment)Limit Switch 4 (Adrift)Limit Switch 5 (Closed)Limit Switch 6 (Totally Closed)Position Indicator

Oil Pump 1

AC Mini CB 1 (Magnetic Operated)AC Mini CB 1 (Opened)AC Mini CB 2 (Thermal Operated)Contactor Relay

Oil Pump 2

AC Mini CB 1 (Magnetic Operated)AC Mini CB 1 (Opened)AC Mini CB 2 (Thermal Operated)




Contactor RelayOil Tank Level Sensor (switch)

Panel Interface

BuzzerLamp 1 (Cracking)Selector Switch 1 (Normal)Selector Switch 2 (One)Selector Switch 3 (Local)Selector Switch 4 (Turned Off)

ServomotorLevel Sensor (switch) OilTemperature Sensor (transmitter) Oil

ValveLimit Switch 1 (Equilibrated)Limit Switch 2 (Equilibrated)Pressure Sensor (switch)

Oil Pipe 1

Pressure Sensor (switch) 1 (Low)Pressure Sensor (switch) 2 (High)Pressure Sensor (switch) 3 (Low)Pressure Sensor (switch) 4 (High)

Oil Pipe 2

Pressure Sensor (switch) 1 (High)Pressure Sensor (switch) 2 (High)Pressure Sensor (switch) 3 (High)Solenoid Valve 1Solenoid Valve 1 (Defect)Solenoid Valve 1 (Opened)Solenoid Valve 2Solenoid Valve 2 (Defect)Solenoid Valve 2 (Opened)Solenoid Valve 3Solenoid Valve 3 (Defect)Solenoid Valve 3 (Opened)Solenoid Valve 4Solenoid Valve 4 (Defect)Solenoid Valve 4 (Opened)


Logical Nodes

The Table B.10 (on page 257) presents the LN classes necessary to model the “IntakeGate (IGate)” system. The table also shows the quantity of instances of each LN class.

Table B.10: Logical node classes of the “Intake Gate (IGate)” system.

Logical node class InstancesHGPI 1HITG 1ICPB 1

KPMP 2KSVV 4KVLV 1PTUV 3SLEV 2SPRS 8STMP 1XCON 1XFUS 1XMCB 2XSWI 1ZSCR 1


The subsystems or LDs defined for the “Intake Gate (IGate)” system are listed in theTable B.11 (on page 258).


The DO references and the names of the points created for the “Intake Gate(IGate)” system are listed in the Table B.12 (on page 259), sorted by LD.

Schematic Diagram

The Figure B.3 (on page 261) shows a simplified diagrama of the “Intake Gate(IGate)” system (with the references listed in the Table B.12).

The interconnections with other hydraulic units are not shown in the figure.


Table B.11: Subsystems of the “Intake Gate (IGate)” system.

Subsystem AbbreviationBy-Pass Valve BValveControl Power Supply CPowSupGate GateHuman Machine Interface HMInterMotor Power Supply MPowSupPanel Board Power Supply PBPowSupPipes PipePump 1 Pump1Pump 2 Pump2Servomotor ServomSolenoids SolenTank Tank


Table B.12: References and Names of the “Intake Gate (IGate)” system.

Data object reference Point nameBValve/Valve KVLV.ClsPos Valve Equilibrated (2)BValve/Valve KVLV.OpnPos Valve Equilibrated (1)BValve/Valve SPRS.Ind (Equilibrated) Valve Pressure EquilibratedCPowSup/125VdcBat1 PTUV.Op 125Vdc Batery 1 Under Voltage Relay Oper-

atedCPowSup/125VdcBat2 PTUV.Op 125Vdc Batery 2 Under Voltage Relay Oper-

atedCPowSup/125VdcCirc GGIO.Ind (Closed) 125Vdc Circuit ClosedCPowSup/125VdcCirc XFUS.Alm 125Vdc Circuit Fuse BlownCPowSup/125VdcRect ZSCR.Alm 125Vdc Rectifier Selector Switch Turned OnGate/Gate HGPI.PosCm Gate PositionGate/Gate HITG.PosDn Gate Totally ClosedGate/Gate HITG.PosStep Gate Replenishment (1)Gate/Gate HITG.PosStep Gate ClosedGate/Gate HITG.PosUp Gate Totally OpenGate/Gate HITG3.PosStep Gate Replenishment (2)Gate/Gate HITG4.PosStep Gate AdriftHMInter/PBInter ICPB.Buz (Turn On) Panel Interface Buzzer Turn OnHMInter/PBInter ICPB.Lamp1 (Cracking) Panel Interface Lamp CrackingHMInter/PBInter ICPB.Sw1 (Normal) Panel Interface Selector Switch 1 NormalHMInter/PBInter ICPB.Sw2 (One) Panel Interface Selector Switch 2 OneHMInter/PBInter ICPB.Sw3 (Local) Panel Interface Selector Switch 3 LocalHMInter/PBInter ICPB.Sw4 (Turned Off) Panel Interface Selector Switch 4 Turned OffMPowSup/460VacCirc PTUV.Op 460Vac Circuit Under Voltage Relay Oper-

atedMPowSup/460VacCirc XSWI.Pos (Opened) 460Vac Circuit Circuit Switch OpenedPipe/OPipe1 SPRS1.LoAlm1 Oil Pipe 1 Pressure 1 LowPipe/OPipe1 SPRS2.HiAlm1 Oil Pipe 1 Pressure 2 HighPipe/OPipe1 SPRS3.LoAlm1 Oil Pipe 1 Pressure 3 LowPipe/OPipe1 SPRS4.HiAlm1 Oil Pipe 1 Pressure 4 HighPump1/OPump1 KPMP.Oper (Turned On) Oil Pump 1 Turned OnPump1/OPump1 XMCB.Mag Oil Pump 1 AC Mini CB 1 Magnetic Oper-

atedPump1/OPump1 XMCB.Pos Oil Pump 1 AC Mini CB 1 OpenedPump1/OPump1 XMCB.Ther Oil Pump 1 AC Mini CB 2 Thermal OperatedPump2/OPump2 KPMP.Oper (Turned On) Oil Pump 2 Turned OnPump2/OPump2 XMCB.Mag Oil Pump 2 AC Mini CB 1 Magnetic Oper-

atedPump2/OPump2 XMCB.Pos Oil Pump 2 AC Mini CB 1 OpenedPump2/OPump2 XMCB.Ther Oil Pump 2 AC Mini CB 2 Thermal OperatedServom/Servom SLEV Oil.HiAlm1 Servomotor Oil Level HighServom/Servom STMP Oil.Tmp Servomotor Oil Temperature


Data object reference Point nameSolen/OPipe2 KSVV.EEHealth Oil Pipe 2 Solenoid Valve 1 DefectSolen/OPipe2 KSVV.EEHealth Oil Pipe 2 Solenoid Valve 2 DefectSolen/OPipe2 KSVV.EEHealth Oil Pipe 2 Solenoid Valve 3 DefectSolen/OPipe2 KSVV.EEHealth Oil Pipe 2 Solenoid Valve 4 DefectSolen/OPipe2 KSVV.Op (Open) Oil Pipe 2 Solenoid Valve 3 OpenSolen/OPipe2 KSVV.Op (Open) Oil Pipe 2 Solenoid Valve 4 OpenSolen/OPipe2 KSVV.Op (Open) Oil Pipe 2 Solenoid Valve 1 OpenSolen/OPipe2 KSVV.Op (Open) Oil Pipe 2 Solenoid Valve 2 OpenSolen/OPipe2 KSVV.Pos Oil Pipe 2 Solenoid Valve 3 OpenedSolen/OPipe2 KSVV.Pos Oil Pipe 2 Solenoid Valve 4 OpenedSolen/OPipe2 KSVV.Pos Oil Pipe 2 Solenoid Valve 1 OpenedSolen/OPipe2 KSVV.Pos Oil Pipe 2 Solenoid Valve 2 OpenedSolen/OPipe2 SPRS1.HiInd1 Oil Pipe 2 Pressure 1 HighSolen/OPipe2 SPRS2.HiInd1 Oil Pipe 2 Pressure 2 HighSolen/OPipe2 SPRS3.HiInd1 Oil Pipe 2 Pressure 3 HighTank/OTank SLEV.LoAlm1 Oil Tank Level Low


Figure B.3: Schematic diagram of the “Intake Gate (IGate)” system.


B.5 Main Transformer / Phase A - MTraPhA

As stated in the Section 9.8, in the Itaipu power plant each HGU has a bank of threesingle-phase main transformers. This section presents the data of one of those transformes(the phase A transformer). The systems of the other two phases are identical to that (toget the names and references is necessary only to change the phase identification - to use“B” or “C” instead of “A”).

The “Main Transformer - Phase A (MTraPhA)” system has one step-up transformerthat connect the HGU to the substation and then to the transmission network. Thattransformer is located inside the power house of the power plant. In the case presentedhere it is built as a single-phase unit; thus, three systems are necessary for each HGU.

Thereafter are presented the results regarding the “Main Transformer - Phase A(MTraPhA)” system.


The equipment and devices of the “Main Transformer - Phase A (MTraPhA)” systemare shown in the Table B.13 (on page 263).

Logical Nodes

The Table B.14 (on page 264) presents the LN classes necessary to model the “MainTransformer - Phase A (MTraPhA)” system. The table also shows the quantity of instancesof each LN class.


The subsystems or LDs defined for the “Main Transformer - Phase A (MTraPhA)” systemare listed in the Table B.15 (on page 264).


The DO references and the names of the points created for the “Main Transformer -Phase A (MTraPhA)” system are listed in the Table B.16 (on page 265), sorted by LD.

Remember that are used the names of the IEC 61850 standard to identify the DOs.Thus, in some references appear “Tr” instead of “Trip” (and they do not follow theestablished pattern).


Table B.13: Equipment and devices of the “Main Transformer (MTraPhA)” system.

Equipment Devices

125Vdc Circuit

DC Mini CB InDC Mini CB Out 1 (Operated)DC Mini CB Out 2 (Operated)DC to DC Converter 125-24DC to DC Converter 125-48

220Vac CircuitAC Mini CBAC Mini CB FanUnder Voltage Relay

460Vac Circuit AC Mini CBUnder Voltage Relay

Heat Exchanger 1Flow Sensor (switch) OilFlow Sensor (switch) WaterTemperature Sensor (switch) Oil

Heat Exchanger 2Flow Sensor (switch) OilFlow Sensor (switch) WaterTemperature Sensor (switch) Oil

High Bushing Pressure Sensor (switch)Low Bushing Buchholz Relay

Power Transformer

Buchholz RelayLevel Sensor (switch) OilLockout RelayRelief Valve 1 (Operated)Relief Valve 2 (Operated)Temperature Sensor (switch) Prim 1 (High)Temperature Sensor (switch) Prim 1 (Too High)Temperature Sensor (switch) Seco 1 (High)Temperature Sensor (switch) Seco 1 (Too High)Temperature Sensor (transmitter) Oil 1Temperature Sensor (transmitter) Oil 2Temperature Sensor (transmitter) Prim 1Temperature Sensor (transmitter) Prim 2Temperature Sensor (transmitter) Seco 1Temperature Sensor (transmitter) Seco 2

Water Tank Level Sensor (switch)

Schematic Diagram

The Figure B.4 (on page 267) shows a simplified diagrama of the “Main Transformer -Phase A (MTraPhA)” system (with the references listed in the Table B.16).

Note that, only one heat exchanger is shown in the figure.


Table B.14: Logical node classes of the “Main Transformer (MTraPhA)” system.

Logical node class InstancesGGIO 1KRLV 2PTUV 2SFLW 2SIML 2SLEV 2SPRS 1STMP 4XMCB 5

Table B.15: Subsystems of the “Main Transformer (MTraPhA)” system.

Subsystem AbbreviationBushing BushControl Power Supply CPowSupHeat Exchanger HeatExchMotor Power Supply MPowSupPanel Board Power Supply PBPowSupPower Transformer PTraWater Tank WTank


Table B.16: References and Names of the “Main Transformer (MTraPhA)” system.

Data object reference Point nameBush/HighBush SPRS.HiAlm1 High Bushing Pressure HighBush/HighBush SPRS.HiTrip1 High Bushing Pressure Too HighBush/HighBush SPRS.LoAlm1 High Bushing Pressure LowBush/LowBush SIML.GasInsTr Low Bushing Buchholz Relay OperatedBush/LowBush SIML.HiGasInsAlm1 Low Bushing Buchholz Relay HighCPowSup/125VdcCirc XMCB In.Op 125Vdc Circuit In DC Mini CB OperatedCPowSup/125VdcCirc XMCB1 Out.Op 125Vdc Circuit Out DC Mini CB 1 Op-

eratedCPowSup/125VdcCirc XMCB2 Out.Op 125Vdc Circuit Out DC Mini CB 2 Op-

eratedCPowSup/125VdcCirc ZDCC 125-24.EEHealth 125Vdc Circuit 125-24 DC to DC FailureCPowSup/125VdcCirc ZDCC 125-48.EEHealth 125Vdc Circuit 125-48 DC to DC FailureHeatExch/HeatExch1 SFLW Oil.Ind (Normal) Heat Exchanger 1 Oil Flow NormalHeatExch/HeatExch1 SFLW Water.Ind (Normal) Heat Exchanger 1 Water Flow NormalHeatExch/HeatExch1 STMP Oil.HiTmp1 Heat Exchanger 1 Oil Temperature HighHeatExch/HeatExch1 STMP Oil.HiTrip1 Heat Exchanger 1 Oil Temperature Too

HighHeatExch/HeatExch2 SFLW Oil.Ind (Normal) Heat Exchanger 2 Oil Flow NormalHeatExch/HeatExch2 SFLW Water.Ind (Normal) Heat Exchanger 2 Water Flow NormalHeatExch/HeatExch2 STMP Oil.HiTmp1 Heat Exchanger 2 Oil Temperature HighHeatExch/HeatExch2 STMP Oil.HiTrip1 Heat Exchanger 2 Oil Temperature Too

HighMPowSup/460VacCirc PTUV.Op 460Vac Circuit Under Voltage Relay Op-

eratedMPowSup/460VacCirc XMCB.Pos 460Vac Circuit AC Mini CB OpenedPBPowSup/220VacCirc PTUV.Op 220Vac Circuit Under Voltage Relay Op-

eratedPBPowSup/220VacCirc XMCB.Op 220Vac Circuit AC Mini CB OperatedPBPowSup/220VacCirc XMCB.Pos 220Vac Circuit AC Mini CB OpenedPBPowSup/220VacCirc XMCB Fan.Op 220Vac Circuit Fan AC Mini CB Oper-

atedPTra/Tra GGIO.EEHealth (Failure) Power Transformer Lockout Relay Fail-

urePTra/Tra GGIO.Ind (Test) Power Transformer Lockout Relay TestPTra/Tra GGIO.Trip (Operated) Power Transformer Lockout Relay Op-

eratedPTra/Tra KRLV1.Op Power Transformer Relief Valve 1 Oper-

atedPTra/Tra KRLV2.Op Power Transformer Relief Valve 2 Oper-

ated


Data object reference Point namePTra/Tra SIML.GasInsAlm Power Transformer Buchholz Relay Op-

erated (1)PTra/Tra SIML.GasInsTr Power Transformer Buchholz Relay Op-

erated (2)PTra/Tra SLEV Oil.HiAlm1 Power Transformer Oil Level HighPTra/Tra SLEV Oil.LoAlm1 Power Transformer Oil Level LowPTra/Tra STMP Oil.Tmp Power Transformer Oil Temperature 2PTra/Tra STMP Prim.HiAlm1 Power Transformer Prim Temperature 1

HighPTra/Tra STMP Prim.HiTrip1 Power Transformer Prim Temperature 1

Too HighPTra/Tra STMP Prim.Tmp Power Transformer Prim Temperature 1PTra/Tra STMP Prim.Tmp Power Transformer Prim Temperature 2PTra/Tra STMP Seco.HiAlm1 Power Transformer Seco Temperature 1

HighPTra/Tra STMP Seco.HiTrip1 Power Transformer Seco Temperature 1

Too HighPTra/Tra STMP Seco.Tmp Power Transformer Seco Temperature 2PTra/Tra STMP Seco.Tmp Power Transformer Seco Temperature 1PTra/Tra STMP1 Oil.Tmp Power Transformer Oil Temperature 1WTank/WTank SLEV.HiAlm1 Water Tank Level HighWTank/WTank SLEV.LoAlm1 Water Tank Level Low


Figure B.4: Schematic diagram of the “Main Transformer (MTraPhA)” system.


B.6 Motor Control Center - MotContCen

The “Motor Control Center (MotContCen)” system is the panel board having a commonpower bus and many control units and contactors to feed diverse loads of the auxiliarysystems of the HGU. It also has protection and metering devices.

Thereafter are presented the results regarding the “Motor Control Center(MotContCen)” system.

Note that, for simplicity, only two feeder circuits are presented.


The equipment and devices of the “Motor Control Center (MotContCen)” system areshown in the Table B.17 (on page 268).

The table does not contain the equipment and devices of all units of the “Motor ControlCenter (MotContCen)” system.

Table B.17: Equipment and devices of the “Motor Con-trol Center (MotContCen)” system.

Equipment Devices

125Vdc Circuit 1DC Mini CBUnder Voltage Relay



13.8kV-460V Power Transformer 2

Block RelayOver Current RelayTemperature Sensor (switch) CoreTemperature Sensor (switch) Wi

18kV-460V Power Transformer 1

Temperature Sensor (transmitter) Core 1Temperature Sensor (transmitter) Core 2Temperature Sensor (transmitter) Core 3Temperature Sensor (transmitter) Wi 1Temperature Sensor (transmitter) Wi 2Temperature Sensor (transmitter) Wi 3




460Vac Circuit 1AmmeterUnder Voltage RelayVoltmeter

460Vac Circuit 2AmmeterUnder Voltage RelayVoltmeter

460Vac Circuit 3AmmeterVoltmeter

460Vac Circuit Breaker 52.1

Auxiliary Contact 1 (Opened)Auxiliary Contact 2 (Closed)Limit SwitchOver Current Relay





460Vac Disconnector 1Auxiliary Contact 1 (Opened)Auxiliary Contact 2 (Closed)



Distribution BusbarUnder Voltage RelayVoltmeter

MCC Unit 52.11A

Auxiliary Contact 1 (Opened)Auxiliary Contact 2 (Closed)Limit SwitchThermal Overload Relay

Phase A - Fan 1 Rotation Sensor (switch)Continue on next page...



Phase B - Fan 1 Rotation Sensor (switch)Phase C - Fan 1 Rotation Sensor (switch)

MCC Unit 52.2A

AC Mini CBContactorLimit SwitchThermal Overload Relay

MCC Unit 52.30B


Panel InterfaceSelector Switch 1 (Remote)Selector Switch 2 (One)

Logical Nodes

The Table B.18 (on page 270) presents the LN classes necessary to model the “MotorControl Center (MotContCen)” system. The table also shows the quantity of instances ofeach LN class.

Table B.18: Logical node classes of the “Motor Control Center (MotContCen)” system.

Logical node class InstancesGGIO 1ICPB 1KFAN 3

MMXU 4PIOC 6PTTR 1PTUV 6STMP 7XCBR 10XCCU 1XCON 1XMCB 4XSWI 6



The subsystems or LDs defined for the “Motor Control Center (MotContCen)” systemare listed in the Table B.19 (on page 271).

Table B.19: Subsystems of the “Motor Control Center (MotContCen)” system.

Subsystem AbbreviationAeration Valve AValveTurbine TurGenerator Cooling GUCoolAutomatic Voltage Regulator ExcitAuxiliary Power Supply APowSupAuxiliary Transformation ATraAuxiliary Transformer Cooling ATCoolBusbar BusbarCollector Ring CRingControl Power Supply CPowSupEmergency Power Supply EPowSupEmergency Transformation ETraGenerator Power Supply GPowSupGenerator Transformation GTraHuman Machine Interface HMInterHydraulic Governor HGovMain Transformer Cooling MTCoolMiddle Bearing MBearPurified Water PWater

Note that, it was created one conventional panel board HMI for each main circuitbreaker. Also it is possible to model all conventional HMIs in a single LD.


The DO references and the names of the points created for the “Motor Control Center(MotContCen)” system are listed in the Table B.20 (on page 272), sorted by LD.

Schematic Diagram

The Figure B.5 (on page 275) shows a simplified diagrama of the “Motor Control Center(MotContCen)” system (with the references listed in the Table B.20).

In addition to some symbology of the ANSI/ISA-S5.1 standard [59], some functionnumbers of the IEEE Std C37.2TM-2008 “Standard for Electrical Power System DeviceFunction Numbers, Acronyms, and Contact Designations” [67] are used for designations


Table B.20: References and Names of the “Motor Control Center (MotContCen)” system.

Data object reference Point nameAPowSup/460VacCirc2 MMXU.A.phsA 460Vac Circuit 2 Phase A CurrentAPowSup/460VacCirc2 MMXU.A.phsB 460Vac Circuit 2 Phase B CurrentAPowSup/460VacCirc2 MMXU.A.PhsC 460Vac Circuit 2 Phase C CurrentAPowSup/460VacCirc2 MMXU.PhV.phsA 460Vac Circuit 2 Phase A VoltageAPowSup/460VacCirc2 MMXU.PhV.phsB 460Vac Circuit 2 Phase B VoltageAPowSup/460VacCirc2 MMXU.PhV.phsC 460Vac Circuit 2 Phase C VoltageAPowSup/460VacCirc2 PTUV.Op 460Vac Circuit 2 Under Voltage Relay

OperatedAPowSup/460VacCircBreak52.2 PIOC.Op 460Vac Circuit Breaker 52.2 Over Cur-

rent Relay OperatedAPowSup/460VacCircBreak52.2 XCBR.Niche 460Vac Circuit Breaker 52.2 ExtractedAPowSup/460VacCircBreak52.2 XCBR.Pos 460Vac Circuit Breaker 52.2 OpenedAPowSup/460VacCircBreak52.2 XCBR2.Pos 460Vac Circuit Breaker 52.2 ClosedAPowSup/460VacDiscon2 XSWI1.Pos (Opened) 460Vac Disconnector 2 OpenedAPowSup/460VacDiscon2 XSWI2.Pos (Closed) 460Vac Disconnector 2 ClosedATCool/PhAFan1 KFAN.EEHealth Phase A - Fan 1 Angular Speed FailureATCool/PhBFan1 KFAN.EEHealth Phase B - Fan 1 Angular Speed FailureATCool/PhCFan1 KFAN.EEHealth Phase C - Fan 1 Angular Speed FailureATra/13.8kV-460VTra2 GGIO.Ind (Operated) 13.8kV-460V Power Transformer 2 Block

Relay OperatedATra/13.8kV-460VTra2 PIOC.Health 13.8kV-460V Power Transformer 2 Over

Current Relay FailureATra/13.8kV-460VTra2 PIOC.Op 13.8kV-460V Power Transformer 2 Over

Current Relay OperatedATra/13.8kV-460VTra2 STMP Core.HiAlm1 13.8kV-460V Power Transformer 2 Core

Temperature HighATra/13.8kV-460VTra2 STMP Wi.HiAlm2 13.8kV-460V Power Transformer 2 Wi

Temperature HighBusbar/DistrBusbar MMXU.PhV.phsA Distribution Busbar Phase A VoltageBusbar/DistrBusbar MMXU.PhV.phsB Distribution Busbar Phase B VoltageBusbar/DistrBusbar MMXU.PhV.phsC Distribution Busbar Phase C VoltageBusbar/DistrBusbar PTUV.Op Distribution Busbar Under Voltage Relay

OperatedCPowSup/125VdcCirc1 PTUV.Op 125Vdc Circuit 1 Under Voltage Relay

OperatedCPowSup/125VdcCirc1 XMCB.Pos 125Vdc Circuit 1 DC Mini CB OpenedCPowSup/125VdcCirc2 PTUV.Op 125Vdc Circuit 2 Under Voltage Relay

OperatedCPowSup/125VdcCirc2 XMCB.Pos 125Vdc Circuit 2 DC Mini CB OpenedCPowSup/125VdcCirc3 PTUV.Op 125Vdc Circuit 3 Under Voltage Relay

Operated


Data object reference Point nameCPowSup/125VdcCirc3 XMCB.Pos 125Vdc Circuit 3 DC Mini CB OpenedCRing/MCCUnit52.11A PIOC.Op MCC Unit 52.11A Thermal Overload Re-

lay OperatedCRing/MCCUnit52.11A XCBR.Niche MCC Unit 52.11A ExtractedCRing/MCCUnit52.11A XCBR.Pos MCC Unit 52.11A OpenedCRing/MCCUnit52.11A XCBR2.Pos MCC Unit 52.11A ClosedEPowSup/460VacCirc3 MMXU.A.phsA 460Vac Circuit 3 Phase A CurrentEPowSup/460VacCirc3 MMXU.A.phsB 460Vac Circuit 3 Phase B CurrentEPowSup/460VacCirc3 MMXU.A.PhsC 460Vac Circuit 3 Phase C CurrentEPowSup/460VacCirc3 MMXU.PhV.phsA 460Vac Circuit 3 Phase A VoltageEPowSup/460VacCirc3 MMXU.PhV.phsB 460Vac Circuit 3 Phase B VoltageEPowSup/460VacCirc3 MMXU.PhV.phsC 460Vac Circuit 3 Phase C VoltageEPowSup/460VacCircBreak52.3 PIOC.Op 460Vac Circuit Breaker 52.3 Over Cur-

rent Relay OperatedEPowSup/460VacCircBreak52.3 XCBR.Niche 460Vac Circuit Breaker 52.3 ExtractedEPowSup/460VacCircBreak52.3 XCBR.Pos 460Vac Circuit Breaker 52.3 OpenedEPowSup/460VacCircBreak52.3 XCBR2.Pos 460Vac Circuit Breaker 52.3 ClosedEPowSup/460VacDiscon3 XSWI1.Pos (Opened) 460Vac Disconnector 3 OpenedEPowSup/460VacDiscon3 XSWI2.Pos (Closed) 460Vac Disconnector 3 ClosedGPowSup/460VacCirc1 MMXU.A.phsA 460Vac Circuit 1 Phase A CurrentGPowSup/460VacCirc1 MMXU.A.phsB 460Vac Circuit 1 Phase B CurrentGPowSup/460VacCirc1 MMXU.A.PhsC 460Vac Circuit 1 Phase C CurrentGPowSup/460VacCirc1 MMXU.PhV.phsA 460Vac Circuit 1 Phase A VoltageGPowSup/460VacCirc1 MMXU.PhV.phsB 460Vac Circuit 1 Phase B VoltageGPowSup/460VacCirc1 MMXU.PhV.phsC 460Vac Circuit 1 Phase C VoltageGPowSup/460VacCirc1 PTUV.Op 460Vac Circuit 1 Under Voltage Relay

OperatedGPowSup/460VacCircBreak52.1 PIOC.Op 460Vac Circuit Breaker 52.1 Over Cur-

rent Relay OperatedGPowSup/460VacCircBreak52.1 XCBR.Niche 460Vac Circuit Breaker 52.1 ExtractedGPowSup/460VacCircBreak52.1 XCBR.Pos 460Vac Circuit Breaker 52.1 OpenedGPowSup/460VacCircBreak52.1 XCBR2.Pos 460Vac Circuit Breaker 52.1 ClosedGPowSup/460VacDiscon1 XSWI1.Pos (Opened) 460Vac Disconnector 1 OpenedGPowSup/460VacDiscon1 XSWI2.Pos (Closed) 460Vac Disconnector 1 ClosedGTra/18kV-460VTra1 STMP1 Core.Tmp 18kV-460V Power Transformer 1 Core

Phase A Temperature 1GTra/18kV-460VTra1 STMP1 Wi.Tmp 18kV-460V Power Transformer 1 Wi

Phase A Temperature 1GTra/18kV-460VTra1 STMP2 Core.Tmp 18kV-460V Power Transformer 1 Core

Phase C Temperature 2GTra/18kV-460VTra1 STMP2 Wi.Tmp 18kV-460V Power Transformer 1 Wi

Phase C Temperature 2


Data object reference Point nameGTra/18kV-460VTra1 STMP3 Core.Tmp 18kV-460V Power Transformer 1 Core

Phase B Temperature 3GTra/18kV-460VTra1 STMP3 Wi.Tmp 18kV-460V Power Transformer 1 Wi

Phase B Temperature 3HMInter/PBInter ICPB.Sw1 (Remote) Panel Interface Selector Switch 1 Re-

moteHMInter/PBInter ICPB.Sw2 (One) Panel Interface Selector Switch 2 OneMBear/MCCUnit52.2A PTTR.Op MCC Unit 52.2A Thermal Overload Re-

lay OperatedMBear/MCCUnit52.2A XCCU.Niche MCC Unit 52.2A ExtractedMBear/MCCUnit52.2A XCCU.Test MCC Unit 52.2A TestMBear/MCCUnit52.2A XCON.Pos (Close) MCC Unit 52.2A Contactor CloseMBear/MCCUnit52.2A XCON.Pos (Closed) MCC Unit 52.2A Contactor ClosedMBear/MCCUnit52.2A XMCB.Mag MCC Unit 52.2A AC Mini CB Magnetic

OperatedMBear/MCCUnit52.2A XMCB.Pos MCC Unit 52.2A AC Mini CB OpenedMTCool/MCCUnit52.30B PIOC.Op MCC Unit 52.30B Over Current Relay

OperatedMTCool/MCCUnit52.30B XCBR.Niche MCC Unit 52.30B ExtractedMTCool/MCCUnit52.30B XCBR.Pos MCC Unit 52.30B OpenedMTCool/MCCUnit52.30B XCBR2.Pos MCC Unit 52.30B Closed

of devices. The typical real UMCC has around 25 feeders, but they are not represented inthe figure. In the figure are represented, for example purposes, only two feeders: “CollectorRing” and “Main Transformer Cooling”.

The references (points) of feeders regarding specific data of other systems (listed inthe Table B.20) are represented in those systems.


Figure B.5: Schematic diagram of the “Motor Control Center (MotContCen)” system.


B.7 Purified Water - PWater

The “Purified Water (PWater)” system provides deionized water (or demineralizedwater) to the generator for direct cooling of the stator winding and of the associated com-ponents. The control and supervision of the electrical conductivity of water are necessary.

Thereafter are presented the results regarding the “Purified Water (PWater)” system.


The equipment and devices of the “Purified Water (PWater)” system are shown in theTable B.21 (on page 276).

Table B.21: Equipment and devices of the “Purified Wa-ter (PWater)” system.

Equipment Devices125Vdc Circuit 1 DC Mini CB125Vdc Circuit 2 DC Mini CB220Vac Circuit AC Mini CB24Vdc Circuit DC Mini CB460Vac Circuit AC Mini CBAlkalizator Condutivity Sensor (transmitter)

Expansion Tank

Level Sensor (switch)Level Sensor (transmitter)Pressure Sensor (switch)Pressure Sensor (transmitter)

FilterCondutivity Sensor (switch)Condutivity Sensor (transmitter)Pressure Sensor (switch)

Ions ExchangerAuxiliary ContactCondutivity Sensor (transmitter)

Nitrogen Cylinder Pressure Sensor (switch)

Panel InterfaceSelector Switch 1 (Automatic)Selector Switch 2 (One)Selector Switch 3 (Automatic)

Pump 1Auxiliary Contact




Contactor RelayOver Frequency Relay

Pump 2Auxiliary ContactContactor RelayOver Frequency Relay

Purified Water Pipe 1

Pressure Sensor (switch)Pressure Sensor (transmitter)Temperature Sensor (switch) 2 (High)Temperature Sensor (switch) 2 (Too High)Temperature Sensor (transmitter) 1Temperature Sensor (transmitter) 2

Purified Water Pipe 2 Flow Sensor (switch)

Purified Water Pipe 3

Flow Sensor (switch) StaOutPressure Sensor (switch) 1 (High)Pressure Sensor (switch) 1 (Too Low)Pressure Sensor (switch) 2 (Low)Temperature Sensor (switch) StaInTemperature Sensor (switch) StaOutTemperature Sensor (transmitter) StaInTemperature Sensor (transmitter) StaOut

Reposition Tank

Level Sensor (switch)Level Sensor (transmitter)Pressure Sensor (switch)Pressure Sensor (transmitter)

Water Pipe

Control ValvePressure Sensor (switch)Temperature Sensor (transmitter) InTemperature Sensor (transmitter) Out

Logical Nodes

The Table B.22 (on page 278) presents the LN classes necessary to model the “PurifiedWater (PWater)” system. The table also shows the quantity of instances of each LN class.


Table B.22: Logical node classes of the “Purified Water (PWater)” system.

Logical node class InstancesICPB 1KFIL 2

KPMP 2KVLV 1PTOF 2SECW 3SFLW 2SLEV 2SPRS 6STMP 3XMCB 6


The subsystems or LDs defined for the “Purified Water (PWater)” system are listed inthe Table B.23 (on page 278).

Table B.23: Subsystems of the “Purified Water (PWater)” system.

Subsystem AbbreviationControl Power Supply CPowSupExpansion Tank ETankFilter FilterHeat Exchange HeatExchHuman Machine Interface HMInterMotor Power Supply MPowSupPanel Board Power Supply PBPowSupPumps PumpPurified Water PWaterRaw Water RWaterRepositon Tank RTankStator StatTreatment of Water WTreat


The DO references and the names of the points created for the “Purified Water(PWater)” system are listed in the Table B.24 (on page 279), sorted by LD.


Table B.24: References and Names of the “Purified Water (PWater)” system.

Data object reference Point nameCPowSup/125VdcCirc1 XMCB.Op 125Vdc Circuit 1 DC Mini CB OperatedCPowSup/125VdcCirc1 XMCB.Pos 125Vdc Circuit 1 DC Mini CB OpenedCPowSup/125VdcCirc2 XMCB.Op 125Vdc Circuit 2 DC Mini CB OperatedCPowSup/125VdcCirc2 XMCB.Pos 125Vdc Circuit 2 DC Mini CB OpenedCPowSup/24VdcCirc XMCB.Op 24Vdc Circuit DC Mini CB OperatedCPowSup/24VdcCirc XMCB.Pos 24Vdc Circuit DC Mini CB OpenedETank/ETank SLEV.HiAlm1 Expansion Tank Level HighETank/ETank SLEV.LevPc Expansion Tank LevelETank/ETank SLEV.LoAlm1 Expansion Tank Level LowETank/ETank SLEV.LoTrip1 Expansion Tank Level Too LowETank/ETank SPRS.HiTrip1 Expansion Tank Pressure Too HighETank/ETank SPRS.Pres Expansion Tank Differential PressureETank/NitrCyl SPRS.HiAlm1 Nitrogen Cylinder Pressure HighETank/NitrCyl SPRS.LoAlm1 Nitrogen Cylinder Pressure LowFilter/Filter KFIL.HiFilAlm1 Filter Pressure HighFilter/Filter SECW.Cdt Filter Electric CondutivityFilter/Filter SECW.HiAlm1 Filter Electric Condutivity HighFilter/Filter SECW.HiTrip1 Filter Electric Condutivity Too HighHMInter/PBInter ICPB.Sw1 (Automatic) Panel Interface Selector Switch 1 AutomaticHMInter/PBInter ICPB.Sw2 (One) Panel Interface Selector Switch 2 OneHMInter/PBInter ICPB.Sw3 (Automatic) Panel Interface Selector Switch 3 AutomaticMPowSup/460VacCirc XMCB.Op 460Vac Circuit AC Mini CB OperatedMPowSup/460VacCirc XMCB.Pos 460Vac Circuit AC Mini CB OpenedPBPowSup/220VacCirc XMCB.Op 220Vac Circuit AC Mini CB OperatedPBPowSup/220VacCirc XMCB.Pos 220Vac Circuit AC Mini CB OpenedPump/Pump1 KPMP.EEHealth Pump 1 FailurePump/Pump1 KPMP.Oper (Turn Off) Pump 1 Turn OffPump/Pump1 KPMP.Oper (Turn On) Pump 1 Turn OnPump/Pump1 KPMP.Oper (Turned On) Pump 1 Turned OnPump/Pump1 PTOF.Op Pump 1 Over Frequency Relay OperatedPump/Pump2 KPMP.EEHealth Pump 2 FailurePump/Pump2 KPMP.Oper (Turn Off) Pump 2 Turn OffPump/Pump2 KPMP.Oper (Turn On) Pump 2 Turn OnPump/Pump2 KPMP.Oper (Turned On) Pump 2 Turned OnPump/Pump2 PTOF.Op Pump 2 Over Frequency Relay OperatedPWater/PWaterPipe1 SPRS.HiTrip1 Purified Water Pipe 1 Pressure Too HighPWater/PWaterPipe1 SPRS.LoAlm1 Purified Water Pipe 1 Pressure LowPWater/PWaterPipe1 SPRS.Pres Purified Water Pipe 1 PressurePWater/PWaterPipe1 STMP.HiAlm1 Purified Water Pipe 1 Temperature 2 HighPWater/PWaterPipe1 STMP.HiTrip1 Purified Water Pipe 1 Temperature 2 Too

High


Data object reference Point namePWater/PWaterPipe1 STMP.Tmp Purified Water Pipe 1 Temperature 2PWater/PWaterPipe1 STMP.Tmp Purified Water Pipe 1 Temperature 1PWater/PWaterPipe2 SFLW.LoAlm1 Purified Water Pipe 2 Flow LowRTank/RTank SLEV.HiAlm1 Reposition Tank Level HighRTank/RTank SLEV.LevPc Reposition Tank LevelRTank/RTank SLEV.LoAlm1 Reposition Tank Level LowRTank/RTank SPRS.HiAlm1 Reposition Tank Pressure HighRTank/RTank SPRS.LoAlm1 Reposition Tank Pressure LowRTank/RTank SPRS.Pres Reposition Tank PressureRWater/WPipe KVLV.ClsPos Water Pipe Control Valve ClosedRWater/WPipe KVLV.OpnPos Water Pipe Control Valve OpenedRWater/WPipe KVLV.PosSpt Water Pipe Control Valve Set-PointRWater/WPipe KVLV.PosVlv Water PipeRWater/WPipe SPRS.LoAlm1 Water Pipe Pressure LowRWater/WPipe STMP In.Tmp Water Pipe In TemperatureRWater/WPipe STMP Out.Tmp Water Pipe Out TemperatureRWater/WPipe XMCB.Ther Water Pipe Control Valve Thermal OperatedStat/PWaterPipe3 SFLW StaOut.LoAlm1 Purified Water Pipe 3 StaOut Flow LowStat/PWaterPipe3 SFLW StaOut.LoTrip1 Purified Water Pipe 3 StaOut Flow Too LowStat/PWaterPipe3 SPRS.HiAlm1 Purified Water Pipe 3 Pressure 1 HighStat/PWaterPipe3 SPRS.LoAlm1 Purified Water Pipe 3 Pressure 2 LowStat/PWaterPipe3 SPRS.LoTrip1 Purified Water Pipe 3 Pressure 1 Too LowStat/PWaterPipe3 STMP StaIn.HiAlm1 Purified Water Pipe 3 StaIn Temperature

HighStat/PWaterPipe3 STMP StaIn.HiTrip1 Purified Water Pipe 3 StaIn Temperature Too

HighStat/PWaterPipe3 STMP StaIn.Tmp Purified Water Pipe 3 StaIn TemperatureStat/PWaterPipe3 STMP StaOut.HiAlm1 Purified Water Pipe 3 StaOut Temperature

HighStat/PWaterPipe3 STMP StaOut.HiTrip1 Purified Water Pipe 3 StaOut Temperature

Too HighStat/PWaterPipe3 STMP StaOut.Tmp Purified Water Pipe 3 StaOut TemperatureWTreat/Alk SECW.Cdt Alkalizator Electric CondutivityWTreat/IExch KFIL.FilAlm Ions Exchanger SaturatedWTreat/IExch SECW.Cdt Ions Exchanger Electric Condutivity

Schematic Diagram

The Figure B.6 (on page 281) shows a simplified diagrama of the “Purified Water(PWater)” system (with the references listed in the Table B.24).


Figure B.6: Schematic diagram of the “Purified Water (PWater)” system.


B.8 Raw Water - RWater

The “Raw Water (RWater)” system realize the raw water treatment. It has diversetanks, pipelines and valves. The raw water is utilized in the power plant for cooling ofequipment, mainly the main transformers.

Thereafter are presented the results regarding the “Raw Water (RWater)” system.


The equipment and devices of the “Raw Water (RWater)” system are shown in theTable B.25 (on page 282).

Table B.25: Equipment and devices of the “Raw Water (RWater)” system.

Equipment Devices125Vdc Circuit 1 DC Mini CB125Vdc Circuit 2 DC Mini CB220Vac Circuit 1 AC Mini CB220Vac Circuit 2 AC Mini CB

Cuno-Flo Filter

Auxiliary Contact 1 (Cleaning)Auxiliary Contact 2 (Ready)Pressure Sensor (switch) Air 2 (Low)Pressure Sensor (switch) Water 1 (Low)

Water Valve

Contactor Relay 1Contactor Relay 2Limit Switch 1 (Opened)Limit Switch 2 (Closed)

Logical Nodes

The Table B.26 (on page 282) presents the LN classes necessary to model the “RawWater (RWater)” system. The table also shows the quantity of instances of each LN class.

Table B.26: Logical node classes of the “Raw Water (RWater)” system.

Logical node class InstancesXMCB 2KFIL 1

XMCB 2HVLV 1



The subsystems or LDs defined for the “Raw Water (RWater)” system are listed inthe Table B.27 (on page 283).

Table B.27: Subsystems of the “Raw Water (RWater)” system.

Subsystem AbbreviationControl Power Motor MPowSupControl Power Supply CPowSupFilter FilterValve Valve


The DO references and the names of the points created for the “Raw Water(RWater)” system are listed in the Table B.28 (on page 283), sorted by LD.

Table B.28: References and Names of the “Raw Water (RWater)” system.

Data object reference Point nameCPowSup/125VdcCirc1 XMCB.Op 125Vdc Circuit 1 DC Mini CB OperatedCPowSup/125VdcCirc2 XMCB.Op 125Vdc Circuit 2 DC Mini CB OperatedFilter/CunofloFilter KFIL.Flush Cuno-Flo Filter CleaningFilter/CunofloFilter KFIL.FlushCnt Cuno-Flo Filter ReadyFilter/CunofloFilter KFIL Air.LoFilAlm1 Cuno-Flo Filter Air Pressure 2 LowFilter/CunofloFilter KFIL Water.LoDifPresHi1 Cuno-Flo Filter Water Pressure 1 LowMPowSup/220VacCirc1 XMCB.Op 220Vac Circuit 1 AC Mini CB OperatedMPowSup/220VacCirc2 XMCB.Op 220Vac Circuit 2 AC Mini CB OperatedValve/WaterValve HVLV.Cls (Close) Water Valve CloseValve/WaterValve HVLV.ClsPos Water Valve ClosedValve/WaterValve HVLV.Opn (Open) Water Valve OpenValve/WaterValve HVLV.OpnPos Water Valve Opened

Schematic Diagram

The Figure B.7 (on page 284) shows a simplified diagrama of the “Raw Water(RWater)” system (with the references listed in the Table B.28).


Figure B.7: Schematic diagram of the “Raw Water (RWater)” system.


B.9 Concluding Remarks

The data presented in this appendix is the first approach (finalized by a hard deadline)and have to be reviewed.

Appendix C

IEC 61850 Issues

C.1 Introduction

This appendix presents some comments and proposals of modifications of the IEC61850 standard. Other proposals were presented in the Chapters 6 “IEC 61850 Stan-dard and Communications” and 7 “Modelling of the Generating Unit”, because they areessential to understand the developments or to apply in the examples.

The main idea is to allow the application of the IEC 61850 standard in HPPs andalso to improve the standard. In addition, a critical analysis of the standard is presented,including some doubts and suggestions that arose during the development of this research.

C.2 Clarifications

This section present some subjects from the IEC 61850 standard that are difficultto understand1 and thus, they could be improved. If the texts, tables, figures, etc. inthe parts of the standard are suitable, maybe some clarification can be included in theappropriated technical reports.

C.2.1 Logical Devices

In some parts of the standard it is established that the use of LDs is optional. Butthe part IEC 61850-7-510 [63] in the item “4.1 Logical device modelling” states: “LogicalNodes must be assembled in Logical Devices”. Only as example, the same part of thestandard states that LDs are not an application requirement.

1That is a particular point of view of the author of this report as “user” of the standard. Thus, maybethere are no problems in the standard, but in the interpretation of the author.

Appendix C. IEC 61850 Issues 287

Considering the functions of the LDs in the implementation of the automation systems,in this research it is considered that the LDs are obligatory.

C.2.2 Human Machine Interface - IHMI

It is suggested to clarify the application of the LN class “Human Machine Interface- IHMI” (and other similar LN classes: “Telecontrol Interface - ITCI”, “TelemonitoringInterface - ITMI”, etc.) and also how the HMIs works according the IEC 61850 standard.A description of the specification of those elements also can help to apply them.

C.3 Pattern of Logical Nodes Classes

It is necessary to defined directives of standardization so that the data models (def-initions of classes) follow an unified pattern. Some LN classes are very simple (a fewDOs) and other LN classes for similar equipment or function are very complex (excess ofDOs); besides, some similar DOs of distinct LN classes have diverse specifications as, forexample, different CDCs.

Several examples of the problem described above can be found in the specifications ofthe LN classes for sensors. There are LN classes for sensors with dozens of DOs and otherwith a few DOs. Strictly speaking, the main characteristic that changes in the sensors isthe quantity to be measured, so there should not be much difference in the specifications.

The problem also can be found in the specification of the commands. There are diverseapproaches of commands for similar situations.

C.4 Modified Logical Node Classes

For improvements in the IEC 61850 standard, this section presents some suggestionsof modifications of existing LN classes specifications.

For simplification, in most cases the “Common Information” (information independentof the dedicated function represented by the LN class) of the LN classes are not presented.

C.4.1 Generic Process I/O - GGIO

The Table C.1 (at page 288) presents the GGIO LN class.

C.4.2 Generator Shaft Bearing - HBRG

The Table C.2 (at page 288) presents the HBRG LN class.


Table C.1: Specification of the GGIO LN class.GGIO Class

Data Object CDC Explanation T M/O/CCommon InformationEEHealth ENS External equipment health (external sensor) OEEName DPL External equipment name plate OLoc SPS Local Control Behavior OLocKey SPS Local or remote key OLocSta SPC Remote Control Blocked OOpCntRs INC Resetable operation counter OStatus InformationAlm SPS General single alarm OInd SPS General indication (binary input) OIntIn INS Integer status input OTrip SPS General single trip OWrn SPS General single warning OMeasured ValuesAnIn MV Analogue input OAnOut APC Controllable analogue output OMetered ValuesCntRs BCR Counter, resetable OControlsDPCSO DPC Double point controllable status output OISCSO INC Integer status controllable status output OSPCSO SPC Single point controllable status output O

Table C.2: Specification of the HBRG LN class.HBRG Class

Data Object CDC Explanation T M/O/CSettingsBrgTyp ING Type of bearing: 1 Generator thrust ; 2 Generator

guide ; 3 Turbine thrust ; 4 Turbine guide ; 5Combined guide and thrust ; 6 Gear-box ; 7 Clutch

M

Status InformationOilTmpHi SPS Lubrication oil temperature alarm OTmpAlm SPS Bearing temperature alarm O

C.4.3 Dam Gate - HGTE

The Table C.3 (at page 289) presents the HGTE LN class.

C.4.4 Intake Gate - HITG

The Table C.4 (at page 290) presents the HITG LN class.


Table C.3: Specification of the HGTE LN class.HGTE Class

Data Object CDC Explanation T M/O/CCommon InformationLoc SPS Local Control Behavior OLocKey SPS Local or remote key OLocSta SPC Remote Control Blocked OOpCntRs INC Resetable operation counter OSettingsGteLoLim ASG Lower limit of gate position (temporary restriction) OGteUpLim ASG Upper limit of gate position (temporary restriction) OIncr ASG Increment of position change for raise / lower com-

mandsO

Status InformationGteBlk SPS Gate is blocked (cannot move from present posi-

tion)O

GteTyp ENS Type of gate OMvm SPS Gate is moving OPosDn SPS Lower end position reached (cannot move further) MPosUp SPS Upper end position reached (cannot move further) MMeasured ValuesFlw MV Calculated water flow through the gate [m3 /s] OControlsBlkCls SPC Block closing of the gate OBlkOpn SPC Block opening of the gate OCls SPC Gate to full closed position OOpn SPC Gate to full open position OPosChg ISC Change gate position to a dedicated position CPosChgIncr BSC Change gate position incrementally C

C.4.5 Mechanical Brake for the Generator Shaft - HMBR

The Table C.5 (at page 290) presents the HMBR LN class.

C.4.6 Speed Monitoring - HSPD

The Table C.6 (at page 291) presents the HSPD LN class.

C.4.7 Hydropower Unit - HUNT

The Table C.7 (at page 292) presents the HUNT LN class.


Table C.4: Specification of the HITG LN class.HITG Class

Data Object CDC Explanation T M/O/CCommon InformationLoc SPS Local Control Behavior OLocKey SPS Local or remote key OLocSta SPC Remote Control Blocked OOpCntRs INC Resetable operation counter OStatus InformationAdrift SPS Adrift level OBrkSpd SPS Braking speed level OGteBlk SPS Gate is blocked (cannot move from present posi-

tion)O

Mvm SPS Gate is moving OPosDn SPS Lower end position reached (cannot move further) MPosStep SPS Step Inst reached OPosUp SPS Upper end position reached (cannot move further) MRep SPS Replenishment level ORRep SPS Reinforced replenishment level OControlsBlkCls SPC Block closing of the gate OBlkOpn SPC Block opening of the gate OCls SPC Gate to full closed position OOpn SPC Gate to full open position O

Table C.5: Specification of the HMBR LN class.HMBR Class

Data Object CDC Explanation T M/O/CCommon InformationLoc SPS Local Control Behavior OLocKey SPS Local or remote key OLocSta SPC Remote Control Blocked OOpCntRs INC Resetable operation counter OStatus InformationBrkOff SPS Brakes are disengaged (off) OBrkOn SPS Brakes are applied (on) OControlsBlkOn SPC Brake blocked OOp SPC Brake on MOpRs SPC Brake off M

C.4.8 Air Compressor - KACP

The Table C.8 (at page 292) presents the KACP LN class.


Table C.6: Specification of the HSPD LN class.HSPD Class

Data Object CDC Explanation T M/O/CSettingsSetSpdBrk ASG Braking allowed setting Inst OSetSpdCrp ASG Creep detection setting OSetSpdExt ASG Excitation breaker operation setting OSetSpdHys ASG Hysteresis limit OSetSpdLft ASG Lift pump operation setting OSetSpdLim ASG Speed limit setpoint OSetSpdLub ASG Lubrication system operation setting Inst OSetSpdOv ASG Over-speed detection setting Inst OSetSpdRb ASG Start angle setting settting OSetSpdStl ASG Standstill detection limit OSetSpdSyn ASG Synchronisation setting OStatus InformationDirRot SPS Direction of rotation OSpdBrk SPS Brake operation allowed Inst OSpdCrp SPS Creep detection OSpdExt SPS Point of operation for excitation system breaker OSpdLft SPS Point of operation for lift pump (high pressure oil

system)O

SpdLim SPS Speed limit Inst reached OSpdLub SPS Point of operation for lubrication system Inst OSpdMovr SPS Mechanical over-speed detection Inst OSpdOvr SPS Over-speed detection Inst OSpdRb SPS Point of setting for start angle for rotor blades OSpdSrc INS Speed sensor Inst fault OSpdSyn SPS Point of operation for synchronising OStndStl SPS Stand still detection OMeasured ValuesSpd MV Rotational speed of the shaft [s-1] CSpdPc MV Rotational speed of the shaft [%] CControlsSpdCrpCtl SPC Creep detection, true = enabled O

C.4.9 Filter - KFIL

The Table C.9 (at page 293) presents the KFIL LN class.

C.4.10 Supervision of Media Flow - SFLW

The Table C.10 (at page 293) presents the SFLW LN class.


Table C.7: Specification of the HUNT LN class.HUNT Class

Data Object CDC Explanation T M/O/CCommon InformationInert INS Inertia of the unit (sum of turbine and generator

inertia) [kgm2]O

Loc SPS Local Control Behavior OLocKey SPS Local or remote key OLocSta SPC Remote Control Blocked OOpCntRs INC Resetable operation counter OSettingsFlwRtg ASG Rated maximum water flow OPwrRtgLim ASG Temporary limitation of power output OSpdLim ASG Maximum allowed rotational speed OVRtgLim ASG Temporary limitation of operating voltage OStatus InformationGridMod ENS Grid mode e.g. the actual grid the unit meets when

CB synchronises to the grid.O

GridOpSt ENS Grid operational status, i.e. if there is a distur-bance or not

O

LimAct SPS Turbine limitation is activated OPaOpnMod SPS Partial opening in condenser mode OStopVlv SPS Stop valve position OUntOpMod ENS Operating mode of the unit MUntOpSt ENS Status of the unit (numbers above 20 are free for

user specific requests).M

ControlsCtlMod SPC Automatic or manual control (true = automatic) MReqSt ENS Requested state from operator (numbers above 20

are free for user specific requests)O

StpOp SPC Step by step operation of sequencer, every stepreleased manually

O

StrNxt SPC Start next step O

Table C.8: Specification of the KACP LN class.KACP Class

Data Object CDC Explanation T M/O/CCommon InformationEEHealth ENS External equipment health OEEName DPL External equipment nameplate OOpTmh INS Operation time OControlsOper DPC Operate air compressor M


Table C.9: Specification of the KFIL LN class.KFIL Class

Data Object CDC Explanation T M/O/CSettingsAlmLevSpt ASG Alarm level set-point OStatus InformationACAlm SPS AC supply failure (fuse or other problem) OFilAlm SPS Filter alarm OFlush SPS Filter flushing OFlushCnt INC Filter flushing counter (reset-able) OMotPro SPS Motor protection tripped OMeasured ValuesDifPresHi MV Differential pressure over the filter OControlsOper SPC Operate filter O

Table C.10: Specification of the SFLW LN class.SFLW Class

Data Object CDC Explanation T M/O/CSettingsActivSet SPS Start action when activation threshold passed set-

pointO

AlmDlTmm ING Delay time for alarm (m) OAlmVal ASG Alarm level setpoint ODeActSet SPS Stop action when activation threshold passed set-

pointO

IndDlTmm ING Delay time for indication (m) OIndSet ASG Indication alarm level setpoint OMedia ENS Type of media being measured OTripDlTm ING Delay time for trip (time unit given by application) OTripVal ASG Trip level setting OStatus InformationActiv SPS Start action when activation threshold passed OAlm SPS Alarm level Inst reached ODeActiv SPS Stop action when activation threshold passed OInd SPS Indication level Inst reached OTrip SPS Trip level Inst reached OMeasured ValuesFlw MV Flow-rate of media [m3/s] O

C.4.11 Circuit Breaker - XCBR

The Table C.11 (at page 294) presents the XCBR LN class.


Table C.11: Specification of the XCBR LN class.XCBR Class

Data Object CDC Explanation T M/O/CStatus InformationCBOpCap INS Circuit breaker operating capability OMaxOpCap INS Circuit breaker operating capability when fully

chargedO

Niche SPS Position of the withdrawable circuit breaker regard-ing the niche: 0 = “Disengaged/Removed” ; 1 =“Engaged/Inserted”

O

POWCap INS Point On Wave switching capability OMetered ValuesSumSwARs BCR Sum of Switched Amperes, resetable OControlsBlkCls CSP Block closing MBlkOpn CSP Block opening MChaMotEna CSP Charger motor enabled MPos CDP Switch position M

C.4.12 Others

The necessary modifications to adapt the existing LN classes to the approach proposedin the sections C.3 and C.8 are not presented here.

C.5 New Logical Node Classes

For improvements in the IEC 61850 standard, this section presents some proposals ofnew LN classes.

The IEC 61850 standard Edition 1.0 states that new LN classes can be created if theexisting ones are not sufficient for the modelling. That new LN classes must be createdaccording to the rules of the “Annex A - Extension rules” of the part IEC 61850-7-4 ofthe standard edition 1.0 [188] (the edition 2.0 does not contain that annex). In spite ofthat fact, the intention is to include the LN classes shown here (or similar ones) in theIEC 61850 standard.

Only have been created DOs needed for this research and the commonly used forphysical elements. New DOs can be added to the new NL classes. That action requiresanalysis of the existing equipment and devices as well as their applications.

The abbreviations of DOs and DAs of the proposed new NLs do not necessarily followthe IEC 61850 standard.

Each LN name shall be composed of the LN prefix, class name, and LN instance


according to IEC 61850-7-2 (and the modifications proposed in this research).For simplicity, the “common information” [116] (independent of the dedicated function

represented by the LN classes) are not shown in the tables.Note that, considering the atual edition of the IEC 61850 standard, it is suppose that

for each LN class of the group “S” an correspondent LN class of the group “T” also isnecessary.

C.5.1 Conventional Panel Board Interface – ICPB

The Table C.12 (at page 295) presents the ICPB LN class.

Table C.12: Specification of the ICPB LN class.ICPB Class

Data Object CDC Explanation T M/O/CStatus InformationBut SPS Status of a panel mounted push button Inst: 0 =

“released” or 1 = “pressed”O

Sw ENS Position of a panel mounted selector switch Inst OControlsBuz SPC Panel monted buzzer (horn): 0 = “turn off” or 1

= “turn on”O

Lamp SPC Panel monted lamp Inst: 0 = “turn off” or 1 =“turn on”

O

C.5.2 Braking Lifting Monkey – KBLM

The Table C.13 (at page 295) presents the KBLM LN class.

Table C.13: Specification of the KBLM LN class.KBLM Class

Data Object CDC Explanation T M/O/CStatus InformationPos DPS Brake lift monkey position: moving; applied; dis-

engaged; invalid.O

ControlsApply SPC Apply the brake lift monkey MBlock SPC Block the brake lift monkey operation ORelease SPC Release the brake lift monkey M


C.5.3 Oil-Water Heat Exchanger – KOWE

The Table C.14 (at page 296) presents the KOWE LN class.

Table C.14: Specification of the KOWE LN class.KOWE Class

Data Object CDC Explanation T M/O/CMeasured ValuesEnvTmp MV Temperature of environment OOilTmpIn MV Oil temperature at the input of the heat exhanger OOilTmpOut MV Oil temperature at the output of the heat exhanger OWaterTmpIn MV Water (secundary cooling medium) temperature at

the input of the heat exhangerO

WaterTmpOut MV Water (secundary cooling medium) temperature atthe output of the heat exhanger

O

C.5.4 Relief Valve – KRLV

The Table C.15 (at page 296) presents the KRLV LN class.

Table C.15: Specification of the KRLV LN class.KRLV Class

Data Object CDC Explanation T M/O/CStatus InformationOp SPS Opetated O

C.5.5 Solenoid Valve – KSVV

The Table C.16 (at page 297) presents the KSVV LN class.

C.5.6 Three Way Valve – KTWV

The Table C.17 (at page 297) presents the KTWV LN class.

C.5.7 Lockout Relay - PLOR

The Table C.18 (at page 297) presents the PLOR LN class.

C.5.8 Timer – RTIM

The Table C.19 (at page 298) presents the RTIM LN class.


Table C.16: Specification of the KSVV LN class.KSVV Class

Data Object CDC Explanation T M/O/CCommon InformationEEHealth ENS External equipment health OEEName DPL External equipment nameplate OOpCnt INS Operation counter OStatus InformationBeh ENS Behaviour MLocKey SPS Local-remote key MPos SPS Position: Closed / Open (or A / B) OControlsMod ENC Mode COp SPC Operate the valve (Closed to Open or A to B) M

Table C.17: Specification of the KTWV LN class.KTWV Class

Data Object CDC Explanation T M/O/CStatus InformationPosA SPS Three way valve in position A (1-3) MPosB SPS Three way valve in position B (2-3) M

Table C.18: Specification of the PLOR LN class.PLOR Class

Data Object CDC Explanation T M/O/CCommon InformationHealth ENS Health COpCntRs INC Resetable operation counter OStatus InformationOp ACT Operate T MControlsMode SPC Mode of operation: 0 = “normal operation” ; 1 =

“test”O

Reset SPC Reset the relay MTrip SPC Command the relay to trip M

C.5.9 Water in Oil Sensor - SWIO

The Table C.20 (at page 298) presents the SWIO LN class.

C.5.10 Contactor - XCON

The Table C.21 (at page 298) presents the XCON LN class.


Table C.19: Specification of the RTIM LN class.RTIM Class

Data Object CDC Explanation T M/O/CCommon InformationOpCntRs INC Resetable operation counter OSettingsReCyc SPG Repeated cycle OTmms ING Time adjustment [ms] MType ENG Timer type: “1 = NOTC - Normally-open, timed-

closed (on-delay)” ; 2 = “NOTO - Normally-open,timed-open (off delay)” ; 3 = “NCTO - Normally-closed, timed-open (on-delay)” ; “4 = NCTC -Normally-closed, timed-closed (off-delay)”

M

Status InformationOp ACT Operate (pulse) T OOut SPS Output (relay contact) MStr SPS Start (timer running) OControlsIn SPC Input (input voltage) M

Table C.20: Specification of the SWIO LN class.SWIO Class

Data Object CDC Explanation T M/O/CSettingsAlmVal ASG Alarm level setting OIndVal ASG Indication level setting OTripVal ASG Trip level setting OStatus InformationAlm SPS Alarm level Inst reached OInd SPS Indication level Inst reached OTrip SPS Trip level Inst reached OMeasured ValuesWaterAct MV Water Activity [%] O

Table C.21: Specification of the XCON LN class.XCON Class

Data Object CDC Explanation T M/O/CSettingsCat ENG Category: AC1, AC2, AC3, AC4, DC1, DC2, DC3,

DC4, DC5.O

Poles ENG Number of poles: 1, 2, 3, or 4. OStatus InformationPos SPC Contactor position M


C.5.11 Miniature Circuit Breaker - XMCB

The Table C.22 (at page 299) presents the XMCB LN class.

Table C.22: Specification of the XMCB LN class.XMCB Class

Data Object CDC Explanation T M/O/CSettingsNI ENG Nominal (rated) current of the circuit breaker = 6

A, 10 A, 13 A, 16 A, 20 A, 25 A, 32 A, 40 A, 50A, 63 A, 80 A, 100 A, and 125 A.

O

Type ENG Type of the circuit breaker: B = “above 3 In up to5 In” ; C = “above 5 In up to 10 In” ; D = “above10 In up to and including 20 In” ; K = “above 8In up to and including 12 In” ; Z = “above 2 Inup to and including 3 In for periods in the order oftens of seconds”

M

Status InformationMag SPS Magnetic (instantaneous) operated OOp SPS Operated (Thermal or/and Magnetic) OPos SPS Circuit breaker position (false = open; true =

closed)M

Ther SPS Thermal (longer-term ) operated O

C.5.12 Motor Control Center Unit - XMCU

The Table C.23 (at page 299) presents the XMCU LN class.

Table C.23: Specification of the XMCU LN class.XMCU Class

Data Object CDC Explanation T M/O/CSettingsType ENG Type of the unit: F = “Feeder” ; C = “Control” MWithdraw SPG Indicate if the unit is withdrawable: 0 = “No” ; 1

= “Yes”O

Status InformationNiche SPS Position of the withdrawable unit regarding the

niche: 0 = “Disengaged/Removed” ; 1 = “En-gaged/Inserted”

O

Test SPS Unit in test position O


C.5.13 Direct Current Converter - ZDCC

The Table C.24 (at page 300) presents the ZDCC LN class.

Table C.24: Specification of the ZDCC LN class.ZDCC Class

Data Object CDC Explanation T M/O/CCommon InformationEEHealth ENS External equipment health OEEName DPL External equipment name plate OOpTmh INS Operation time O

C.5.14 Others

If the idea of to associate one LN class with each equipment and each devices (intro-duced below, in the Section C.8) is utilized, more LN classes are necessary.

C.6 Abbreviations

Some comments and suggestion about abbreviations utilized in the IEC 61850 standardcan be seen in the Chapters 6 “IEC 61850 Standard and Communications” and Chapter 7“Modelling of the Generating Unit” and also in the Appendix A “Abbreviations”.

C.7 Other Comments and Suggestions

This section present some general comments and suggestions.

C.7.1 Conceptual Class Models

It is suggested to follow a pattern to create the names of the classes and attributes ofall conceptual class models presented in the IEC 61850 standard.

C.7.2 Technical Terms

There are minor problems with some terms in the IEC 61850 standard. For example:the term “automation” is ambiguous; the terms “indicator”, “sensor” and “transmitter”are utilized in the standard as synonyms. Thus, a review of main terms would be good.


C.7.3 Missing Information

In the tables of specification of DOs, some of them do not have the group to whichthey belong (common information, status information, controls or settings).

Other points of the standard also miss information.

C.8 Edition 3.0

This section proposes a more drastic change in the IEC 61850 standard. It is onlypossible with a new edition of the standard. Thus, the presented ideas are not applied inthis research.

C.8.1 Elementary Functions

The part 61850-7-510 of the standard [63] states that “Logical Nodes defined in thisdocument are more or less overlapping”, but this is not good for standardization. The LNclasses should have specific functions without overlapping. If there are enough functionsalso it is possible to cover most plants (power plants and substations) and arrangements.

The IEC 61850 standard states that the LN is a “smallest part of a function thatexchanges data” [11], but the practice is different. In the standard there are very complexLN classes that includes a variety of subfunctions.

The LNs specified in the IEC 61850 standard should be elementary functions as smallblocks which could be utilized to build complex functions (standardized groupings ofelementary functions, as templates, also could be defined in the standard). That approachprovides freedom to develop any kind of application functions in a standardized way.Thus, the LN classes must contain only the elementary functions associated to the objectmodelled by the class.

For example, the LNs of primary devices should have only the data attributes thatare intrinsical to the LN. This means that those LNs should have only the characteristics,status, measures and controls that are mandatory to the LN. All the other necessary datashould be appended to the LN using other LNs as, for example, LNs of sensors.

C.8.2 Logical Nodes Classes for Equipment or Devices

Continuing the idea presented in the last subsection, it is proposed to separate the LNclasses into two large groups. The first one contain all LN classes referring to equipmentas, for example: tanks, motors, pumps, turbines, generators, transformers. The secondgroup contain the LN classes referring to devices as, for example: sensors, actuators,


automation devices, protection devices. Those two groups can completely represents anyprocess. A simple example is presented in the next paragraph.

Considere a tank which it is necessary to know the level, temperature and pressure.Following the proposal presented above, all those data should be aggregated, if necessary,utilizing other LN class that model the specific sensors (see Section C.8). The LN classKTNK2 should model only the physical element tank (and its intrinsic characteristics).Thus, in the example, an instance of the LN class KTNK would be utilized together instancesof other LN classes: SLVL, STMP and SPRS (and the respective TLVL, TTMP and TPRS3).

Considering yet the example of the tank. If it is necessary to control the level of thetank, two additional LNs referring to devices are required. A control valve, instance ofthe LN class KVLV, and a controller, for example an instance of the instance of the LNclass FPID.

The approach proposed in this subsection is not applied in the research, because theresult would be very different of the actual edition of the IEC 61850 standard, generatingconfusion. Thus, all modelling are done considering the actual structure and LN classesof the current edition of the standard.

C.8.3 Groups of Logical Nodes

This section discuss the organization of the LNs classes in the standard.In the first edition of the IEC 61850 standard, the groups of LNs were organized by

the main function using one letter for group indication [188]: “A” for automation, “P”for protection, “S” for supervision and monitoring, “I” for interfacing and archiving, etc.And them, in other editions of the standard [116] some LNs were grouped according tothe area of application: “H” for hydroelectric power plants, “E” for thermal power plants,“W” for wind power plants, “D” for distributed energy resources. Those two approacheshave create confusions and, in fact, a disorganization instead of organization.

It is proposed to return to the first approach of the standard, classifying all the LNclasses according to their functions (thus eliminating the LN groups indicators “D”, “E”,“H” and “W”). Naturally, the particular LN classes specifications continue separated bypart of the IEC 61850 standard according to the application. For example, the LN classesspecifics to HPPs belongs to the part IEC 61850-7-410 of the standard4. In that approach,the part IEC 61850-7-4 of the standard should contain only generic LN classes5 that can

2Note that, actually in the IEC 61850 standard [116], the LN class KTNK has the level (LevPct) andthe media volume (Vlm) data only.

3See the Section6.11.4An independent part of the standard is necessary for the classes relating to thermal power plants.5It is not a reference to the LN class GGIO.


used in diverse areas. In addition a new part of the standard, for example “IEC 61850-7-400”, could be created to contain the LN classes specifics for substations.

Besides the groups defined above, the LNs could be classified in four main groups (oneof them with two subgroups):

• Automation;

• Control;

• Monitoring;

• Process:

– equipment;

– devices.

• Protection.

Note that, considering the proposal of the last subsection, the groups “automation”,“protection” and “monitoring” contain only LNs associated to the LN classes of devices.

If it is considered that the primary system includes the sensors and actuators, thegroups could be “primary system” and “secondary system”.

C.8.4 Groups S and T

As introduced in the Chapter 6 “IEC 61850 Standard and Communications”, at theSection 6.11.1, the IEC 61850 standard has two groups of LNs for sensors, transmitters,supervising and monitoring functions [116]. The sensors and transmitters functions belongto the group “T”. The standard states that they have as output a single sampled analoguevalue at a given sampling rate. On the other hand, the supervising and monitoringfunctions belong to the group “S”. Those functions may to convert the sampled values tomeasured values and perform checks against limits.

Another fact, is that the LNs of the group “T” are considered functions of process(field) and the LNs of the group “S” are considered functions of bay (or unit). Finally, alast fact, although it is not clear in the standard, it follows that each LN of the group “S”requires a LN of the group “T”.

That idea of specifics functions of group “T” and group “S” makes sense for CTs andVTs (although in the standard there is no “S” function for those applications...). Maybe(it is supposed that) the idea came from that application. However, for other quantities(other kind of sensors) the approach does not make too much sense. Besides, the majority


of sensors utilized in a HPP provide contacts indicating limits reached. For example, adevice that operates at a given temperature preset value. A few sensors provide thequantity value and, normally, there are some contacts associated. Nowadays, no sensorsprovide sampled values.

Thus, here it is proposed to utilize a single LN for the functions of sensor and super-visor, as function of the process (The “0 - Process” level introduced in the Section 8.3 -see the Figure 8.1). In fact, it is considered that a supervisor is a sensor with a contacts.Those contacts belong to the interface of the sensor. Note that, if sampled values arenecessary that single LN could provide them too.

On the other hand, if it is concluded that the current approach of the IEC 61850standard is really necessary (functions “S” and “T”), a modification also is proposed here.There is no necessity of one LN class “S” for each kind of sensor (LN class “T”’). Asingle complete LN classe for supervision of sensors (group “S”) can be specified. Thatapproach is feasible, because the only difference in the sensor is que quantity. The newproposed LN classe comprises measured values, status information and settings. Duringthe specification of that new LN class, a special care should be taken with the semantics.Similarly, a new single LN class for monitoring could be specified.

Taking advantage of the topic under discussion, it is suggested to use the same patternfor the attributes of the diverse sensors specified in the IEC 61850 standard (LN classesof the group “T”).

C.9 Concluding Remarks

First of all, the proposed amendments presented here are only suggestions. All of themhave to be analyzed in details by expert groups.

The IEC 61850 standard is very complex. The standardization of terms used (ina manner consistent with the definitions) is very important to reduce the difficulty ofunderstanding the standard.

It would be good that the parts of the standard would be understood by themselves,without the need for examples (more comprehensive examples may be put in separateTechnical Reports). The implementation of the concepts presented in the standard shouldbe obvious. Thus, the standard parts would include only normative contents.

A total review of the LN classes would be good. Suggestions for changes and newNL classes must be performed by experts of each specific area. For example, there arevarious types of heat exchangers and the LN classes for such equipment must appropriateconsider the similarities and differences.

In this sense also it is necessary some analises to consider how much each LN class


must be more specific or more generic. For example, a single LN class is enough formodelling pressurized tanks and tanks without pressure? Or it would be better to specifyon LN class for each kind of tank? Specialized classes can be a good solution.

Finally, this appendix presents some constructive critical analysis of the IEC 61850standard from the point of view of the author of this report as user of the standard withoutany external opinion. All ideas presented here have only one purpose: to improve andfacilitate the application of the standard.

Somes analyses and suggestions presented here may not make sense, be irrelevant orbe too difficult to implement (it is hoped that also there are some utile analyses andsuggestions). However, they can serve at least to start some discussions about the themesin the competent work groups of the IEC TC57.

Appendix D

SCL Files

D.1 Introduction

This appendix presents the SCL files of the research.

D.2 Middle Bearings System

Bibliography

[1] Empresa de Pesquisa Energetica - EPE, Anuario Estatıstico de Energia Eletrica2014 - ano base 2013 (Statistical Yearbook of Electricity 2014 - base year 2013),Outubro 2014. Rio de Janeiro - Brasil.

[2] K.-P. Brand, V. Lohmann, and W. Wimmer, Substation Automation Handbook.Bremgarten - Switzerland: Utility Automation Consulting Lohmann - UAC L, 2003.

[3] M. F. Mendes, “Automacao de usinas hidreletricas,” Revista Controle & Instru-mentacao, vol. 185, pp. 52–56, 2013.

[4] J. A. Jardini, Sistemas Digitais para Automacao da Geracao, Transmissao e Dis-tribuicao de Energia Eletrica. Sao Paulo - Brasil: Edicao Universitaria, 1996.

[5] C. A. V. Cardoso, Automacao de Usinas Hidroeletricas - Aplicacao do Padrao UCA- Utility Communication Architecture. Doutorado em Engenharia Eletrica, EscolaPolitecnica, Universidade de Sao Paulo (USP), Sao Paulo - Brasil, 2002.

[6] M. F. Mendes, Proposta de Metodologia e de Modelo para Modernizacoes de Sistemasde Automacao de Unidades Geradoras Hidraulicas de Grande Porte. Doutorado emEngenharia Eletrica, Escola Politecnica, Universidade de Sao Paulo (USP), SaoPaulo - Brasil, Julho 2011.

[7] M. F. Mendes, “Panorama das modernizacoes de sistemas de automacao de unidadesgeradoras hidreletricas no brasil,” in XIV ERIAC - Decimocuarto Encuentro Re-gional Iberoamericano de CIGRE, (Ciudad del Este - Paraguay), Mayo 2011.

[8] M. F. Mendes, “Modernizations of automation systems of hydraulic generating unitsin Brazil,” in 45th Biennial CIGRE Session 2014 - B5-204, (Paris - France), August2014.

[9] M. F. Mendes and J. A. Jardini, “Historia da automacao eletrica e estado da arte,”in 8th CLAGTEE - Latin-American Congress on Electricity Generation and Trans-mission, (Ubatuba - Brazil), October 2009.

Bibliography 308

[10] A. V. Trofimov and A. M. Polyakov, (Free Translation:) Fundamentals of Micro-processor Control Systems for Electrical Installations. Moscow - Russia: NationalResearch University - Moscow Power Engineering Institute, 2014 (book in Russian).

[11] International Electrotechnical Commission - IEC, IEC TR 61850-1 - Communica-tion networks and systems for power utility automation - Part 1: Introduction andoverview, 2013. Edition 2.0.

[12] K.-P. Brand, “The introduction of IEC 61850 and its impact on protection andautomation within substations,” ELECTRA - CIGRE, pp. 21–29, August 2007.

[13] L. Andersson, C. Brunner, and F. Engler, “Substation automation based on IEC61850 with new process-close technologies,” in 2003 IEEE PowerTech, (Bologna -Italy), 2003.

[14] I. De Mesmaeker, P. Rietmann, K.-P. Brand, and P. Reinhardt, “Substation au-tomation based on IEC 61850,” in 6th Regional CIGRE Conference, (Cairo - Egypt),November 2005.

[15] L. Andersson, K.-P. Brand, C. Brunner, and W. Wimmer, “Reliability investigationsfor SA communication architectures based on IEC 61850,” in 2005 IEEE PowerTech,(Saint Petersburg - Russia), June 2005.

[16] A. R. S. Koehler, J. A. S. Stransky, J. C. M. Escobar, L. A. Arriola, H. A. L.Samaniego, M. F. Mendes, J. C. Siqueira, and R. A. R. Galeano, “Criterios adopta-dos para el diseno del control, proteccion y oscilografıa de una subestacion de 1200MVA segun la norma IEC 61850 y dificultades para su implantacion,” in XVI ERIAC- Decimosexto Encuentro Regional Iberoamericano de CIGRE, (Puerto Iguazu - Ar-gentina), Mayo 2015.

[17] International Electrotechnical Commission - IEC, IEC 61850-7-410 - Communica-tion networks and systems for power utility automation - Part 7-410: Basic com-munication structure - Hydroelectric power plants - Communication for monitoringand control, 2012. Edition 2.0.

[18] International Electrotechnical Commission - IEC, IEC 61850-7-410 (WITH-DRAWN) - Communication networks and systems for power utility automation -Part 7-410: Hydroelectric power plants - Communication for monitoring and con-trol, 2007. Edition 1.0.

Bibliography 309

[19] K.-P. Brand, “Hydropower and IEC 61850,” PAC World Magazine, vol. SummerIssue, 2009.

[20] Y. T. Lee, “Information modeling: From design to implementation,” in WMC 1999 -Second World Manufacturing Congress, (Sunderland and Durham - U.K.), pp. 315–321, September 1999.

[21] International Electrotechnical Commission - IEC, IEC 61970-1 - Energy Manage-ment System Application Program Interface (EMS-API) - Part 1: Guidelines andGeneral Requirements, December 2005. Edition 1.0.

[22] Itaipu Binacional, Itaipu Hydroelectric Project: engineering features. Curitiba -Brazil: Itaipu Binacional, 1994.

[23] Itaipu Binacional, Itaipu: Usina Hidreletrica - Projeto: aspectos de Engenharia. Fozdo Iguacu - Brasil: Itaipu Binacional, 2009.

[24] S. L. Dixon and C. A. Hall, Fluid Mechanics and Thermodynamics of Turbomachin-ery. USA: Elsevier Inc., 6th ed., 2010.

[25] M. A. S. Mauro and M. F. Mendes, “Proposta para a modernizacao do sistema deagua pura das unidades geradoras de Itaipu focada na norma IEC 61850,” in SESEP2010 - Seminario del Sector Electrico Paraguayo, (Asuncion - Paraguay), Octubre2010.

[26] I. De Mesmaeker, K.-P. Brand, and C. Brunner, “How to use IEC 61850 in protectionand automation,” ELECTRA - CIGRE, vol. 222, pp. 11–21, October 2005.

[27] J. Orth, “Future power plant control - integrating process and substation automationinto one system,” in Power-Gen Europe 2007, (Madrid - Spain), June 2007.

[28] Electric Power Research Institute - EPRI, The 21st Century Substation Design,September 2010.

[29] A. P. S. Meliopoulos and A. Bose, “The substation of the future: A feasibilitystudy,” tech. rep., Power Systems Engineering Research Center (PSERC), Tempe -USA, October 2010.

[30] M. F. Mendes and J. A. Jardini, “Evolucao dos sistemas de automacaoeletrica: Caminhos das modernizacoes de usinas hidreletricas,” in XIII ERIAC -Decimotercer Encuentro Regional Iberoamericano de CIGRE, (Puerto Iguazu - Ar-gentina), Mayo 2009.

Bibliography 310

[31] S. A. Boyer, Scada: Supervisory Control and Data Acquisition. USA: InternationalSociety of Automation (ISA), 2009.

[32] M. F. Mendes, “Acquiring analog data from existing conventional industrial pan-els,” in V Induscon - Conferencia Internacional de Aplicacoes Industriais IEEE,(Salvador - Brasil), Julho 2002.

[33] P. R. C. de Carvalho, G. O. Calcena, and M. C. Castella, “Sistema de controle,supervisao e aquisicao de dados de Itaipu - Scada/EMS,” in IV Simpase - Simposiode Automacao de Sistemas Eletricos, (Brasılia - Brasil), Outubro 2000.

[34] G. O. Calcena, M. C. Castella, and H. A. L. Duarte, “Automation system in itaipubinacional hydropower - implementation’s challenges,” in V Induscon - ConferenciaInternacional de Aplicacoes Industriais IEEE, (Salvador - Brasil), Julho 2002.

[35] M. F. Mendes, “Sistema digital de supervisao e controle das unidades 9A e 18A deItaipu,” Mecatronica Atual, vol. 29, pp. 32–36, Agosto 2006.

[36] S. Richards, N. Pavaiya, M. Boucherit, P. Ferret, J.-P. Vandeleene, and P. Diemer,“Feedback on in-service deployment of the fully digital substation,” in 45th BiennialCIGRE Session 2014 - B5-110, (Paris - France), August 2014.

[37] L. P. C. da Silva, J. C. Santos, A. L. Cortes, and K. Hidaka, “Optical high volt-age measurement transformer using white light interferometry,” in XXV EncontroNacional de Fısica da Materia Condensada - ENFMC, (Caxambu - Brasil), pp. 204–207, 2002.

[38] M. F. Mendes, “Desvendando o transformador de corrente optico com interferometroSagnac em linha,” in C3N - Congresso da Academia Trinacional de Ciencias, (Fozdo Iguacu - Brasil), Outubro 2008.

[39] I. C. Decker, M. N. Agostini, B. T. Meyer, F. H. Teodoro, D. Dotta, and S. L. Zi-math, “Estudo e avaliacao do desempenho de um prototipo de sistema de medicaofasorial sincronizada instalado no sistema de transmissao da Eletrosul,” in XXSNPTEE - Seminario Nacional de Producao e Transmissao de Energia Eletrica,(Recife - Brasil), Novembro 2009.

[40] K. E. Martin, “Synchrophasor standards development – IEEE C37.118 & IEC61850,” in 44th HICSS - Hawaii International Conference on System Sciences,(Kauai - USA), January 2011.

Bibliography 311

[41] H. V. Pico, J. D. McCalley, A. Angel, R. Leon, and N. J. Castrillon, “Analysis ofvery low frequency oscillations in hydro-dominant power systems using multi-unitmodeling,” IEEE Transactions on Power Systems, vol. 27, pp. 1906–1915, November2012.

[42] R. D. T. Ferreira, B. M. Fontes, H. A. L. Samaniego, M. F. Mendes, and A. Apos-tolov, “Cloud IEC 61850,” in PACW 2013 - PAC World Conference, (Dublin -Hungary), June 2013.

[43] R. D. T. Ferreira, M. F. Mendes, H. A. L. Samaniego, and R. S. de Oliveira, “Archi-tecture and integration of electrical automation systems,” in SBESC 2014 - Brazil-ian Symposium on Computing Systems Engineering, (Manaus - Brazil), pp. 13–18,November 2014.

[44] International Electrotechnical Commission - IEC, IEC 61850-9-1 - Communicationnetworks and systems in substations - Part 9-1: Specific Communication ServiceMapping (SCSM) - Sampled values over serial unidirectional multidrop point topoint link, 2003. Edition 1.0.

[45] L. Andersson, K.-P. Brand, and D. Fuechsle, “Optimized architectures for processbus with IEC 61850-9-2,” in 42nd Biennial CIGRE Session 2008 - B5-101, (Paris -France), August 2008.

[46] M. C. Janssen and A. Apostolov, “IEC 61850 impact on substation design,” in T&D2008 - Transmission and Distribution Conference and Exposition (IEEE/PES),(Chicago - USA), pp. 1–7, April 2008.

[47] D. Tholomier and D. Chatrefou, “IEC 61850 process bus - it is real!,” PAC WorldMagazine, vol. Winter Issue, pp. 48–53, May 2008.

[48] International Electrotechnical Commission - IEC, IEC 61850-8-1 - Communicationnetworks and systems for power utility automation - Part 8-1: Specific communica-tion service mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 9506-2)and to ISO/IEC 8802-3, 2011. Edition 2.0.

[49] International Electrotechnical Commission - IEC, IEC 61850-9-2 - Communicationnetworks and systems for power utility automation - Part 9-2: Specific communica-tion service mapping (SCSM) - Sampled values over ISO/IEC 8802-3, 2011. Edition2.0.

Bibliography 312

[50] M. F. Mendes, “Proposal of methodology for specification and design of iec 61850based power plant automation systems applied to modernizations,” in PACW 2011- PAC World Conference, (Dublin - Ireland), June 2011.

[51] I. De Mesmaeker, P. Hindle, J. Amantegui, J. Ordacgi, and S. Chano, “SC B5protection and automation - current activities and prospects,” ELECTRA - CIGRE,pp. 14–20, February 2008.

[52] L. Andersson, K.-P. Brand, and W. Wimmer, “Some aspects of migration frompresent solutions to SA systems based on the communication standard IEC 61850,”in 2nd International Conference on Integrated Protection, Control and Communi-cation Experience, Benefits and Trends, (New Delhi - India), pp. 24–33, October2001.

[53] L. Hossenlopp and E. Guimond, “IEC 61850: Impact on substation automationproducts and architectures,” in 41st Biennial CIGRE Session 2006 - B5-101, (Paris- France), August 2006.

[54] C. Brunner, “IEC 61850 process connection - a smart solution to connect the primaryequipment to the substation automation system,” in 15th Power Systems Computa-tion Conference - PSCC, (Liege - Belgium), August 2005.

[55] J. Amantegui, A. Cerezo, J. Torres, A. Rivas, and F. Cobelo, “The UniversityCity SAS - first project within Iberdrola Group using IEC 61850 for a completesubstation: Final experiences and future expectations,” in 41st Biennial CIGRESession 2006 - B5-108, (Paris - France), August 2006.

[56] R. E. Mackiewicz, “Overview of IEC 61850 and benefits,” in PSCE - Power SystemsConference & Exposition, (Atlanta - USA), pp. 623–630, October 2006.

[57] L. Hossenlopp, “Engineering perspectives on IEC 61850,” IEEE Power & EnergyMagazine, pp. 45–50, May/June 2007.

[58] K. Schwarz, “Impact of IEC 61850 on system engineering, tools, peopleware, andthe role of the system integrator,” in DistribuTECH - Automation and TechnologyConference for Utilities, (San Diego - USA), February 2007.

[59] American National Standards Institute - ANSI, ANSI/ISA-S5.1-1984 (R 1992),Instrumentation Symbols and Identification, July 1992.

[60] J. B. Mota Junior and M. F. Mendes, “Aplicacao da norma IEC 61850 no sistemade protecao e monitoramento dos mancais das unidades geradoras de Itaipu,” in

Bibliography 313

XII STPC - Decimo Segundo Seminario Tecnico de Protecao e Controle, (Rio deJaneiro - Brasil), novembro 2014.

[61] R. Nicoletti, “Efeitos termicos em mancais segmentados hıbridos: teoria e exper-imento,” mestrado em Engenharia Mecanica, Faculdade de Engenharia Mecanica,Universidade Estadual de Campinas (Unicamp), Campinas - Brasil, Janeiro 1999.

[62] D. M. Pirro and A. A. Wessol, Lubrication Fundamentals. New York - USA: MarcelDekker Inc., 2001.

[63] International Electrotechnical Commission - IEC, IEC TR 61850-7-510 - Communi-cation networks and systems for power utility automation - Part 7-510: Basic com-munication structure - Hydroelectric power plants - Modelling concepts and guide-lines, 2012. Edition 1.0.

[64] M. F. Mendes, “Modernizacoes de sistemas de automacao de usinas hidreletricas:Como especificar?,” in XVI ERIAC - Decimosexto Encuentro Regional Iberoameri-cano de CIGRE, (Puerto Iguazu - Argentina), Mayo 2015.

[65] R. G. Garcıa, E. Gelle, and A. Strohmeier, “The concepts of IEC 61346 applied to asoftware architecture for automation,” tech. rep., Software Engineering Laboratory- Ecole Polytechnique Federale de Lausanne (EPFL), Lausanne - Switzerland, 2004.

[66] H. Dawidczak and H. Englert, “Template based engineering of substation automa-tion systems with the IEC 61850 functional naming concept,” in 16th Power SystemsComputation Conference - PSCC, vol. 1, (Glasgow - Scotland), p. 265, July 2008.

[67] Institute of Electrical and Electronics Engineers - IEEE, IEEE C37.2-2008: Stan-dard for Electrical Power System Device Function Numbers, Acronyms, and ContactDesignations, October 2008. (Revision of IEEE Std C37.2-1996).

[68] Technische Vereinigung der Grosskraftwerksbetreiber - VGB, KKS IdentificationSystem for Power Plants. VGB, 2010.

[69] H. Konigstein, H. Muller, and J. Kaiser, “RDS-PP – transition from the KKS to aninternational standard,” VGB PowerTech, vol. 87, no. 8/2007, pp. 64–72, 2007.

[70] International Electrotechnical Commission - IEC, IEC 81346-1 - Industrial systems,installations and equipment and industrial products - Structuring principles andreference designations - Part 1: Basic rules, July 2009. Edition 1.0.

Bibliography 314

[71] K. Schwarz, “IEC 61850, IEC 61400-25, and IEC 61970: Information models andinformation exchange for electric power systems,” in DistribuTECH - Automationand Technology Conference for Utilities, (Orlando - USA), January 2004.

[72] Electric Power Research Institute - EPRI, Harmonizing the International Elec-trotechnical Commission Common Information Model (CIM) and 61850 - Key toAchieve Smart Grid Interoperability Objectives, May 2010. Project Manager: D.Becker.

[73] L. Hossenlopp, T. Coste, and E. Lambert, “IEC 61850: System configuration includ-ing harmonization with IEC 61970 / IEC 61968,” in 41st Biennial CIGRE Session2006 - B5-102, (Paris - France), August 2006.

[74] E. L. Nunes, “Manutencao centrada em confiabilidade (MCC): Analise da im-plantacao em uma sistematica de manutencao preventiva consolidada,” mestradoem Engenharia de Producao, Centro Tecnologico, Universidade Federal de SantaCatarina (UFSC), Florianopolis - Brasil, Outubro 2001.

[75] R. Lafore, Object-Oriented Programming in C++. Indianapolis - USA: Sams Pub-lishing, 4th ed., 2002.

[76] J. Farrell, Object-Oriented Programming Using C++. Boston - USA: Course Tech-nology, 4th ed., 2009.

[77] S. S. Alhir, Learning UML. Sebastopol - USA: O’Reilly Media, 2003.

[78] R. Baumann and K.-P. Brand, “The standard IEC 61850 - a simple but compre-hensive solution for todays power system requirements,” in 15th Power SystemsComputation Conference - PSCC, (Liege - Belgium), August 2005.

[79] P. Rietmann, M. Hyvarinen, M. Loukkalahti, R. Kirkman, G. Giannuzzi, T. Fortin,and S. A. Kunsmann, “Guidelines for specification and evaluation of substationautomation systems,” ELECTRA - CIGRE, pp. 31–39, August 2007.

[80] A. Apostolov, “Communications in IEC 61850 based substation automation sys-tems,” in Power Systems Conference: Advanced Metering, Protection, Control,Communication, and Distributed Resources 2006 - PS 06, (Clemson - USA), pp. 51–56, March 2006.

[81] Y. Liang and R. H. Campbell, “Understanding and simulating the IEC 61850 stan-dard,” tech. rep., Department of Computer Science - University of Illinois, Urbana- USA, 2008.

Bibliography 315

[82] C. Brunner, J. R. D. Muller, M. Demierre, E. Cottens, and D. Badoux, “Focus onthe application - IEC 61850 experience with third party system configuration tool,”in PACW 2011 - PAC World Conference, (Dublin - Ireland), June 2011.

[83] International Electrotechnical Commission - IEC, IEC 61850-7-1 - Communicationnetworks and systems for power utility automation - Part 7-1: Basic communicationstructure - Principles and models, 2011. Edition 2.0.

[84] International Electrotechnical Commission - IEC, IEC TS 62443-1-1 - Industrialcommunication networks - Network and system security - Part 1-1: Terminology,concepts and models Abstract, July 2009. Edition 1.0.

[85] International Electrotechnical Commission - IEC, IEC 61850-6 - Communicationnetworks and systems for power utility automation - Part 6: Configuration descrip-tion language for communication in electrical substations related to IEDs, 2009.Edition 2.0.

[86] A. S. Tanenbaum and D. J. Wetherall, Computer Networks. Boston, - USA: PearsonEducation, Inc., 2010.

[87] F. Hohlbaum, L. Hossenlopp, and G. Wong, “Concept and first implementationof IEC 61850,” in 40th Biennial CIGRE Session 2004 - B5-110, (Paris - France),August 2004.

[88] K. Schwarz, “Standard IEC 61850 for substation automation and other power systemapplications,” in Power Systems and Communications Infrastructures for the Future,(Beijing - China), September 2002.

[89] S. Laederach, W. Baass, K. P. Brand, and P. Reinhardt, “Experience with IEC61850 in the refurbishment of an important european 380 kV substation,” in 41st

Biennial CIGRE Session 2006 - B5-109, (Paris - France), August 2006.

[90] M. P. Pozzuoli, “Ethernet in substation automation applications - part I,” ElectricityToday, pp. 20–26, June 2007.

[91] M. P. Pozzuoli, “Ethernet in substation automation applications - part II,” Elec-tricity Today, pp. 20–23, July/August 2007.

[92] Institute of Electrical and Electronics Engineers - IEEE, IEEE Std 802.3-2012:IEEE Standard for Ethernet, December 2012. (Revision of IEEE Std 802.3-2008),ISBN: 973-07381-7312-2.

Bibliography 316

[93] B. Kasztenny, B. Le, K. Fodero, and V. Skendzic, “Line current differential pro-tection and the age of Ethernet-based wide-area communications,” in 45th BiennialCIGRE Session 2014 - B5-101, (Paris - France), August 2014.

[94] L. Parziale, D. T. Britt, C. Davis, J. Forrester, W. Liu, C. Matthews, andN. Rosselot, TCP-IP Tutorial and Technical Overview. New York - USA: IBM- International Technical Support Organization, 8th ed., 2006.

[95] G. Leischner and C. Tews, “Security through VLAN segmentation: Isolating andsecuring critical assets without loss of usability,” in 9th Annual Western Power De-livery Automation Conference, (Spokane - USA), April 2007.

[96] International Electrotechnical Commission - IEC, IEC 61508-1 - Functional safety ofelectrical/electronic/programmable electronic safety-related systems - Part 1: Gen-eral requirements, April 2010. Edition 2.0.

[97] International Electrotechnical Commission - IEC, IEC 62439-3 - Industrial commu-nication networks - High availability automation networks - Part 3: Parallel Re-dundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR), June2012. Edition 2.0.

[98] H. Kirrmann, P. Rietmann, and S. Kunsman, “Standard network redundancy usingIEC 62439,” PAC World Magazine, vol. Autumn Issue, pp. 38–44, May 2008.

[99] M. Rentschler and H. Heine, “The parallel redundancy protocol for industrial IPnetworks,” in 2013 IEEE International Conference on Industrial Technology (ICIT),vol. 1, (Cape Town - South Africa), pp. 1404–1409, February 2013.

[100] S. Ward, J. O’Brien, B. Beresh, G. Benmouyal, D. Holstein, J. T. Tengdin,K. Fodero, M. Simon, M. Carden, M. V. V. S. Yalla, T. Tibbals, V. Skendzic,S. Mix, R. Young, T. Sidhu, S. Klein, J. Weiss, A. Apostolov, D.-P. Bui, S. Sciacca,C. Preuss, S. Hodder, and G. Seifert, “Cyber security issues for protective relays,” inIEEE Power Engineering Society General Meeting, (Tampa - USA), pp. 1–8, June2007.

[101] N. Yadav and E. Kapadia, “IP and Ethernet communication technologies andtopologies for IED networks,” in Grid-Interop 2010, (Chicago - USA), November2010.

[102] F. C. B. Farias, P. P. G. F. Garcia, and M. F. Mendes, “Nıveis de seguranca econexoes seguras com sistemas Scada: estudo de caso,” in XVI ERIAC - Decimo-

Bibliography 317

sexto Encuentro Regional Iberoamericano de CIGRE, (Puerto Iguazu - Argentina),Mayo 2015.

[103] M. F. Mendes, “Futuras modernizacoes de sistemas de automacao de unidades ger-adoras no Brasil,” in T&D 2010 Latin America - Transmission and DistributionConference and Exposition (IEEE/PES), (Sao Paulo - Brazil), November 2010.

[104] E. Chikuni and M. Dondo, “Investigating the security of electrical power systems,”in IEEE Africon 2007, (Windhoek - Namıbia), pp. 1–7, September 2007.

[105] J. Tercier and M. Demierr, “Secure your Scada dataflows,” in PACW 2014 - PACWorld Conference, (Zagreb - Croatia), June 2014.

[106] International Electrotechnical Commission - IEC, IEC TS 62351-1 - Power systemsmanagement and associated information exchange - Data and communications secu-rity - Part 1: Communication network and system security - Introduction to securityissues, May 2015. Edition 1.0.

[107] International Electrotechnical Commission - IEC, IEC 61850-5 - Communicationnetworks and systems for power utility automation - Part 5: Communication re-quirements for functions and device models, 2013. Edition 2.0.

[108] Range Commanders Council, U. S. Army White Sands Missile Range, StandardIRIG 200-04: IRIG Serial Time Code Formats, September 2004.

[109] D. L. Mills, Computer Network Time Synchronization: The Network Time Protocolon Earth and in Space. New York - USA: CRC Press, 2010.

[110] J. C. Eidson, Measurement, Control, and Communication Using IEEE 1588: Ad-vances in Industrial Control. New York - USA: Springer-Verlag, 2006.

[111] Institute of Electrical and Electronics Engineers - IEEE, IEEE 1588-2008: Standardfor a Precision Clock Synchronization Protocol for Networked Measurement andControl Systems, January 2008. ISBN: 978-0-7381-5400-8.

[112] International Electrotechnical Commission - IEC, IEC 61588 - Standard for a Pre-cision Clock Synchronization Protocol for Networked Measurement and Control Sys-tems, February 2009. Edition 2.0.

[113] International Electrotechnical Commission - IEC, IEC PAS 61850-9-3 - Communi-cation networks and systems for power utility automation - Part 9-3: Precision timeprotocol profile for power utility automation, 2012. Edition 1.0.

Bibliography 318

[114] International Electrotechnical Commission - IEC, IEC 61850-7-2 - Communicationnetworks and systems for power utility automation - Part 7-2: Basic informationand communication structure - Abstract communication service interface (ACSI),2010. Edition 2.0.

[115] International Electrotechnical Commission - IEC, IEC 61850-4 - Communicationnetworks and systems for power utility automation - Part 4: System and projectmanagement, 2011. Edition 2.0.

[116] International Electrotechnical Commission - IEC, IEC 61850-7-4 - Communicationnetworks and systems for power utility automation - Part 7-4: Basic communicationstructure - Compatible logical node classes and data object classes, 2010. Edition2.0.

[117] International Electrotechnical Commission - IEC, IEC 61850-3 - Communicationnetworks and systems for power utility automation - Part 3: General requirements,2013. Edition 2.0.

[118] M. Kezunovic, T. Djoki, and T. Kosti, “Automated monitoring and control usingnew data integration paradigm,” in 38th HICSS - Hawaii International Conferenceon System Sciences, (Big Island - USA), January 2005.

[119] International Electrotechnical Commission - IEC, Standard IEC 61850-7-2 - Com-munication networks and systems in substations - Part 7-2: Basic communicationstructure for substation and feeder equipment - Abstract communication service in-terface (ACSI), 2003-05. Edition 1.0.

[120] H. Dawidczak, T. Dufaure, and H. Englert, “Compatibility of IEC 61850 edition 1and edition 2 implementations,” in CIRED 2011 - 21st International Conference onElectricity Distribution, (Frankfurt - Germany), June 2011.

[121] International Electrotechnical Commission - IEC, IEC 61850-7-3 - Communicationnetworks and systems for power utility automation - Part 7-3: Basic communicationstructure - Common data classes, 2010. Edition 2.0.

[122] W. Wimmer, “Designing IEC 61850 systems for maintenance, retrofit and exten-sion,” PAC World Magazine, vol. Autumn Issue, pp. 38–44, Spring 2008.

[123] International Electrotechnical Commission - IEC, IEC TS 61850-2 - Communicationnetworks and systems in substations - Part 2: Glossary, 2003. Edition 1.0.

Bibliography 319

[124] International Standards Organization - ISO, ISO 9506-1:2003, Industrial automa-tion systems - Manufacturing Message Specification - Part 1: Service definition,August 2003. Edition 2.

[125] International Standards Organization - ISO, ISO 9506-2:2003, Industrial automa-tion systems - Manufacturing Message Specification - Part 2: Protocol specification,July 2003. Edition 2.

[126] W. Wimmer, “IEC 61850 SCL - more than interoperable data exchange betweenengineering tools,” in 15th Power Systems Computation Conference - PSCC, (Liege- Belgium), August 2005.

[127] S. Holzner, XML - A Beginner’s Guide. Berkeley - USA: Osborne - McGraw-Hill,2009.

[128] Institute of Electrical and Electronics Engineers - IEEE, IEEE C37.239-2010: Stan-dard for Common Format for Event Data Exchange (COMFEDE) for Power Sys-tems, November 2010. (Revision of IEEE Std C37.2-1996).

[129] M. Adamiak, “Overview of the IEEE standard defining a common format for eventdata exchange - COMFEDE - IEEE C37.239-2010,” in Western Protective RelayConference 2011, (Spokane - USA), October 2011.

[130] R. Hughes and C. Brunner, “Experiences of IEC 61850 engineering - designing goodsystems the right way,” in SEAPAC - South East Asia Protection & AutomationConference, (Sydney - Australia), March 2011.

[131] Y. H. Kim, J. Y. Han, Y. J. Lee, Y. H. An, and I. J. Song, “Development of IEC61850 based substation engineering tools with IEC 61850 schema library,” SmartGrid and Renewable Energy, vol. 2, no. 3, pp. 271–277, 2011.

[132] F. Trevisan and I. Habib, “Goose scoope - ferramenta de software livre para acaptura e analise grafica de mensagens goose IEC 61850,” in Seminario del SectorElectrico Paraguayo, Setiembre 2012.

[133] P. Young and J. Stevens, “Consistency and completeness checking of 61850 SCLfiles for compliance and interoperability,” in PACW-A 2014 - PAC World AmericasConference, (Raleigh - USA), September 2014.

[134] C. Brunner, J. Reuter, and R. Hughes, “Choosing and using IEC 61850 SCL files,process and tools correctly throughout the complete SAS lifecycle,” in Study Com-mittee B5 Colloquium 2011, (Lausanne - Switzerland), September 2011.

Bibliography 320

[135] D. Perez, R. Ramos, M. Lopez, and L. Aranda, “Experiencia del PTI-PY con el usode herramientas de ingenierıa IEC 61850,” in SESEP 2010 - Seminario del SectorElectrico Paraguayo, (Asuncion - Paraguay), Octubre 2010.

[136] G. Dogger, G. Tennese, D. Kakoske, and E. MacDonald, “Designing a new IEC61850 substation architecture,” in DistribuTECH - Automation and TechnologyConference for Utilities, (Tampa - USA), March 2010.

[137] N. Nibbio, M. Genier, C. Brunner, E. Cottens, D. Muller, and J. Reuter, “Engineer-ing approach for the end user in IEC 61850 applications,” in 43rd Biennial CIGRESession 2010 - D2/B5-115, (Paris - France), August 2010.

[138] International Electrotechnical Commission - IEC, IEC 61970-301 - Energy Man-agement System Application Program Interface (EMS-API) - Part 301: CommonInformation Model (CIM) Base, December 2013. Edition 5.0.

[139] International Electrotechnical Commission - IEC, IEC 61131-1 - Programmable con-trollers - Part 1: General information, 2003. Edition 2.0.

[140] F. Petruzella, Programmable Logic Controllers. New York - USA: McGraw-HillEducation, 4th ed., 2010.

[141] International Electrotechnical Commission - IEC, IEC 61131-3 - Programmable con-trollers - Part 3: Programming languages, 2013. Edition 3.0.

[142] International Electrotechnical Commission - IEC, IEC 61499-1 - Function blocks -Part 1: Architecture, 2012. Edition 2.0.

[143] J. Asensio, F. Ortuno, M. Damas, and H. Pomares, “Industrial automation program-ming environment with a new translation algorithm among IEC 61131-3 languagesbased on the TC6-XML scheme,” International Journal of Automation and ControlEngineering, vol. 2, May 2013.

[144] T. Bezak, Usage of IEC 61131 and IEC 61499 Standards for Creating DistributedControl Systems. Phd in automation and computer science, Slovak University ofTechnology, Bratislava - Slovak, 2012.

[145] K. Thramboulidis, “IEC 61499 function block model: Facts and fallacies,” IEEEIndustrial Electronics Magazine, vol. 3, pp. 7–23, December 2009.

[146] A. Zoitl and R. Lewis, Modelling Control Systems Using IEC 61499. London - UK:The Institution of Engineering and Technology - IET, 2014.

Bibliography 321

[147] C. W. Yang, V. Vyatkin, N.-K. C. Nair, and J. Chouinard, “Programmable logicfor IEC 61850 logical nodes by means of IEC 61499,” in IEEE 37th InternationalConference of Industrial Electronics Society - IECON 11, (Melbourne - Australia),November 2011.

[148] V. Vlad, C. D. Popa, C. O. Turcu, and C. Buzduga, “Control architecture forsubstation automation systems based on IEC 61850 and IEC 61499 standards,”in Recent Researches in Electrical Engineering, (Lisbon - Portugal), pp. 150–154,October - November 2014.

[149] J. L. P. dos Santos and M. F. Mendes, “Uso de validantes nas funcoes logicas decontrole das unidades geradoras 9A e 18A da usina de Itaipu,” Revista Controle &Instrumentacao, vol. 102, pp. 75–81, Marco 2005.

[150] International Electrotechnical Commission - IEC, IEC 61850-10 - Communicationnetworks and systems for power utility automation - Part 10: Conformance testing,2012. Edition 2.0.

[151] C. Brunner and A. Apostolov, “Functional testing of IEC 61850 based systems,”PAC World Magazine, vol. December Issue, December 2010.

[152] R. Billinton, Power System Reliability Evaluation. New York - USA: Gordon andBreach, 1970.

[153] R. Billinton and R. N. Allan, Reliability Evaluation of Engineering Systems: Con-cepts and Techniques. New York - USA: Springer Science + Business Media, 1992.

[154] C. E. Ebeling, An Introduction to Reliability and Maintainability Engineering. NewYork - USA: Waveland Press, Inc., 2009.

[155] M. Rausand, Reliability of Safety-Critical Systems - Theory and Applications. NewJersey - USA: John Wiley & Sons, Inc., 2014.

[156] A. K. Verma, S. Ajit, and D. R. Karanki, Reliability and Safety Engineering. NewYork - USA: Springer-Verlag, 2010.

[157] International Electrotechnical Commission - IEC, IEC TR 61850-90-4 - Commu-nication networks and systems for power utility automation – Part 90-4: Networkengineering guidelines for substations, 2013. Edition 1.0.

[158] International Electrotechnical Commission - IEC, IEC 60050-192 - Internationalelectrotechnical vocabulary - Part 192: Dependability, 2015. Edition 1.0.

Bibliography 322

[159] M. F. Mendes, “Modernizations of automation systems of hydraulic generating unitsin Brazil,” Revista EletroEvolucao, vol. 80, pp. 65–74, Setembro 2015.

[160] J. Moubray, Reliability Centered Maintenance. New York - USA: Industrial PressInc., 1997.

[161] International Electrotechnical Commission - IEC, IEC 60870-4 - Telecontrol equip-ment and systems. Part 4: Performance requirements, April 1990. Edition 1.0.

[162] L. R. Jonsson, K. Faber, and B. Lundqvist, “The new paradigm in station au-tomation,” in 37th Biennial CIGRE Session 1998 - 34-105, (Paris - France), August1998.

[163] M. F. Mendes, “Proposal of an IEC 61850 based architecture for automation systemsof hydroelectric power plants,” in PACW 2012 - PAC World Conference, (Budapest- Hungary), June 2012.

[164] W. E. Vesely, F. F. Goldberg, N. H. Roberts, and D. F. Haasl, Fault Tree Handbook.Washington - USA: U.S. Nuclear Regulatory Commission, 1981.

[165] A. Gauci and A. Hamel, “Open enterprise architectures for a substation passwordmanagement system,” in Cigre Conference on Power Systems, (Toronto - Canada),October 2009.

[166] P. G. Beaumont, “New trends in protection relays & substation automation sys-tems,” in T&D 2002 Japan - Transmission and Distribution Conference and Expo-sition (IEEE/PES), vol. 1, (Yokohama - Japan), pp. 609–612, October 2002.

[167] M. Golshani, G. A. Taylor, I. Pisica, and P. Ashton, “Laboratory-based deploy-ment and investigation of PMU and openPDC capabilities,” in ACDC 2012 - 10th

IET International Conference on AC and DC Power Transmission, vol. 1, pp. 1–6,December 2012.

[168] International Electrotechnical Commission - IEC, IEC 60870-5-101 - Telecontrolequipment and systems - Part 5-101: Transmission protocols - Companion standardfor basic telecontrol tasks, February 2003. Edition 2.0.

[169] International Electrotechnical Commission - IEC, IEC 60870-5-104 - Telecontrolequipment and systems - Part 5-104: Transmission protocols - Network access forIEC 60870-5-101 using standard transport profiles, June 2006. Edition 2.0.

Bibliography 323

[170] D. Motter, M. F. Mendes, and C. R. Ortiz, “Principais diferencas entre as secoes decomunicacao IEC 60870-5-101 e IEC 60870-5-104 aplicadas em sistemas scada,” inXV ERIAC - Decimo Quinto Encontro Regional Ibero-americano do CIGRE, (Fozdo Iguacu - Brasil), Maio 2013.

[171] F. Trevisan, R. J. Deitos, P. Neis, J. H. Dreher, M. F. Mendes, F. M. Wittmann,and J. V. C. Fracasso, “Uso de tecnicas de Business Intelligence para analise dedados de producao,” in XIII EDAO - Decimo Terceiro Encontro para Debates deAssuntos de Operacao, (Belo Horizonte - Brasil), Novembro 2014.

[172] V. Mayer-Schonberger and K. Cukier, Big Data: A Revolution That Will TransformHow We Live, Work, and Think. Mariner Books - USA: Marcel Dekker Inc., 2014.

[173] D. R. Mauro and K. Schmidt, Essential SNMP. Sebastopol - USA: O’Reilly Media,Inc., 2005.

[174] M. Ben-Ari, Principles of Concurrent and Distributed Programming. EdinburghGate - England: Pearson Education Limited, 2006.

[175] H. A. L. Samaniego and M. F. Mendes, “Uso de redes de Petri para el modelado de laautomatizacion y de la proteccion de una lınea de transmision en 500 kV de la ItaipuBinacional,” in XVI ERIAC - Decimosexto Encuentro Regional Iberoamericano deCIGRE, (Puerto Iguazu - Argentina), Mayo 2015.

[176] M. Kezunovic, J. E. Afonso, S. M. Bamasak, L. B. Tjernberg, T. Bi, P. Crossley,D. G. Eremeev, P. Eguia, L. Fickert, G. Hanna, D. Holstein, H. Ito, K. Kauhaniemi,G. Kovacevic, N. Maseti, P. Oomens, A. C. Pereira, J. F. Pozuelo, and P. Watson,“Education, qualification and continuing professional development of engineers inprotection and control,” tech. rep., CIGRE - WG B5.40, August 2014.

[177] Z. Nedic and A. Nafalski, “Development of a modern power systems laboratory,”World Transactions on Engineering and Technology Education, vol. 12, no. 4,pp. 734–737, 2014.

[178] S. Humphreys, “Substation automation systems in review,” IEEE Computer Appli-cations in Power, vol. 11, pp. 24–30, April 1998.

[179] A. Apostolov, “Workforce training and education: Driving the skill and knowledgedevelopment of internal resources to capitalise on the full capabilities of an iec 61850compliant system,” in IEC 61850 Europe, (Prague - Czech Republic), May 2013.

Bibliography 324

[180] P. J. da Silva, C. A. Viude, W. Aroma, S. I. da Silva Junior, and J. A. Nascimento,“A engenharia nas tradicionais instituicoes de ensino e aprendizagem,” in XXXIVCongresso Brasileiro de Educacao em Engenharia - COBENGE 2006, (Passo Fundo- Brasil), Setembro 2006.

[181] W. A. Bazzo, Introducao A Engenharia - Conceitos, Ferramentas e Comportamen-tos. Florianopolis - Brasil: UFSC, 2006.

[182] M. Kezunovic, “User-friendly, open-system software for teaching protective relayingapplication and design concepts,” IEEE Transactions on Power Systems, vol. 18,pp. 986–992, August 2003.

[183] I. Rocha, “Reengenheirando o ensino de Engenharia no Brasil,” in O Ensino deEngenharia para o Seculo XXI (M. X. Ponte and L. M. Bellesi, eds.), Associacao deUniversidades Amazonicas - UFPA, 1996.

[184] R. T. Pena, F. G. Jota, and C. S. Filho, “A new undergraduate degree in controlengineering,” IEEE Transactions on Education, vol. 44, pp. 399–405, November2001.

[185] N. I. Sarkar, “Teaching computer networking fundamentals - using practical labora-tory exercises,” IEEE Transactions on Education, vol. 49, pp. 285–291, May 2006.

[186] Y. P. Gusev, A. M. Polyakov, and A. V. Trofimov, “Methodological and technicalsupport for training substation automation system,” Energy Security and Conser-vation, vol. 51, May-June 2013.

[187] Electric Power Research Institute - EPRI, Hydro Life Extension ModernizationGuides - Volume 1: Overall Process, December 1999.

[188] International Electrotechnical Commission - IEC, IEC 61850-7-4 - Communicationnetworks and systems in substations - Part 7-4: Basic communication structure forsubstation and feeder equipment - Compatible logical node classes and data classes,2003-05. Edition 1.0.