18th Power Systems Computation Conference Wroclaw, Poland – August 18-22, 2014

Model-Driven Engineering applied to Smart GridAutomation using IEC 61850 and IEC 61499

Filip Andren, Thomas StrasserAIT Austrian Institute of Technology

Energy DepartmentVienna, Austria

Email: {filip.andren, thomas.strasser}@ait.ac.at

Wolfgang KastnerInstitute of Computer Aided Automation

Vienna University of TechnologyVienna, Austria

Email: k@auto.tuwien.ac.at

Abstract—In order to guarantee a sustainable electric energysupply the power systems domain is currently in a transformationphase. Renewable energy sources have to be installed on a largescale causing a more complex operation of the power distributiongrids due its stochastic behavior. Advanced automation andinformation technology approaches, concepts and algorithms arebeing applied to operate such complex systems. Interoperabilityand standardized interfaces are important topics which haveto be considered realizing a Smart Grid. A standard-compliantformal approach for the modeling of power utility automationand control applications is missing up to now. This papertherefore introduces a novel approach using the well-knownmodel-driven engineering concept from computer science forthe development of Smart Grid automation applications. Thismethod focuses on the usage of the power utility interoperabilityapproach IEC 61850 and the distributed automation referencemodel IEC 61499 as basis for the proposed modeling concept.An overview of the engineering method, corresponding transfor-mation rules as well as an explanatory example are provided.

I. INTRODUCTION

The power systems domain is currently on the verge ofa profound change. The large-scale integration of DistributedEnergy Resources (DER) from renewable sources challengesthe already tight hosting capacities in the power distributiongrids today [1], [2]. Automation and control systems usingadvanced Information and Communication (ICT) concepts andarchitectures are seen as key elements of the future SmartGrids to enable a more efficient use of the already existinginfrastructure [3]. The future power distribution grids haveto support a higher amount of flexibility and adaptabilityto varying demands. Because of its complexity, the futuresystem will not only be a matter of grid components andrelated topology, but also the automation and control systemsas well as the corresponding application(s) have to be takeninto account making todays approaches smarter [4].

However, a comprehensive information model for SmartGrid application development covering the physical grid, thecommunication infrastructure as well as control and applica-tion issues is missing up to now. In addition, no correspondingdesign method, development procedure nor necessary tool sup-port system is able to integrate all these different views duringthe design and validation phase of Smart Grid automationapplications today [5], [6].

The most promising solutions for the standardized infor-mation exchange in Smart Grids are based on the well known

domain standards Common Information Model (CIM) andpower utility automation (i.e., IEC 61850) introduced by theInternational Electrotechnical Commission (IEC), TechnicalCommittee TC 57 [3], [5]. The later one which is of interestfor the work presented in this paper was originally developedfor substation automation but has been enlarged over the lastyears to cover also power utility equipment and DER services[7]. Designed to address mainly interoperability issues andstandardized software interface, IEC 61850 does not cover theimplementation of automation and protection functions. Theyhave to be implemented using other approaches.

One very interesting concept from the automation sectorhas also been introduced by the IEC, the IEC 61499 refer-ence model. It describes an automation standard especiallydeveloped for the design of distributed industrial process,measurement and control systems using function blocks. Dueto it’s distributed nature it provides a very good basis toserve as implementation concept for IEC 61850 functions.There are already several publications available discussing theintegration and harmonization of IEC 61850 and IEC 61499for the domain of Smart Grids [5], [8], [9], [10].

The main aim of this paper is to introduce and discuss amodel-driven design approach to integrate the IEC 61499 au-tomation approach with the IEC 61850 power utility standardto improve and partially automate the engineering process ofSmart Grid automation applications. The presented approachcontinues an integration of the two standards where model-driven development is used for model transformations [5].

The rest of the paper is organized as follows: Section IIgives a brief overview about currently ongoing activities re-lated to power utility automation as well as important IEC stan-dards. The model-driven engineering concept using IEC 61850and IEC 61499 is introduced in Section III followed by thediscussion of model-transformation rules in Section IV. Theproposed engineering concept is covered in Section V andexplained on a selected use case in Section VI. Finally, thepaper is summarized and concluded in Section VII.

II. POWER UTILITY AUTOMATION AND STANDARDS

A. Active Power Distribution Grids

Up until now the electric energy infrastructure was charac-terized by a centralized architecture. Electricity was generatedby large-scale power plants—denoted as bulk generation (e.g.,

18th Power Systems Computation Conference Wroclaw, Poland – August 18-22, 2014

nuclear, hydro, fossil-fuel power plants)—and transported overlong distances by the transmission system to regions and cities.Followed by a series of step-down transformers to mediumand low voltage levels the electric energy was distributed tothe customers (i.e., distribution system). Such a system has ahierarchical structure and is characterized by a unidirectionalpower flow from the bulk generators to the customers [1].

In order to build a sustainable electric energy supply andthe corresponding infrastructure to prevent a global warmingduring the next decades, Renewable Energy Sources (RES)have to be integrated in todays power system on a largescale. Such generators are usually installed in the mediumand low-voltage distribution grids in a decentralized way (e.g.,small photovoltaic systems, hydro power stations or windturbines). With the integration of such DERs the topologyof the electric energy supply infrastructure changes denotedin the literature as Smart Grid [1], [2], [4]. Still the wholearchitecture has a hierarchical nature but it has to cope withfluctuating distributed generation causing a bidirectional powerflow between the distribution grid and the consumers whichnow act also as electricity producers (denoted in the literaturealso as prosumers) [11].

Traditionally, the automation degree in power distributiongrids are quite low compared to the transmission system.Medium-voltage distribution grids, secondary substations andlarger Distributed Generators (DG) can be controlled by dis-tribution control centers but especially the operation of low-voltage grids is still carried out manually today. Due to thelarge scale integration of DER components and the futurepenetration of electric vehicles as well as decentralized storagesystems the operation of the aforementioned grids becomesmore complex [1], [4].

With the availability of powerful Supervisory Control andData Acquisition systems (SCADA), corresponding remotecontrol possibilities/devices as well as installation of automaticmetering systems (i.e., advanced sensor and measurementequipment) a higher degree of automation may be expectedalso on the low-voltage level during the next years. The currenttrend is also to increase the connectivity between all thesecomponents (e.g., generators, loads, storage, transmission anddistribution lines, substations, on-load tap change transformers,measurement devices, smart meters) through a powerful com-munication network and corresponding automation infrastruc-ture. All these measures allow a more intelligent monitoringand optimization of the Smart Grid [1], [2], [4], [12].

B. Important Smart Grid ICT and Automation Standards

An important issue related to Smart Grid automation isstandardization to fulfill interoperability requirements. In thiscontext on international level the IEC is one of the mostimportant players. In order to cover Smart Grid topics ithas setup the “Strategic Group on Smart Grid (SG 3)”. Oneimportant outcome of this activity was the development ofthe “IEC Smart Grid Standardization Roadmap” [13] wherethe following main standards for the realization of SmartGrids are suggested: (i) IEC TR 62357 Seamless IntegrationReference Architecture (SIA) using service-oriented concepts,(ii) IEC 61970/61968 Common Information Model (CIM) fortransmission and distribution systems, (iii) IEC 61850 power

utility automation, (iv) IEC 62351 security, (v) IEC 62056meter data exchange, and (vi) IEC 61508 functional safety.

Besides the IEC Smart Grids activities several other ini-tiatives can be observed. The most important once are the“US NIST Framework and Roadmap for Smart Grids Interop-erability Standards” [14], the “DKE German standardizationroadmap for Smart Grids” [15], as well as the “IEEE Guidefor Smart Grid Interoperability of Energy Technology andInformation Technology Operation with the Electric PowerSystem (EPS), End-Use Applications, and Loads” [16].

As mentioned above power utility automation is covered byIEC 61850, developed by IEC TC 57. The main purpose ofthis interoperability standard is to define a common modelingapproach for the data exchange in power systems. To do thisit defines several data models for modeling, configuration aswell as high-level communication services for information ex-change over Ethernet. The main components—Logical Nodes(LN)—are used to model power system components (e.g.,switches, transformers, inverters) as well as power systemfunctions (e.g., measurement, protection, voltage control). TheLNs are contained in so-called Intelligent Electronic Devices(IED), providing a kind of object-oriented modeling approach.For configuration of IEDs the XML-based Substation Config-uration Language (SCL) is defined using XML schema.

The implementation of the corresponding automation andprotection functions is not part of IEC 61850. Therefore, othersolutions have to be used. For example, the German DKEroadmap suggests the automation standards IEC 61131 [17]and IEC 61499 [18] for this task. IEC 61131 was especiallydeveloped for centralized Programmable Logic Controllers(PLC) whereas IEC 61499 provides a reference architecturefor distributed automation and control systems. IEC 61499has been defined as a methodology for specifying open dis-tributed industrial process, measurement and control systemsand therefore providing a very good basis for the implemen-tation of IEC 61850 functions. Automation applications canbe modeled in a hardware independent manner using FunctionBlocks (FB). Moreover, the automation hardware can also berepresented by IEC 61499 elements (i.e., devices, resourcesand communication network). An interesting aspect of thisdistributed automation standard is its event-driven executionmodel. Different concepts are defined for structuring complexautomation problems [19], [20].

Summarizing, for the design of Smart Grid control func-tions and applications as well as their implementation incomplex automation solutions proper engineering processesand corresponding tools are missing up to now from an ICTpoint of view. A formalized and standard-compliant design andimplementation process for Smart Grid automation systems isrequired. Below such an approach is presented.

III. MODEL-DRIVEN ENGINEERING CONCEPT

Model-Driven Engineering (MDE) is a concept from com-puter science where the modeling of an application is put infocus [21], [22]. Once the model definition is accomplished itis transformed into other models or source code is generated.The main idea is to increase consistency and to minimizeerrors. One of the core components of MDE is the modeltransformation, which is defined by a set of rules. This can

18th Power Systems Computation Conference Wroclaw, Poland – August 18-22, 2014

either be model-to-model transformations or model-to-texttransformations, also called code generation. Usually morethan one transformation is needed, e.g., a model-to-modeltransformation followed by code generation. To automaticallyexecute model- transformations some kind of tool support isneeded. Such tools can also check for possible errors.

Applying the MDE approach to the IEC 61850 andIEC 61499 standards enables new engineering possibilitiescompared to standard power utility automation. IEC 61850introduced SCL which makes it easier to configure IEDs.Nonetheless, since IEC 61850 does not specify how thefunctions of the LNs are implemented, such a configurationcannot be considered as complete. With an MDE approachbetween IEC 61850 and IEC 61499 not only the communica-tion can be configured, but also the functionality of the LNscan be automatically configured, generated and deployed. AnMDE approach also provides better simulation and validationpossibilities of the application [5].

The main goal of the present work is to introduce amodel-driven approach to transform IEC 61850 models intoIEC 61499 automation models. In order to do this the platformindependent modeling approach of IEC 61499 is used. Asdescribed in [18], [23] IEC 61499 can effectively be used in anMDE approach, where the design of the IEC 61499 applicationis done in a platform independent way. The platform specificimplementation is done once the application is mapped to thehardware specification (i.e., IEC 61499 devices and resources).This approach is depicted in Fig. 1.

Thus any hardware independent parts of the IEC 61850model should be mapped to the IEC 61499 application andhardware dependent parts should be mapped to IEC 61499devices and resources. In this paper hardware independenceis defined as a model which can be generalized to multipleplatforms. Both IEC 61850 and IEC 61499 contain domainspecific names and expressions. To improve the readability anyexpressions related to IEC 61850 are emphasized as element850,and expressions related to IEC 61499 are emphasized aselement499 in the rest of the paper.

Resource

A

Resource

B

Resource

C

Communication Interface

Process Interface

Resource

A

Resource

B

Resource

C

Communication Interface

Process Interface

Device 1

Application 1

Application 2

Device 2

Communication Interface

Process Interface

Scheduling function

MN

POWERL

INK_MN

CN1

POWERL

INK_IO

OUT

SUBL

IN

PUBL

CN2

POWERL

INK_IO

Resource C

Application 3App. 4

Communication Network

Application Model

System Model

Resource Model

Controlled Process

FB1

FB5 FB6

FB4FB2 FB3

Fig. 1. Models defined in IEC 61499 [18], [24].

IV. MODEL-TRANSFORMATION

A model-transformation can be defined as an automaticgeneration of one or more target models from one or moresource models. The heart of the model- transformation isthe transformation rule, which describe how one or moreconstructs of the source meta-model can be transformed intoone or more constructs of the target meta-model. A set oftransformation rules can be combined into a transformationdefinition describing how the source models are mapped totarget models [25].

IEC 61850-6 defines the Substation Configuration Lan-guage (SCL) for the configuration of IEC 61850 devices. SCLis defined using XML schema. IEC 61499-2 also providesa specification of its elements in form of Document TypeDefinitions (DTD). The DTD specification are defined in XMLformat to allow exchange of models between software tools.These formal definitions can be used as meta-models forIEC 61850 and IEC 61499 respectively. Thus it is possibleto define transformation rules between objects in IEC 61850to elements in IEC 61499. For completeness the bi-directionaltransformation should be possible, however this paper onlycovers the transformation from IEC 61850 to IEC 61499.

A. Mapping of Artifacts

The main object in IEC 61850 is the LN850 (LNode inFig. 2) since it act as a connector between the different models.Summarized, the following three models with different objectsare of importance:

• Functional model: a logical model containing powerconducting equipment (e.g., transformer) as well asvirtual functions (e.g., voltage level)

• Product model: provides models of the IEDs850 andtheir LNs850 and data objects,

• Communication model: models the available accesspoints850 and subnetworks850.

IEC 61499 also defines several models for different mod-eling objectives. Some of these models are shown in Fig. 1and can be summarized as follows [18]:

• System model: a collection of devices499 and their con-nections with each other through network segments499

and links499,

Fig. 2. SCL object model as defined in IEC 61850-6 [26].

18th Power Systems Computation Conference Wroclaw, Poland – August 18-22, 2014

• Device model: models a hardware device which con-sists of one or more resources499,

• Resource model: a resource499 is considered as a func-tional unit and contains one ore more applications499

or parts of it,

• Application model: consists of a FB network499, i.e.,FBs499 connected to each other.

A mapping between IEC 61850 and IEC 61499 artifactsis seen in Table I. The corresponding transformation rules aredescribed below and are summarized in Fig. 3.

1) Functional to Application Model: The functional modelis intended to represent the functional structure of a substa-tion850. As depicted in Fig. 2 each object of the functionalmodel contains LNs850. Thus the function described by the LN850

and its IED850 is related to a part of the substation850 [26].

Since the objects of the functional model is not directlyrelated to power system objects (i.e, hardware devices) they aremapped to the application499. Thus the platform independenceis maintained. The hierarchical structure of the functionalmodel (e.g., substation850 containing voltage levels850 containingLNs850) is realized in IEC 61499 using subapplications499. Asshown in Fig. 2 the LN850 is part of both the functionalmodel as well as the product model, i.e., the LN850 is thelowest hierarchy level of the functional model. Thus thesubapplication499 representing the LN850 contains the productmodel of the LN850.

Connections499 between the subapplications499 correspond tothe information exchange between the LNs850. Each LN850 canbe seen as an interface description, which makes a mapping toadapters499 a suitable option [27]. This mapping is describedin more detail below.

2) Product to Resource/Device Model: The product modelcovers the modeling of the IEDs850 used in the power system.Each IED850 can be seen as a hardware device containingsoftware functions. Models of these software functions are

Substation

-name = nSub

System

-name = nSub

Application

-name = nSub

IED

-name = nIED

Device

-name = nIED

Logical Device

-inst = iLD

Resource

-name = iLD

LNode

-inst = i

Adapter

-name = lC

Subapplication

-name = lC + i

AccessPoint

-name = nAP

NetworkSegment

-name = nSubN-type = tSubN

Link

-commResource = iLD-segmentName = nSunN

LNodeType

-lnClass = lC

Server

SubNetwork

-name = nSubN-type = tSubN

Substation2System

LNode2Subapp

LNodeType2Adapter

IED2Device

AccessPoint2Link

SubNetwork2NetworkSegment

LogicalDevice2Resource

IEC 61850 IEC 61499

Transformation rule

Fig. 3. Transformation definition between IEC 61850 and IEC 61499

TABLE I. MAPPING BETWEEN IEC 61850 AND IEC 61499 ARTIFACTS

IEC 61850 IEC 61499Substation System & Application

IED DeviceLogical Device Resource

LN Subapplication & AdapterCommunication Network segments & Links

Abstract CommunicationService Interface (ACSI)

SIFB(client/server and publisher/subscriber)

not covered by IEC 61850, however their interfaces are rep-resented in form of LNs850. Thus the product model defines ahierarchical description of the IEDs850, i.e., each IED850 containsone or more servers850, containing one or more logical devices(LDevice850), and so on ending with the data of the LN850, aspresented in Fig. 2 [26].

Following this MDE approach of IEC 61499, as describedin Section III all hardware independent parts should be part ofthe application499, whereas any parts related to the hardwareshould be covered by the resource499 or the device499. In theprevious section the LN850 was defined to be part of the appli-cation499 as it describes a hardware independent functionality.The same applies to the data850 and therefore it is also part ofthe application499.

The IED850 is a hardware device which makes a mappingto the device499 natural. Each IED850 contains one ore moreLDevices850 which are mapped to resources499. The servers850

are a special case since they need to be mapped to ServiceInterface Function Blocks499. This mapping is explained inmore detail below.

3) Communication to System Model: The communicationmodel of IEC 61850 defines logically possible connections be-tween IEDs850, i.e., which IEDs850 can connect with each other.This is described using subnetworks850 and access points850,defining where an IED850 is connected to a subnetwork850 [26].

The system model in IEC 61499 has a similar purpose,since it describes a collection of devices499 connected vialinks499 to network segments499 [18]. Thus a logical mappingis made from subnetworks850 to network segments499 and fromaccess points850 to links499.

Even if IEC 61499 provide some possibilities for networkmodeling it still lacks in detail. For instance link properties likedelay or statistical package drops cannot be directly modeled.For such purposes other models are needed.

B. Logical Nodes to Subapplications/Adapters

As described in Section IV-A1 each LN850 of an IEC 61850model is mapped to two different objects in the IEC 61499model, a subapplication499 and an adapter499. The subappli-cation499 is intended to include the functional model of theLN850, and the adapter499 models the data interface. The useof subapplications499 makes it possible to model Smart Gridapplications in different hierarchies. Furthermore, adapters499

have the advantage that they can define a bi-directional con-nection499, including both data and event connections.

When a LN850 is mapped to an adapter499, each datainput/output of the adapter499 has the data type matching aCommon Data Class850 (CDC) specified in IEC 61850. ACDC850 is a complex structure made up of simple data types,

18th Power Systems Computation Conference Wroclaw, Poland – August 18-22, 2014

arrays or other structures. In IEC 61499 user defined structureddata types499 can also be used to model a CDC850. Since aCDC850 can consist of other structures the result may be anested structured data type499 in IEC 61499 [27].

In order to define the event interface499 of adapters499

the communication services defined by the IEC 61850 arestudied since they define how the data of LNs850 are accessed.For example all communication services related to pollingcan be mapped to a request (REQ), confirm (CNF) pattern inIEC 61499. Fig. 4 shows how the measurement LN850 MMXU[28] is modeled as an adapter499.

MMXU Adapter

REQ EVENT – Request from ClientCNF Confirmation from Server – EVENT

TotWTotal Active Power – MV

TotVArTotal Reactive Power – MV

Data object

name

Comon

data classExplanation T M/O/C

TotW MV Total Active Power O

TotVAr MV Total Reactive Power O

MMXU class

Measured Values

Fig. 4. Mapping of IEC 61850 LN MMXU into IEC 61499 adapter.

The usage of adapters499 simplifies the overall structure ofthe application499, but it does not directly specify any commu-nication link. The actual specification of the communicationconfiguration is done when the application499 is mapped to aspecific resource499 [27].

C. Communication Patterns

As stated above on of the main goals of IEC 61499was the support for developing distributed control systems.Thus communication is an important topic in such a setup.However, since IEC 61499 is a generic standard it does notprovide specific communication means for this interaction.Generally, SIFBs are intended to provide an interface betweenthe application499 and the actual communication service of theresource499. Moreover, two generic communication patterns aredefined in the standard, representing bi-directional transactionswith a client/server model and uni-directional transactionswith a publisher/subscriber model [18]. Since the two modelsare generic it is also possible to map other communicationprotocols onto these patterns [29].

IEC 61850 defines a number of Abstract CommunicationService Interfaces (ACSI), dedicated to different purposes,e.g., some follow a typical polling pattern whereas other areintended for reporting. Principally a client/server model is usedfor the communication, i.e., a client needs to connect to aserver before it can use any of its services. From an applicationpoint-of-view this may however not always be the case.

ACSIs in IEC 61850 defined for polling purposes (e.g.,GetDataValues, SetDataValues) are mapped to the clien-t/server model of IEC 61499, since a poll is instantiated by arequest (REQ) from the client and answered with a response(CNF) from the server. A number of ACSIs can also be mappedto a publisher/subscriber model. These are mainly (i) reports,where the server sends a collection of data to a specificclient when something changes, (ii) sampled-values, where the

server publishes values to the client using real-time constraints,and (iii) GOOSE messages, publishing of real-time substationevents, e.g., protection related events.

V. ENGINEERING PROCESS

The mappings between IEC 61850 and IEC 61499 de-scribed in Section IV define how each object of IEC 61850is mapped to a correspondent component in IEC 61499. Thissection provides some guidelines for the engineering process.In particular it covers how IEC 61850 configurations (i.e., SCLfiles) can be transformed into an IEC 61499 compliant model.An overview of this engineering process is shown in Fig. 5,where the important steps are marked in the red circles.

The first step is to generate structured data types499 fromeach CDC850. When they are available, adapters499 can begenerated from the LNs850. Furthermore, IEC 61850 standardas well as IEC 61499 reference model both define simpledata types, thus a mapping between them are needed, e.g.,FLOAT32850 is mapped to REAL499.

In step 2 an application499 can be generated from thedefined LNs850. This means a subapplication499 is created foreach LN850, with adapters499 used to define the interfaces. Thecontent of these subapplications499 is a model of the behaviorof the LN850, e.g., providing measurements from a processinterface. Since the LNs850 do not define how their functionalityis implemented a semantic mapping is required between eachLN850 and some functionality defined in IEC 61499 . Such alogic can be expressed using a FB network499 or be defined ina single FB499. However, this is not a main part of this workbut will be a future research topic.

If report control blocks850 are defined for specific IEDs850

and LNs850 by the SCL file some connections499 may be auto-matically generated in the application499. If nothing is definedin the SCL configuration, the connections can always be addedmanually, depicted as step 3 in Fig. 5.

After the application499 is specified it can be deployed. Firstof all the devices499 and resources499 are specified and generatedfrom the IEDs850 and LDevices850 in the SCL configuration(i.e., step 4). Once this is done each subapplication499 in theapplication499 can be mapped to its corresponding resource499,i.e., the resource499 generated from the LDevice850 containingthe LN850. This activity is denoted as step 5 in Fig. 5.

The platform independent application499 does not explicitlycontain any communication specification. The actual commu-nication link is defined using SIFB or CLIENT/SERVER FBs499,see Section IV-C. Thus the adapter connections499 used in theapplication499 need to be exchanged into either a CLIENT or aSERVER FB499 representation as shown in step 6 of Fig. 5.

It may be noted that step 5 and 6 are possible to beperformed without the need of the IEC 61850 model. Thisincreases the number of possibilities in terms of reusability andreconfigurability. The actual deployment of the application499

may differ from the definition in the IEC 61850 model. Thisis possible due to the platform independence nature of theapplication499. Using this engineering approach the IEC 61850interoperability model is transformed into an IEC 61499 com-pliant representation.

18th Power Systems Computation Conference Wroclaw, Poland – August 18-22, 2014

System

DER : Device

LDevice : Resource

SCADA : Device

AP : Ethernet

LDevice : Resource

SERVERSERVER

MMXU >>

Application

IHMIIHMI

MMXU >>

DRCC >>

DRCC1DRCC1

>> DRCC

MMXU1MMXU1

>> MMXU

DRCC >>

IEC 61850 IEC 61499

22

44

55

DER : IED

AP : AccessPoint

Server

LDevice

MMXU : LN

DRCC : LN

TotW : MV : CDC

ctlVal : AnalogueValue : DA

OutWSet : APC : CDC

SCADA : IED

mag : AnalogueValue : DA

f : FLOAT32

f : FLOAT32

AP : AccessPoint

IHMI : LN

DRCCDRCC

>> DRCC

MMXUMMXU

>> MMXU

DRCCDRCC

DRCC >>

Subapplication

OutWSet.ctlVal.f

33

11

66

Fig. 5. Engineering process for transformation of IEC 61850 models into IEC 61499 models.

VI. MODELING USE-CASE

In order to give an idea of how the above defined trans-formation concept and rules can be implemented, a modelinguse-case is presented where an IEC 61850 configuration istransformed into an IEC 61499 model. This example is pro-vided in the corresponding Fig. 5.

A SCL file is provided for a power utility application wheretwo IEDs850 are used, one DER acting as a server and a SCADAsystem as a client. The DER has two LNs850: MMXU and DRCCfor supervisory control. DRCC is used to control the desiredactive power output of the DER. Using this SCL specificationan application499 is generated which models the behavior of theapplication. Using this application499, depicted in the middleof Fig. 5, the power utility application can also be simulatedand validated. If needed, it is also possible to deploy theapplication499 to real hardware, i.e., steps 4 to 6 in Fig. 5.

For the use-case Eclipse was used. The meta-models forIEC 61850 and IEC 61499 were imported into Eclipse, usingEclipse Modeling Framework. Next the transformations ruleswere defined using ATL for Eclipse. Two main transforma-tion processes were defined, first of all the rules defined inSection IV were implemented for the transformations betweenIEC 61850 and IEC 61499 artifacts. Listing 1 shows one ofthese rules.

rule DAType2StructuredType {froms : iec61850!TDAType

tot : iec61499!DataTypeType(name <- s.id,comment <- s.desc,structuredType <- strType

),strType : iec61499!StructuredTypeType(varDeclaration <- s.bDA

)}

Listing 1. ATL rule for transformation of data attribute to structured types

The rule DAType2StructuredType defines how aTDAType850 is transformed into a DataTypeType499. The sec-ond main transformation process is to generate an applica-tion499 based on the LNs850 defined in the SCL file.

The generated data types499 and adapters499 were importedinto an IEC 61499 tool environment. For this use-case the opensource environment 4DIAC was used. 4DIAC consist of anengineering tool (IDE) and a runtime environment compliantto the IEC 61499 standard.

The 4DIAC-IDE uses the same XML format for datatypes499 as defined in IEC 61499-2. Thus the generated datatypes499 and adapters499 could be directly imported without anyfurther alterations. The runtime environment need all FB499

types, data types499 and adapters499 to be compiled before theapplication499 can be deployed. This can be achieved througha model-to-text transformation from the generated types to theappropriate source code (4DIAC runtime uses C++).

The generated application499, shown in Fig. 6 consist ofthe LNs850 defined in the SCL file. Fig. 6 also depicts thegenerated DRCC adapter499. No information is provided in theSCL file about connections between the LNs850 and thereforethe connections499 between IHMI, MMXU and DRCC are definedmanually. The DRCC subapplication499 consists of a socketFB499, which converts the adapter499 interface into normal dataoutputs, and a conceptual interface to the process where thedesired active power output is forwarded to the actual process,e.g., an inverter. Once the application499 has been generated itcan be deployed to hardware devices, as described in steps 4to 6 in Fig. 5.

VII. SUMMARY AND CONCLUSIONS

In order to improve the engineering process of SmartGrid automation applications this paper introduces as model-driven engineering approach using IEC 61850 and IEC 61499.The main idea is to generate IEC 61499 applications basedon IEC 61850 descriptions. The paper presents the requiredmappings between artifacts of IEC 61850 and IEC 61499 and

18th Power Systems Computation Conference Wroclaw, Poland – August 18-22, 2014

Subapplication

Application

Adapter

Fig. 6. IEC 61499 application model represented in the 4DIAC-IDE tool.

it proposes an engineering approach for the transformations ofIEC 61850 models into IEC 61499 models.

The presented model-driven engineering approach enablesthe following new possibilities for the design and develop-ment of Smart Grid automation applications: (i) automaticgeneration and deployment of control applications based onIEC 61850 descriptions, (ii) increased consistency throughautomatic model transformations, (iii) better simulation andvalidation possibilities of the generated IEC 61499 application,and (iv) increased reusability through platform independence.

Although both IEC 61850 and IEC 61499 in general aresuited for MDE, improvements are always possible. LNs inIEC 61850 are currently specified as tables. If they wereprovided in an exchangeable UML format it would increasethe usability. Future work will focus on the semantic mappingsbetween LNs and their functionality expressed in IEC 61499.

ACKNOWLEDGMENT

This work is funded by the Austrian Climate and EnergyFund with the support of the Austrian Research PromotionAgency (FFG) under the project “DG -EV-HIL” (No. 827987).

REFERENCES

[1] “Technology Roadmap Smart Grids,” International Energy Agency(IEA), Tech. Rep., 2011. [Online]. Available: http://www.iea.org

[2] M. Liserre, T. Sauter, and J. Hung, “Future energy systems: Integratingrenewable energy sources into the smart power grid through industrialelectronics,” IEEE Industrial Electronics Magazine, vol. 4, no. 1, pp.18–37, 2010.

[3] V. Gungor, D. Sahin, T. Kocak, S. Ergut, C. Buccella, C. Cecati, andG. Hancke, “Smart grid technologies: Communication technologies andstandards,” IEEE Transactions on Industrial Informatics, vol. 7, no. 4,pp. 529–539, 2011.

[4] H. Farhangi, “The path of the smart grid,” IEEE Power and EnergyMagazine, vol. 8, no. 1, pp. 18–28, 2010.

[5] F. Andren, M. Stifter, and T. Strasser, “Towards a Semantic DrivenFramework for Smart Grid Applications: Model-Driven Developmentusing CIM, IEC 61850 and IEC 61499,” Informatik-Spektrum, vol. 36,pp. 58–68, Jan. 2013.

[6] R. F. Arritt and R. Dugan, “Distribution system analysis and the futuresmart grid,” IEEE Transactions on Industry Applications, vol. 47, no. 6,pp. 2343–2350, 2011.

[7] A. Apostolov, “Modeling systems with distributed generators inIEC 61850,” in Power Systems Conference (PSC’09), 2009.

[8] N. Higgins, V. Vyatkin, N.-K. Nair, and K. Schwarz, “Distributedpower system automation with IEC 61850, IEC 61499, and intelligentcontrol,” IEEE Transactions on Systems, Man, and Cybernetics, PartC: Applications and Reviews, vol. 41, no. 1, pp. 81–92, 2011.

[9] G. Zhabelova and V. Vyatkin, “Multiagent smart grid automationarchitecture based on IEC 61850/61499 intelligent logical nodes,” IEEETransactions on Industrial Electronics, vol. 59, no. 5, pp. 2351–2362,May 2012.

[10] L. Zhu, D. Shi, and X. Duan, “Standard Function Blocks for FlexibleIED in IEC 61850-Based Substation Automation,” IEEE Transactionson Power Delivery, vol. 26, no. 2, pp. 1101–1110, 2011.

[11] S. Grijalva and M. Tariq, “Prosumer-based smart grid architectureenables a flat, sustainable electricity industry,” in 2011 IEEE PESInnovative Smart Grid Technologies (ISGT), 2011, pp. 1–6.

[12] S. Rusitschka, C. Doblander, C. Goebel, and H.-A. Jacobsen, “Adaptivemiddleware for real-time prescriptive analytics in large scale powersystems,” in Proceedings of the Industrial Track of the 13th ACM/I-FIP/USENIX International Middleware Conference. ACM, 2013, p. 5.

[13] SMB Smart Grid Strategic Group (SG3), “IEC Smart Grid Standard-ization Roadmap,” International Electrotechnical Commission (IEC),Geneva, Switzerland, Tech. Rep. Ed. 1.0, 2010.

[14] “NIST Framework and Roadmap for Smart Grid Interoperability Stan-dards,” National Institute of Standards and Technology - U.S. Depart-ment of Commerce, USA, Tech. Rep. NIST Publication 1108, 2010.

[15] “The German Standardisation Roadmap E-Energy/Smart Grid,” GermanCommission for Electrical, Electronic & Information Technologies ofDIN and VDE, Frankfurt, Germany, Tech. Rep., 2010.

[16] “IEEE Guide for Smart Grid Interoperability of Energy Technologyand Information Technology Operation with the Electric Power System(EPS), End-Use Applications, and Loads,” IEEE Std 2030-2011, pp.1–126, Oct. 2011.

[17] IEC 61131-3: Programmable controllers - Part 3: Programming lan-guages, International Electrotechnical Commission (IEC) Std., 2012.

[18] IEC 61499: Function blocks, International Electrotechnical Commission(IEC) Std., 2012.

[19] I. Hegny, T. Strasser, M. Melik-Merkumians, M. Wenger, and A. Zoitl,“Towards an increased reusability of distributed control applicationsmodeled in IEC 61499,” in IEEE International Conference on EmergingTechnologies and Factory Automation (ETFA), 2012, pp. 1–8.

[20] T. Strasser, M. Rooker, G. Ebenhofer, A. Zoitl, C. Sunder, A. Valentini,and A. Martel, “Structuring of large scale distributed control programswith iec 61499 subapplications and a hierarchical plant structuremodel,” in IEEE International Conference on Emerging Technologiesand Factory Automation (ETFA), 2008, pp. 934–941.

[21] S. J. Mellor, S. Kendall, A. Uhl, and D. Weise, MDA Distilled.Redwood City, CA, USA: Addison Wesley Longman Publishing Co.,Inc., 2004.

[22] J. Siegel, “Developing in OMG’s New Model-Driven Architecture,”Management, 2001.

[23] A. Zoitl and V. Vyatkin, “IEC 61499 architecture for distributedautomation: The “glass half full” view,” IEEE Industrial ElectronicsMagazine, vol. 3, no. 4, pp. 7–23, 2009.

[24] R. W. Lewis, Modeling control systems using IEC 61499. IEEPublishing, 2001, no. ISBN: 0 85296 796 9.

[25] T. Mens and P. V. Gorp, “A taxonomy of model transformation,”Electronic Notes in Theoretical Computer Science, vol. 152,no. 0, pp. 125 – 142, 2006, proceedings of the InternationalWorkshop on Graph and Model Transformation (GraMoT 2005)Graph and Model Transformation 2005. [Online]. Available:http://www.sciencedirect.com/science/article/pii/S1571066106001435

[26] IEC 61850: Communication networks and systems for power utility au-tomation, International Electrotechnical Commission (IEC) Std., 2010.

[27] F. Andren, T. Strasser, and W. Kastner, “Towards a common modelingapproach for smart grid automation,” in 39th Annual Conference onIEEE Industrial Electronics Society (IECON), 2013, pp. 5338–5344.

[28] IEC/TR 61850-90-7 - Communication networks and systems for powerutility automation - Part 90-7: Object models for power converters indistributed energy resources (DER) systems, International Electrotech-nical Commission (IEC) Std., 2013.

[29] F. Andren, T. Strasser, A. Zoitl, and I. Hegny, “A reconfigurablecommunication gateway for distributed embedded control systems,”in 38th Annual Conference on IEEE Industrial Electronics Society(IECON), 2012, pp. 3720–3726.