IN
DEGREE PROJECT ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS
STOCKHOLM SWEDEN 2019,
Power System Protection
Modelling with IEC 61850 and IEC 61499
FRANCISCO DE LIMA
Abstract
The nature of the power system is changing; what was once a clearly defined generation-transmission-distribution-consumer power flow is now shifting towards a distributed infrastructure, with great amounts of vari- able renewable sources in the system. The penetration of alternative en- ergies like solar and wind have represented a game changer for the electric power industry, diminishing the traditional dominance of fossil fuel based sources, and moving towards a more renewable mixture. All this was made possible due to severe climate regulations, both in the European and global framework, as well as ever decreasing installation, operation and maintenance costs for these novel technologies.
However, the penetration of renewable energies brings challenges to the reliability and stability of the power system, which must be tackled accord- ingly. Fortunately, the tools are there, standards like the IEC61850 and IEC61499 were independently designed, and for different purposes. The IEC61850 standard strives for inter-operability and vendor-independence within the substation design field, specifically in regards to the data ob- jects exchanged between the devices. On the other hand, the IEC61499 standard is used for the design of industrial distributed systems.
This report aims to answer the question: is it possible to generate an IEC61499 description which complements an IEC61850 substation specifi- cation? To this end, an IEC61850-IEC61499 interface was created, which takes an IEC61850 substation specification description, as well as a se- ries of configuration files (rules, connections, allocation, parameters) and generates extended descriptions of the substation, as well as a fully oper- ational IEC61499 system specification. This can be directly imported in the 4DIAC tool, and executed to evaluate the performance of the designed protection systems, in a network of distributed or centralized devices.
A series of test cases were evaluated, and the obtained results demon- strate that it is possible to bridge the gap between IEC61850 and IEC61499, thus enabling power system engineers to assess the performance of a cer- tain protection scheme, before actually implementing it in the substation.
This potentially reduces human errors and development times. The in- terface was implemented in Java p.l. and is distributed as an open source project.
Sammanfattning
Kraftsystemets karakt¨ar f¨or¨andras, vilket en g˚ang var ett klart definie- rat generations-kraftn¨at-distributionsn¨at-konsumentfl¨ode, V¨axlar nu mot en distribuerad infrastruktur, med stora m¨angder av f¨ornybara k¨allor i systemet. Intr¨angningen av alternativa energier som sol och vind har re- presenterat en spelv¨axlare f¨or elkraftindustrin, vilket allvarligt minskar den traditionella dominansen av fossila br¨anslebaserade k¨allor och g˚ar mot en mer f¨ornybar blandning. Allt detta gjordes p˚a grund av sv˚ara klimatbest¨ammelser, b˚ade inom den europeiska och globala ramen, samt att minska installationskostnaderna, driftskostnaderna och kostnaderna av underh˚allning, f¨or denna nya teknik.
Inf¨orandet av f¨ornybara energik¨allor medf¨or emellertid allvarliga ut- maningar f¨or kraftsystemets tillf¨orlitlighet och stabilitet, vilket m˚aste
˚atg¨ardas i enlighet med detta. Lyckligtvis finns verktygen d¨ar standarder som IEC61850 och IEC61499 var sj¨alvst¨andigt utformade och f¨or olika
¨
andam˚al. IEC61850-standarden str¨avar efter interoperabilitet och leve- rant¨orsoberoende inom substationsdesignf¨altet, s¨arskilt n¨ar det g¨aller de dataobjekt som utbyts mellan enheterna. ˚A andra sidan anv¨ands IEC61499- standarden f¨or konstruktion av industriella distribuerade system.
Denna rapport syftar till att svara p˚a fr˚agan: ¨ar det m¨ojligt att genere- ra en IEC61499 beskrivning som kompletterar en IEC61850 substations- specifikation? F¨or detta ¨andam˚al, ett IEC61850-IEC61499 gr¨ans-snitt ska- pades, detta tar en IEC61850-specifikationsbeskrivning f¨or stationen, lik- som en grupp konfigurationsfiler (regler, anslutningar, allokering, para- metrar) och genererar ut¨okade beskrivningar av substation samt en helt operativ IEC61499-systemspecifikation, som direkt kan importeras i 4DIAC- verktyget, och exekveras f¨or att utv¨ardera prestanda hos de utformade skyddssystemen, i ett n¨atverk av distribuerade enheter.
En serie testfall utv¨arderades. De erh˚allna resultaten visar att det
¨ar m¨ojligt att ¨overbrygga klyftan mellan IEC61850 och IEC61499 och g¨ora det m¨ojligt f¨or kraftsystemingenj¨orerna att bed¨oma prestanda f¨or ett visst skyddsschema innan de faktiskt implementeras i substationen.
Detta minskar potentiellt m¨anskliga fel och utvecklingstider. Gr¨anssnittet implementerades i Java p.l. och distribueras som ett open source-projekt.
Contents
1 Introduction 11
1.1 Related Work . . . . 12
1.2 Problem Definition . . . . 13
1.3 Objectives . . . . 14
1.4 Motivation . . . . 15
1.5 Overview . . . . 15
2 Literature Review 17 2.1 The IEC61850 standard . . . . 17
2.2 The IEC61499 standard . . . . 19
2.3 Combining IEC61850 with IEC61499 . . . . 23
3 IEC61850-IEC61499 Conversion Methodology 24 3.1 General Workflow . . . . 24
3.2 Substation design . . . . 27
3.3 Configuration files . . . . 28
3.4 Interface Usage . . . . 33
3.4.1 Console execution . . . . 34
3.4.2 Graphical execution . . . . 34
3.5 Interface output . . . . 38
3.5.1 Extended System Specification Description (XSSD) . . . 38
3.5.2 Extended Substation Configuration Description (XSCD) . 38 3.5.3 IEC61499 System Configuration . . . . 38
3.6 Unified model . . . . 39
4 Results 42 4.1 Assumptions and Limitations . . . . 42
4.2 Testing Infrastructures . . . . 42
4.3 Test Case 1: Single Bus Two Bay Substation . . . . 42
4.3.1 Protection Scheme . . . . 42
4.3.2 HMI Process Monitoring . . . . 49
4.4 Test Case 2: Single Bus Three Bay Substation . . . . 52
4.5 Test Case 3: Single Bus Two Bay Substation (MATLAB Field Communication) . . . . 54
4.6 Test Case 4: Single Bus Two Bay Substation (OPAL Full Real Time System) . . . . 58
4.6.1 Physical Setup . . . . 58
4.6.2 Simulink System . . . . 58
4.6.3 Operation . . . . 61
5 Conclusions 65
6 Future Work 67
A RaspberryPI Multinetwork Setup 70
B 4DIAC Custom Data Types 71
C Real Time Linux Installation 73
D Algorithms 74
List of Figures
1 Problem Definition . . . . 13
2 Core Objective . . . . 14
3 Physical and logical devices . . . . 18
4 Data objects and attributes . . . . 19
5 System Architecture . . . . 20
6 Remote communication . . . . 20
7 Function Block . . . . 22
8 Execution Control Chart . . . . 23
9 General Idea . . . . 24
10 Process Diagram . . . . 26
11 Interface Diagram . . . . 27
12 Single Bus Three Bay Substation . . . . 28
13 Single Bus Three Bay Substation (Bay 1 Logical Nodes) . . . . . 29
14 Helinks SSD File Generation . . . . 29
15 Console Help (Usage Instructions) . . . . 35
16 Successful Console Execution . . . . 35
17 Graphical Execution (Main Window) . . . . 35
18 Graphical Execution (Choose Configuration File) . . . . 36
19 Graphical Execution (Step-by-Step Process) . . . . 37
20 Graphical Execution (Visual Allocation) . . . . 37
21 Graphical execution (data types) . . . . 37
22 UML Diagram . . . . 41
23 Test Case 1 - Substation . . . . 44
24 Test Case 1 - System Configuration . . . . 44
25 Test Case 1 - Application Network . . . . 45
26 Test Case 1 - IED2 (Process Level) . . . . 45
27 Test Case 1 - IED2 (Station Level) . . . . 46
28 Test Case 1 - IED1 . . . . 46
29 Test Case 1 - Current Signal . . . . 47
30 Test Case 1- Raspberry FORTE Launch . . . . 47
31 Test Case 1 - Localhost Launch . . . . 48
32 Test Case 1 - Monitor System . . . . 48
33 Test Case 1 - Upstream Bus . . . . 49
34 Test Case 1 - Downstream Bus . . . . 49
35 Test Case 1 - HMI Function . . . . 50
36 Test Case 1 - HMI System Configuration . . . . 51
37 Test Case 1 - HMI Application Network . . . . 51
38 Test Case 1 - Execution Control Diagram . . . . 52
39 Test Case 2 - Substation . . . . 53
40 Single bus three bay system configuration . . . . 53
41 Test Case 2 - Pre-Fault Condition . . . . 54
42 Test Case 2 - Fault Current . . . . 54
43 Test Case 2 - Fault Condition . . . . 55
44 Test Case 3 - Substation . . . . 55
45 Test Case 3 - Sampling and Protection Clocks . . . . 56
46 Test Case 3 - MATLAB Current Transformer . . . . 57
47 Test Case 3 - Fault Condition . . . . 57
48 Test Case 4 - OPAL-RT Target 1 . . . . 59
49 Test Case 4 - Ubuntu 18.04 Real Time . . . . 59
50 Test Case 4 - Simulink Substation . . . . 60
51 Test Case 4 - Simulink Communication . . . . 61
52 Test Case 4 - Wireshark Traffic . . . . 62
53 Test Case 4 - Console Pre-Fault . . . . 62
54 Test Case 4 - 4DIAC Pre-Fault . . . . 63
55 Test Case 4 - Console Fault . . . . 63
56 Test Case 4 - 4DIAC Fault . . . . 64
57 Custom data type creation . . . . 72
58 Linux real time kernel . . . . 74
59 Test Case 1 - Current Simulation . . . . 74
List of Tables
1 General Configuration . . . . 302 Node Allocation Attributes . . . . 33
3 Console Execution Parameters . . . . 34
4 Testing Infrastructures . . . . 43
Listings
1 General Configuration File . . . . 302 Generic Rules File . . . . 31
3 Specific Connections File . . . . 32
4 Logical Node Allocation File . . . . 32
5 Parameters and Settings File . . . . 34
6 Extended System Specification Description . . . . 38
7 Extended Substation Configuration Description . . . . 39
8 IEC61499 System Configuration . . . . 40
9 RaspberryPI Multinetwork Setup . . . . 71
10 Transformer 4DIAC service function block . . . . 76
11 Transformer current simulation . . . . 77
12 MATLAB Server Current Simulation . . . . 78
13 IHMI Execution Monitoring Server (Part 1 of 2) . . . . 79
14 IHMI Execution Monitoring Server (Part 2 of 2) . . . . 80
15 Asynchronous UDP Communication . . . . 81
Acronyms
CDC Common Data Class.
CID Configured IED Description.
CT Current Transformer.
DA Data Attribute.
DCOM Distributed Component Object Model.
DO Data Object.
ECC Execution Control Chart.
FB Function Block.
FORTE 4DIAC Runtime Environment.
GOOSE Generic Object Oriented System Event.
GPIO General Purpose Input Output.
GPO General Purpose Output.
GRUB Grand Unified Bootloader.
GUI Graphical User Interface.
HMI Human Machine Interface.
ICD IED Capability Description.
IED Intelligent Electronic Device.
LAN Local Area Network.
LN Logical Node.
MMS Manufacturing Message Specification.
MU Merging Unit.
NIC Network Interface Controller.
OPC OLE for Process Control.
OS Operating System.
RTOS Real Time Operating System.
RTU Remote Terminal Unit.
SCADA Supervisory Control and Data Acquisition.
SCD Substation Configuration Description.
SCL Substation Configuration Language.
SIFB Service Interface Function Block.
SSD System Specification Description.
SSH Secure Shell Protocol.
SV Sampled Values.
UCA Utility Communication Architecture.
UML Unified Modeling Language.
USART Universal Synchronous Asynchronous Receiver Transmitter.
XML Extended Markup Language.
XSCD Extended Substation Configuration Description.
XSSD Extended System Specification Description.
Acknowledgements
To God, for giving me the required strength and resillience to persevere even during the toughest times.
To KTH, for providing me with 2 years of free and world class superior education, and for allowing me to receive classes from the best professors and with the best teammates one could ask for.
To my tutors, Tin Rabuzin and Yiming Wu, for being a crucial part of this project and for being my mentors throughout these last months. The realization of this work would have been impossible without their numerous and accurate contributions.
To my family, for constantly supporting me; not only throughout the devel- opment of this Master Thesis, but also in every aspect of my life.
To my wife Ana Cristina, for being always by my side, in the good times and the bad, and for being a fundamental part of my life.
To my grandmother Mar´ıa Lucila, may her teachings always light my path, as they have so far. May her soul rest in peace.
1 Introduction
Nowadays, substation relay protection algorithms are mainly closed-source soft- ware supplied by vendors and tied to their respective hardware platforms, which are tethered to protection devices designed by different equipment manufactur- ers. Companies like Siemens, ABB, Harris and many others, usually create their own protection logics and algorithms, and use them in a close-source fashion, meaning that they are the sole developers and proprietors of their own software, and no third party can use them without proper licensing rights, or alter them (even with proper licensing). Even though standards like the IEC61850 have standardized the information flow by specifying the different data objects and attributes that can be received/transmitted by the involved Intelligent Elec- tronic Device (IED) within the substation, the electric power industry is yet to make the leap towards a fully interoperable digital substation standard, in which functions and algorithms are open-source, and information exchange is common to all parties. The current state of affairs has caused that the digital substation has not yet been able to reach its maximal potential, due to the level of secrecy and lack of interoperability that still exists in the industry at this moment.
On the other hand, there have been some noticeable developments in the field of industrial automation in recent years. Distributed devices have become increasingly more common and available to engineers, and communication be- tween them has become more streamlined, efficient and reliable. The IEC61499 standard supplies the industry with a well structured tool to unify the way in which information flows within a system (both locally and remotely between the devices), by offering an Extended Markup Language (XML) documentation describing the disposition of the different elements within a system, and how these elements interact and communicate between one and other. This standard has also gained popularity in the academic field, and many engineering students and hobbyists have relied on it in order to develop academic projects and all sorts of other applications.
The main purpose of this project is to bridge the gap between the IEC61850 digital substation specification standard, and the IEC61499 industrial automa- tion and distributed systems standard. The goal is to design a new methodol- ogy in which a standard substation specification is augmented with information about the internal modelling of the substation and the connections between its protection elements, while at the same time producing an additional document which can be directly imported into a testing framework so as to assess the per- formance of the proposed protection scheme. To achieve this goal, an interface will be created, which will be able to automatically translate all the nuances and complexities of the IEC61850 standard, take a System Specification Description (SSD) file, and process it in order to generate an IEC61499 system specification, which can be imported into already available IEC61499 compliant tools (4DIAC in this case) and implement it in an infrastructure of distributed devices, with the purpose of emulating the different IED in a certain substation. The benefit of such approach is that the output can be directly used for testing, which al- lows engineers to assess their proposed protection schemes before implementing them in the field, therefore increasing security and reliability, while at the same time reducing the man-hours required for the design.
1.1 Related Work
Other authors have also proposed similar methodologies as the one discussed in this report. In an article written by: Zhabelova, Yang, Vyatkin, Etherden and Christoffersson; it is demonstrated that, through the combination of IEC61850 and IEC61499 standards, it is possible to design a platform that can yield a flexible automation scheme, thus simultaneously reducing vendor dependency and costs [1].
Vlad, Popa, Turcu and Budzuga propose a control system architecture for substation automation systems, which combines IEC61499 (for the implemen- tation of the control logic) and IEC61850 (for communications and information exchange). The authors discuss about the convenience of the IEC61499 standard and its success in the field of industrial automation and control systems, since it has allowed to comprehensively describe the behaviour of different function blocks in a graphical manner [2].
In another publication, Vlad and colleagues present a solution for combining an IEC61850 specification with an actual implementation in IEC61499, where the IEC61499 devices are used for describing the automation logic. The authors point out that the IEC61499 standard is a convenient way in which to develop modular control applications, since it allows for the creation of function blocks that perform control applications. Among some of their benefits, the following features can be highlighted: modularity, reconfigurability and reusability of code [3].
Higgins, Vyatkin, Nair and Schwarz investigate the integration between the IEC61850 and IEC61499 standards, and propose a new approach based on a distributed architecture, instead of the traditional centralized scheme. The au- thors bring out the increasing obsolescence of the current architecture of the electric power system, which was designed for 20th century performance stan- dards. Distributed energy resources, low-cost generators, increased vulnerabil- ity to terrorist attacks and ever increasing performance regulations for electrical service providers have demanded an update in the current architecture of the power system. In their article, the authors highlight the necessity for devices that can detect changes and appropriately reconfigure. One way to achieve this is to implement relays and controllers on IEC61499 compliant platforms, providing increased relevance to the IEC61850 compliance [4].
Yang, Zhabelova, Vyatkin and Nair discuss about the numerous benefits of integrating the aforementioned standards, since it is foreseen that this combina- tion will decrease fault-clearing times while at the same time reduce the number of direct copper connections between the devices and the field equipment. The idea is to take advantage of the efficient IEC61850 communication standard, and combine it with the interoperability of the IEC61499 standard. The distributed protection infrastructure that the authors propose depend on strict time per- formance requirements. Even though the IEC61850 standard contemplates fast peer-to-peer communication, it doesn’t make mention to the actual implemen- tation of the function blocks, which is why the IEC61499 standard can be used to solve this problem, offering a precise way in which to describe the behaviour of the logical nodes and their control algorithms [5].
1.2 Problem Definition
Figure 1 shows the current state of affairs (on the top), as well as the implemen- tation that this master thesis project is trying to achieve (on the bottom), in regards to the way in which digital substations are designed and implemented.
In the figure, the red circles correspond to vendor-dependent elements, while the green circles are open-source.
The current implementation (top) requires specialized personnel which is able to handle proprietary tools (ABB, Siemens, etc.) in order to generate a series of IED Capability Description (ICD) files. Then, another engineering group has to design the topology of the substation in an IEC61850 compliant software, utilizing the provided ICD files to implement the different IED in the system, and then connect these devices as required. A series of Configured IED Description (CID) files is thereafter exported, and then another group will use proprietary tools to program the different relays in the substation (these devices are, again, vendor-dependent). It can be seen that the current workflow is highly dependent on proprietary software and equipment, and requires a great deal of specialized personnel to handle each of the closed-source tools. This will become increasingly more complicated when there are devices of multiple vendors in the substation.
In this thesis, a newly proposed approach is presented (bottom). As usual, a group will specify the layout of the substation as in the original approach, but in this case, the system specification tool will be exclusively used to design the topology, since there will be an interface which will take care of the internal and external connections. In addition, this group will not consider the hardware;
the interface will export an IEC61499 file from the IEC61850 specification, and this file can in turn be imported into an IEC61499 compliant tool (like 4DIAC) in order to distribute the solution to the field devices, which don’t necessarily have to be tethered to a particular vendor. Moreover, this solution is almost entirely open source (a proprietary IEC61850 tool is still being used to create the substation).
Figure 1: Problem Definition
1.3 Objectives
The following list states the main goals and objectives of this thesis project:
1. Perform a literature review on the subject of IEC61499 application for power system protection and automation.
2. Configure a set of tools for IEC61499 application development (4DIAC, FORTE) and IEC61850 system integrator tool (Helinks).
3. Create an IEC61850 model of a simple substation.
4. Develop a tool to map the IEC61850 description of a substation to IEC61499 application description.
5. Import the mapped IEC61499 application to the software platform and then deploy to the target hardware.
6. Test the performance of the application with simulations and test cases.
7. Demonstrate the interchangeability of protection function blocks.
Put simply, Figure 2 shows the core objective of the developed solution. A standard description of a substation will be processed in order to achieve an augmented version of such description, which will also specify the way in which the different protection elements of the substation are internally connected.
Concretely, an interface will take an IEC61850 System Specification Description (SSD) file, and output an Extended System Specification Description (XSSD) as well as an Extended Substation Configuration Description (XSCD). The first file essentially describes the internal model and behaviour of the substation, whereas the second one describes its specific configuration, while at the same time providing a full IEC61499 system (which can be used for testing in a centralized or decentralized infrastructure) as well as the actual implementations (algorithms) of the different logical nodes in such system.
Interface Substation
Augmented Model of Substation
Figure 2: Core Objective
1.4 Motivation
In the near future, an important part of society’s electrical consumption will be covered by renewable energies (wind, solar, etc.), and these variable renewable sources of energy usually behave as a negative demand, which will present a big challenge for the system’s adequacy and reliability in the future [6]. Renewable energies, while presenting very promising scenarios in terms of reduced CO2 and NOx emissions, also present a major challenge for all the system operators worldwide [7]. The high penetration of variable and intermittent sources intro- duces an increased level of unpredictability [8], and this of course means that substations of the future must be conditioned to manage sudden power varia- tions and a potentially increased number of failures and abnormal conditions, with rapidly changing topologies, due to sudden equipment disconnections. For this reason, digital substations and more standardized protection schemes will be key for smoothing the transition from a predominantly fossil fuel based power system, to a potentially 100% renewable electrical system. This is because, among other things, these new breed of digital substation devices enable the possibility for self-reconfiguration and remote setting calibration, which gives the substation an unprecedented level of flexibility and adaptability to different topological configurations and rapidly varying load conditions.
1.5 Overview
The present document is divided into three main parts: the Literature Review section, IEC61850-IEC61499 Interface section, and the Results section.
The Literature Review section aims to deliver a background of the work other authors and organizations have developed in the topic. This part will gather relevant information and previous experience in the fields of IEC61850 and IEC61499 standards, as well as outlining the commercial-off-the-shelf tools and software which will be used in the present project to create, edit and test the developed systems and applications.
The IEC61850-IEC61499 Interface section thoroughly describes how the interface works and how it is meant to be operated, it is subdivided in the following parts:
• General workflow: describing the main purpose of the interface, as well as its expected inputs, outputs and intermediate products. The benefits of the interface compared to the current digital substation design workflow are also underlined in this subsection.
• Unified model: explaining the relationships between the different classes present in the interface’s architecture. This section displays and describes the Unified Modeling Language (UML) diagram of the interface. The UML is a graphical representation of how a certain system works, it visu- ally represents the internal interactions that take place between its classes or components [9].
• Substation design: indicating the way in which the involved engineers should design and construct their substation, using the Helinks (STS Sys- tem Integrator) tool [10], or any other commercially available IEC61850 substation design software. This section will also specify the required
nomenclature and naming convention that the different substation’s bays must adhere to in order for the interface to properly parse the substation description and generate a functioning system.
• Configuration files: describing all the input files that the users must cre- ate/edit in order for the interface to function as expected. At the current development state of the interface, the majority of the files must be edited manually (i.e. by means of a commercial text editor), but the interface also supports some additional tools and aids in order to graphically design the most complex files.
• Interface usage: instructing the users on how the interface can be oper- ated. There are essentially two ways to use the interface: by console (the user must use the command line terminal to specify some execution pa- rameters, and the filesystem location of the main configuration file), and using a GUI. An additional graphical interface is also available for the user to visually edit the configuration files, and execute the conversion algorithms in the intended sequence.
• Interface output: detailing the files which are expected to be generated by the interface, provided that its execution was successful. This section also shows extracts of each of these files, in order to showcase what is expected in terms of their contents.
The Results section presents a series of testing scenarios, with the inten- tion of assessing if the interface is capable of generating properly functioning systems out of standard substation description files. With this in mind, this section will present a series of benchmark substation topologies, attempting to generate IEC61499 systems from IEC61850 digital substations, carrying differ- ent degrees of complexities. This section will present all the simulation scripts and underlying signals which are involved in each substation scheme, as well as a group of figures and screen captures, documenting the performance of the interface-generated IEC61499 system in the 4DIAC tool.
The report also contains a Conclusions section, stating the main findings and results of the present work, as well as a Future Work section, in which the author underlines all the aspects that were not fully covered in the thesis project, while at the same time pointing out potential fixes or improvements that could be carried on in order to make the interface more robust, efficient and reliable.
Finally, the report features an Appendix chapter, intended to describe some additional aspects that are not directly related to the development of the in- terface, but that played a role that is worth mentioning, both in terms of pro- gramming and system testing (RaspberryPI multi-network setup, creation of IEC61499 custom data type structures, installation of Linux real-time kernel, etc).
2 Literature Review
This section will explore some essential concepts and definitions that the reader must get herself familiar with in order to better grasp the core sections of this report. There is a subsection exploring the IEC61850 standard, a subsection exploring the IEC61499 standard, and a final subsection describing the benefits of combining these two standards.
2.1 The IEC61850 standard
The automation of the electrical power system can be traced back to the 1930’s.
Even during that period of time, a primitive infrastructure was already in place that enabled system operators to obtain the status of field devices, while at the same time allowing the possibility to issue control commands from the control center. All this was accomplished through the plain telephone network, and it represented the first step towards a centralized control scheme [11].
A few years later, in the 1960’s, remote terminal devices started to appear within the electric power system framework, and an underlying digital commu- nication infrastructure progressively began to replace the plain old telephone system, increasing the reliability, bandwidth and data transfer rates from the field to the control system and back. This represented the first step towards the institution of the SCADA system that is nowadays present in the modern control systems around the world.
A couple of decades later, in the late 1980’s, the UCA was designed and put in place. It encompassed data models, protocols and several other fundamental definitions, which ultimately resulted in the creation of the IEC61850 protocol [11].
The IEC61850 standard defines three main components or functional blocks:
the Physical Device, the Logical Device, and the Logical Node (LN).
The physical device is the actual, physical component where the logical de- vices are contained in. It can either be an IED, an RTU or any other device that is to be located in the field, interacting with the process variables (cur- rent, voltage, etc.) through its input/output ports, or communicating with the control center.
The logical devices are contained within the physical device, and they rep- resent a unit which is intended to perform a certain high-level function (line protection, measurement report, etc); each logical device contains a group of logical nodes, connected in a specific way, so as to achieve the desired behaviour.
The logical node is the heart of the IEC61850 standard, it is the core, atomic unit out of which the different power system protection and measurement func- tions can be created. The engineers in charge of the substation design will connect the different LN in a specific way, with the purpose of achieving the desired protection scheme. Each logical node can be implemented in a partic- ular way by the different electrical equipment manufacturing companies (the internal algorithms, to this date, are designed in a proprietary way by every manufacturer), but the pieces of information to be transmitted between logi- cal nodes of different devices, must be strictly followed in order to achieve the desired interoperability, which is one of the main purposes of the standard.
The relationship between the physical devices, logical devices and logical nodes is depicted in Figure 3. As shown in the graph, the physical device
contains the logical devices, each of which contains the logical nodes.
Figure 3: Physical and logical devices
Each logical node can be interfaced through pieces of information known as Data Object (DO), and each of these data objects is associated to a particu- lar Common Data Class (CDC). One of the main strengths of the IEC61850 standard is the fact that these CDC are independent of any underlying pro- tocol [11]. The data classes are in turn composed by data attributes (DA), which correspond to the smallest pieces of information presented in the stan- dard (i.e. floats, integers, strings, date-times, etc). Figure 4 shows the data object-attribute hierarchy.
Moreover, the IEC61850 standard features an ecosystem of documents, aimed to describe the substation and protection systems. The IED Capability De- scription (ICD), Configured IED Description (CID), System Specification De- scription (SSD) and Substation Configuration Description (SCD) files are all documents written in the Substation Configuration Language (SCL), which is an XML representation of the digital substation, its devices and their corre- sponding interactions.
The architecture of a traditional IEC61850 substation is depicted in Figure 5.
It is essentially comprised of three information levels, and two network buses.
The information levels are:
• Process level: where the current/voltage signal acquisition takes place.
It is the lowest level, which directly interacts with the secondaries of the current and voltage transformers, interfacing the physical system and cap- turing the process variables. The captured process values are sent to the upstream protective devices through the SV protocol.
• Bay level: where the main protection and measurement functions take place. The IED on this level horizontally exchange information between one and other, traditionally using a connection-less scheme, described in the GOOSE protocol.
Figure 4: Data objects and attributes
• Station level: where the information is reported from the substation to the SCADA control center, and viceversa. It is the gateway between the remote Human Machine Interface (HMI) and the substation.
The IEDs on the process and bay levels are connected through the so called Process Bus, whereas the IED on the bay level exchange information with the ones in the station level through the Station Bus. Figure 5 shows the standard IEC61850 system architecture.
Communication between the control center and the gateway RTU can take place through any of the commonly used application layer protocols (DNP3, MODBUS, IEC60870, etc). However, there is also the possibility to use the widely popular OPC standard, through its DCOM protocol, in order to exchange information between the SCADA and the field, provided that the gateway RTU is capable of running an OPC server [12]. Figure 6 shows the previously de- scribed case.
2.2 The IEC61499 standard
The IEC61499 standard describes a series of procedures, methods and data structures which can be used to design and build embedded industrial and con- trol automation systems. It has quickly become adopted as one of the favorite standards for the development of distributed applications, featuring multiple devices which can communicate between each other, provided that they are connected to the same physical network.
The development of the IEC61499 standard began in the year 1992. Since then, the main goal has been to develop a standard that not only describes the way in which the different devices within a system are connected and how the
Figure 5: System Architecture
Figure 6: Remote communication
information flows, but also one that accurately specifies the internal behaviour of the different function blocks.
The Function Block (FB) is the building block and main component of the IEC61499 ecosystem. It represents: “The basic unit for encapsulating and reusing Intellectual Property (IP = know-how)” [13]. Put in programming terms, the FB resembles a Class and all the internal pieces of information cor- respond to the Properties. A similar scenario takes place within the IEC61850 standard, where a LN class is composed by a group of information elements (the data objects), which are in turn composed by data attributes. Being aware of this resemblance, it is only natural to strive for compliance and interoperability
between these two standards, which will potentially lead to more stable and better performing developments.
There are essentially three types of FB described in the IEC61499 standard:
basic, composite and service interface.
• Basic FB: the basic function block is the workhorse of the standard, it consists on a series of states, as well as a group of events which control the execution flow of the block, traversing between the different states accord- ingly. Each state has an associated algorithm, defined in one of the follow- ing programming languages (Ladder Diagram, Structured Text, Function Block Diagram). These languages are described in the IEC61131-3 stan- dard, which in many ways is the predecessor of IEC61499. The problem with the original IEC61131-3 standard is that it doesn’t support state transitions, and it is confined to just one sequential execution algorithm.
The team behind the development of the IEC61499 standard realized the necessity for an improvement of the existing IEC61131-3, and therefore included state transitions and a multi-algorithm structure which dramat- ically increased the number of possible functionalities that the original IEC61131-3 had to offer, therefore enabling developers to create more ad- vanced and robust distributed systems.
• Composite FB: the composite function block is formed by a group of basic function blocks, properly positioned and connected to carry on a particular function. All of this can be accomplished without writing any additional algorithm, since the composite FB aggregates the behaviors of its internal blocks. This is a convenient way of scaling code and reusing functionalities in a modular fashion.
• Service Interface FB: even though the majority of the functions can be implemented by programming a certain basic FB, some functionalities cannot be directly implemented through the IEC61131-3 available lan- guages. Operations like filesystem access and any other special hardware interfacing routines (including the design of custom communication pro- tocols and related network tasks) must be implemented directly in the underlying programming language (C++ in 4DIAC’s case) and compiled as an external module in the target host. These units of information are the so called Service Interface Function Blocks (SIFB), and they comple- ment all the tasks that cannot be directly performed by the previously described function block types.
Figure 7 shows a basic function block. The lower section of the function block interfaces the input and output data objects, and holds all the algorithms present in the FB. The upper section of the function block interfaces the input and output events, and it holds the ECC diagram which dictates the execution flow of the different algorithms. Note that there are some connections between the input and output events, with the input and output data elements (respec- tively). A connection between an input event and an input data indicates that, whenever the event is trigger, the associated data point will be consumed by the function block. A connection between an output event and an output data indicates that, whenever the output data is changed, the associated event will be triggered.
Figure 7: Function Block
The Execution Control Chart (ECC) is a graphical representation of the different potential execution paths that a function block’s internal program can take. It represents a state machine, in which every state potentially triggers an associated algorithm and an event, which can be connected to other function blocks in order to signal its execution. Figure 8 shows the ECC of a potential IEC61499 implementation of an IEC61850 PTOC (protection time overcurrent) logical node. In this example, an incoming current sample will trigger the REQ event, and will update the state of the machine from the Standby state to the Accumulation state, which will immediately execute the Accumulate algorithm, which in turn will square the most recent current sample and add it to the previously accumulated value Ia = Ia + Is2. After a while, the RMS event will be triggered, and the state machine will move to the Calculation state, which will trigger the RMS calculation routine Irms=p(Ia/N ), and then clear the accumulated current value Ia = 0. Finally, The calculated Irms will be compared against a threshold or an inverse time-current curve (depending on the complexity of the PTOC block), and a trigger signal will be issued if the conditions are met.
Any IEC61499 system must be specified through an XML file, describing the structure, function blocks, connections and exchanges that take place within the target system. Creation of this file by using a regular text editor can be a daunting task for the user, since she must constantly verify the structure presented by the standard, and follow it thoroughly so that her designed system is fully compatible with the IEC61499 standard. The amount of details that must be considered while designing the system by hand are too many, and thus the chances of incurring in mistakes will increase dramatically. In order to facilitate the utilization of the IEC61499 standard, software developers have created a set of tools, intended to graphically aid the user during system creation time. One of the most popular computer applications used to visually design IEC61499 systems is the 4DIAC tool [14]. As stated in their webpage: “Eclipse 4diac provides an open source infrastructure for distributed industrial process measurement and control systems based on the IEC 61499 standard... it defines
Figure 8: Execution Control Chart
a domain specific modeling language for developing distributed industrial control solutions. IEC61499 extends IEC61131-1 by improving the encapsulation of software components for increased re-usability, providing a vendor independent format, and simplifying support for controller to controller communication” [14].
In other words, 4DIAC provides its base of users the possibility to conveniently design IEC61499 systems in a graphical manner.
The IEC61499 standard is now a mature framework for the streamlined design of distributed systems. Its ease of use and extensive documentation have increased its popularity in the academic and industrial fields alike, while at the same time enabling developers to create software and tools that interact with the standard.
2.3 Combining IEC61850 with IEC61499
Many authors have already noticed the great potential and benefits that could come from the integration of the IEC61850 and IEC61499 standards. “The logical nodes in IEC61850 are only defined as an interface describing character- istics of objects and functions in a power system. The functionality behind the interface is not part of the IEC61850 standard. However in order to fully con- figure an IED this specific functionality must be defined as well as the SCL part.
Since IEC61499 is highly suitable for this functionality description a logical step would be to integrate and harmonize the configuration of IED using IEC61850 and IEC61499” [15].
Moreover, the IEC TR 61850-90-11 standard proposes a way in which IEC61850 basic types can be mapped to IEC61131-3, which shows a similar approach as the one presented in this report (in this thesis project, the map- ping is performed against the IEC61499 standard) [16].
The interoperability offered by IEC61850 and the operational and functional capabilities of IEC61499 can be put together to yield a powerful configuration of any electrical substation, describing both its external structure and information exchange, as well as its internal structure and functional operation.
3 IEC61850-IEC61499 Conversion Methodology
This section aims to thoroughly describe the proposed IEC61850-IEC61499 con- version methodology, and the way in which the designed interface can be used in order to obtain the augmented model of the substation. Firstly, a general workflow of the conversion process will be described, followed by a UML dia- gram explaining the relationships between the different modules and classes of the interface (the most important ones). Secondly, a substation design chapter will describe the proposed way in which the electrical components should be connected, but above all, the naming conventions that need to be used for the interface to work correctly. Then, a section on configuration files will specify the required structure of these documents, and will present some examples. Lastly, a chapter on interface usage will be presented, where a reader is instructed on how to use the software, and what kind of files are expected to be generated from the interface.
3.1 General Workflow
Figure 9 presents the general workflow of the interface: a group of engineers may use any IEC61850 compliant tool (e.g. Helinks STS System Integrator) to carry on the substation design as usual, ensuring to make the appropriate connections between the different bays and equipment, and placing all the sub- station components within the desired voltage levels. After the substation has been properly designed, the export functionality of the Helinks tool can be used to write the SSD file to the filesystem. After the SSD file has been exported, the IEC61850-IEC61499 interface will be used to generate an XSCD file (extended SCD file) and an IEC61499 system configuration file: the former file (XSCD) is used as the final documentation for the substation, the latter (IEC61499) can be analyzed, parsed and executed by means of the 4DIAC environment. The interface also generates and reads an intermediary XSSD file (extended SSD file) which is an augmented format of the System Specification Description, and internally used by the interface to produce the previously mentioned end output files.
Figure 9: General Idea
Now that the general, high-level functionality of the interface has been de-
scribed, a more detailed (but still general) description of the interface can be found in Figure 10. As mentioned before, an engineer or group of engineers takes the desired substation and implements it in the Helinks tool. Once the intended design has been achieved, the export functionality of the aforementioned tool is used to write the SSD file to the specified location in the file system. Once this is done, the users must also design a set of standard configuration files which will indicate to the interface, among other things: (1) the logical node allocation in each IED present in the substation, (2) the settings and parame- ters of each logical node, (3) generic connection rules between the different LN, (4) specific GOOSE exchanges between the different IED in the substation, (5) some general configuration parameters (author, organization, etc).
As stated earlier, the interface will take the SSD and standard configuration files and export an XSSD,XSCD and IEC61499 files. The IEC61499 is particu- larly handy, since it can be directly used to create a distributed application in order to test the current substation design and assess if it complies with safety and performance requirements. The 4DIAC tool can be used to create a project out of the exported IEC61499 file, and the user will be able to verify that the devices are properly connected in the corresponding network, and that the log- ical nodes are mapped and communicate according to the specifications of the standard configuration file.
The 4DIAC tool can also be used to deploy the system interactions and be- haviour to the network of distributed devices; in short, it is a two step process:
(1) All the function blocks and data types to be included must be compiled to the proper target architectures (e.g. ARM7, x86-64, etc.) and then manually distribute the resulting 4DIAC Runtime Environment (FORTE) to the corre- sponing devices, (2) Use 4DIAC to transfer to the target devices the particular parameters and interconnections that will take place between the different func- tion blocks of the system.
Additional to the standard configuration and SSD files, a library of IEC61850 function blocks implemented in IEC61499 is also required to perform tests in the 4DIAC environment. These blocks can be programmed directly in the 4DIAC tool, they require an Execution Control Chart (ECC) diagram (describing the different states of the block and the way in which the different transitions be- tween the states can take place), and a programming logic described in any of the languages contained in the IEC61131-3 standard (ladder diagram, structured text, etc), or even in the C++ programming language (displayed as AnyText in the editor). The exact implementation of these blocks is out of the scope of this report, but some of them (PTOC, PTRC, XCBR, etc) were implemented so as to achieve some basic functionality, therefore allowing for the developed interface to generate systems that could actually be tested.
Notice that the previously described process (Figure 10) also shows the way in which the workflow would have been if there was no interface whatsoever.
In the portrayed scenario, a group of engineers would have needed to use the 4DIAC tool in order to manually place and connect each and every one of the logical nodes and devices present in the substation. The real contribution of the proposed interface is that it will considerably cut down the time that the user(s) will have to spend in the 4DIAC environment, which will now be only used to verify and deploy the application to the distributed devices. The interface is also meant to reduce the number of potential human errors that a manual design might carry along.
Figure 10: Process Diagram
Figure 11 presents a more detailed diagram of the stages of the interface. As shown in the figure, the software consists of two clearly separated phases, which can even be executed by two different groups of engineers:
• The substation design group will work on the IEC61850 design of the sub- station, the rules file (which specifies the generic connections between the different logical nodes) and the connections file (specifying the substation specific exchanges). This group will then use the SSD-XSSD functionality of the interface to export the augmented substation specification descrip- tion.
• The allocation and parameters group will import the previously exported XSSD file, and then design the allocation file (mapping all of the dif- ferent logical nodes with the desired IED) as well as the parameters file (which will contain the different settings and configurations of the existing logical nodes). Once the interface is aware of these three files, the engi- neer(s) can use the XSSD-XSCD functionality to produce the Extended Substation Configuration Description (XSCD) file and the IEC61499 sys- tem specification file.
Notice that, regardless of the engineering group which is utilizing the in- terface, the configuration file is required for any of the program stages, and is passed as the sole argument of the interface at command line execution. The configuration file points to all the other input and output files, and contains general information about the substation and export options. The idea of re- questing a single configuration file is to reduce the number of references that the user(s) will need to make at run-time.
A more detailed description of the interface will be displayed in Section 3.6, where a UML diagram will show the relationships between the different classes present in the interface. Figure 11 is a higher level representation of the diagram depicted in Figure 22.
Figure 11: Interface Diagram
3.2 Substation design
The first thing that needs to be done before using the interface is to design and create the substation. For this, the engineer(s) will use the Helinks tool (or any other IEC61850 compliant software), as usual making sure to establish solid connections between the different equipment involved, and ensuring that all devices are properly located within the desired bay and voltage level. Figure 12 shows a single bus, three bay substation, which will be used as an example throughout the current section.
Note: All the substation topologies presented in this report were created through the STS System Integrator tool (Helinks). This does not mean that the user is forced to use this software, since any IEC61850 compliant suite should generate valid substation specification descriptions, which will be compliant with the designed interface.
Note that, in order for the interface to properly apply the specified rules to the corresponding bay types and voltage levels, the user must name the different bays in the substation according to a certain nomenclature. The bay type nomenclature and available substation voltage levels must be specified within the Substation element of the Generic Rules configuration file. This document (along with the rest of the configuration files), is described in Section 3.3, specifically under Listing 2.
Now that the substation has been properly designed, and that the different bay types have been named accordingly, it is time to specify the different logical nodes and protection functions that will be included in each bay. In order to do this, the user must double click on the point-down arrow next to the bay name. This will open a new tab which will display some default logical devices and logical nodes already in place, corresponding to the primary and secondary equipment present in the bay. At this point, the user must add a New Function block, in which she will include all the additional logical nodes that will conform the desired protection and/or measuring logic.
In a traditional substation design process using the Helinks tool, the user(s)
