Model-Driven Engineering applied to Smart Grid

Automation using IEC 61850 and IEC 61499

Filip Andren, Thomas Strasser

Wolfgang Kastner

AIT Austrian Institute of Technology

Energy Department
Vienna, Austria
Email: {filip.andren, thomas.strasser}@ait.ac.at

Institute of Computer Aided Automation

Vienna University of Technology
Vienna, Austria
Email: k@auto.tuwien.ac.at

AbstractIn order to guarantee a sustainable electric energy

supply the power systems domain is currently in a transformation
phase. Renewable energy sources have to be installed on a large
scale causing a more complex operation of the power distribution
grids due its stochastic behavior. Advanced automation and
information technology approaches, concepts and algorithms are
being applied to operate such complex systems. Interoperability
and standardized interfaces are important topics which have
to be considered realizing a Smart Grid. A standard-compliant
formal approach for the modeling of power utility automation
and control applications is missing up to now. This paper
therefore introduces a novel approach using the well-known
model-driven engineering concept from computer science for
the development of Smart Grid automation applications. This
method focuses on the usage of the power utility interoperability
approach IEC 61850 and the distributed automation reference
model IEC 61499 as basis for the proposed modeling concept.
An overview of the engineering method, corresponding transformation rules as well as an explanatory example are provided.

I.

I NTRODUCTION

The power systems domain is currently on the verge of

a profound change. The large-scale integration of Distributed
Energy Resources (DER) from renewable sources challenges
the already tight hosting capacities in the power distribution
grids today [1], [2]. Automation and control systems using
advanced Information and Communication (ICT) concepts and
architectures are seen as key elements of the future Smart
Grids to enable a more efficient use of the already existing
infrastructure [3]. The future power distribution grids have
to support a higher amount of flexibility and adaptability
to varying demands. Because of its complexity, the future
system will not only be a matter of grid components and
related topology, but also the automation and control systems
as well as the corresponding application(s) have to be taken
into account making todays approaches smarter [4].
However, a comprehensive information model for Smart
Grid application development covering the physical grid, the
communication infrastructure as well as control and application issues is missing up to now. In addition, no corresponding
design method, development procedure nor necessary tool support system is able to integrate all these different views during
the design and validation phase of Smart Grid automation
applications today [5], [6].
The most promising solutions for the standardized information exchange in Smart Grids are based on the well known
th

18 Power Systems Computation Conference

domain standards Common Information Model (CIM) and

power utility automation (i.e., IEC 61850) introduced by the
International Electrotechnical Commission (IEC), Technical
Committee TC 57 [3], [5]. The later one which is of interest
for the work presented in this paper was originally developed
for substation automation but has been enlarged over the last
years to cover also power utility equipment and DER services
[7]. Designed to address mainly interoperability issues and
standardized software interface, IEC 61850 does not cover the
implementation of automation and protection functions. They
have to be implemented using other approaches.
One very interesting concept from the automation sector
has also been introduced by the IEC, the IEC 61499 reference model. It describes an automation standard especially
developed for the design of distributed industrial process,
measurement and control systems using function blocks. Due
to its distributed nature it provides a very good basis to
serve as implementation concept for IEC 61850 functions.
There are already several publications available discussing the
integration and harmonization of IEC 61850 and IEC 61499
for the domain of Smart Grids [5], [8], [9], [10].
The main aim of this paper is to introduce and discuss a
model-driven design approach to integrate the IEC 61499 automation approach with the IEC 61850 power utility standard
to improve and partially automate the engineering process of
Smart Grid automation applications. The presented approach
continues an integration of the two standards where modeldriven development is used for model transformations [5].
The rest of the paper is organized as follows: Section II
gives a brief overview about currently ongoing activities related to power utility automation as well as important IEC standards. The model-driven engineering concept using IEC 61850
and IEC 61499 is introduced in Section III followed by the
discussion of model-transformation rules in Section IV. The
proposed engineering concept is covered in Section V and
explained on a selected use case in Section VI. Finally, the
paper is summarized and concluded in Section VII.
II.

P OWER U TILITY AUTOMATION AND S TANDARDS

A. Active Power Distribution Grids

Up until now the electric energy infrastructure was characterized by a centralized architecture. Electricity was generated
by large-scale power plantsdenoted as bulk generation (e.g.,

Wroclaw, Poland August 18-22, 2014

nuclear, hydro, fossil-fuel power plants)and transported over

long distances by the transmission system to regions and cities.
Followed by a series of step-down transformers to medium
and low voltage levels the electric energy was distributed to
the customers (i.e., distribution system). Such a system has a
hierarchical structure and is characterized by a unidirectional
power flow from the bulk generators to the customers [1].
In order to build a sustainable electric energy supply and
the corresponding infrastructure to prevent a global warming
during the next decades, Renewable Energy Sources (RES)
have to be integrated in todays power system on a large
scale. Such generators are usually installed in the medium
and low-voltage distribution grids in a decentralized way (e.g.,
small photovoltaic systems, hydro power stations or wind
turbines). With the integration of such DERs the topology
of the electric energy supply infrastructure changes denoted
in the literature as Smart Grid [1], [2], [4]. Still the whole
architecture has a hierarchical nature but it has to cope with
fluctuating distributed generation causing a bidirectional power
flow between the distribution grid and the consumers which
now act also as electricity producers (denoted in the literature
also as prosumers) [11].
Traditionally, the automation degree in power distribution
grids are quite low compared to the transmission system.
Medium-voltage distribution grids, secondary substations and
larger Distributed Generators (DG) can be controlled by distribution control centers but especially the operation of lowvoltage grids is still carried out manually today. Due to the
large scale integration of DER components and the future
penetration of electric vehicles as well as decentralized storage
systems the operation of the aforementioned grids becomes
more complex [1], [4].
With the availability of powerful Supervisory Control and
Data Acquisition systems (SCADA), corresponding remote
control possibilities/devices as well as installation of automatic
metering systems (i.e., advanced sensor and measurement
equipment) a higher degree of automation may be expected
also on the low-voltage level during the next years. The current
trend is also to increase the connectivity between all these
components (e.g., generators, loads, storage, transmission and
distribution lines, substations, on-load tap change transformers,
measurement devices, smart meters) through a powerful communication network and corresponding automation infrastructure. All these measures allow a more intelligent monitoring
and 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 is
standardization to fulfill interoperability requirements. In this
context on international level the IEC is one of the most
important players. In order to cover Smart Grid topics it
has setup the Strategic Group on Smart Grid (SG 3). One
important outcome of this activity was the development of
the IEC Smart Grid Standardization Roadmap [13] where
the following main standards for the realization of Smart
Grids are suggested: (i) IEC TR 62357 Seamless Integration
Reference Architecture (SIA) using service-oriented concepts,
(ii) IEC 61970/61968 Common Information Model (CIM) for
transmission and distribution systems, (iii) IEC 61850 power
th

18 Power Systems Computation Conference

utility automation, (iv) IEC 62351 security, (v) IEC 62056

meter data exchange, and (vi) IEC 61508 functional safety.
Besides the IEC Smart Grids activities several other initiatives can be observed. The most important once are the
US NIST Framework and Roadmap for Smart Grids Interoperability Standards [14], the DKE German standardization
roadmap for Smart Grids [15], as well as the IEEE Guide
for Smart Grid Interoperability of Energy Technology and
Information Technology Operation with the Electric Power
System (EPS), End-Use Applications, and Loads [16].
As mentioned above power utility automation is covered by
IEC 61850, developed by IEC TC 57. The main purpose of
this interoperability standard is to define a common modeling
approach for the data exchange in power systems. To do this
it defines several data models for modeling, configuration as
well as high-level communication services for information exchange over Ethernet. The main componentsLogical Nodes
(LN)are used to model power system components (e.g.,
switches, transformers, inverters) as well as power system
functions (e.g., measurement, protection, voltage control). The
LNs 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 Configuration Language (SCL) is defined using XML schema.
The implementation of the corresponding automation and
protection functions is not part of IEC 61850. Therefore, other
solutions have to be used. For example, the German DKE
roadmap suggests the automation standards IEC 61131 [17]
and IEC 61499 [18] for this task. IEC 61131 was especially
developed for centralized Programmable Logic Controllers
(PLC) whereas IEC 61499 provides a reference architecture
for distributed automation and control systems. IEC 61499
has been defined as a methodology for specifying open distributed industrial process, measurement and control systems
and therefore providing a very good basis for the implementation of IEC 61850 functions. Automation applications can
be modeled in a hardware independent manner using Function
Blocks (FB). Moreover, the automation hardware can also be
represented by IEC 61499 elements (i.e., devices, resources
and communication network). An interesting aspect of this
distributed automation standard is its event-driven execution
model. Different concepts are defined for structuring complex
automation problems [19], [20].
Summarizing, for the design of Smart Grid control functions and applications as well as their implementation in
complex automation solutions proper engineering processes
and corresponding tools are missing up to now from an ICT
point of view. A formalized and standard-compliant design and
implementation process for Smart Grid automation systems is
required. Below such an approach is presented.
III.

M ODEL -D RIVEN E NGINEERING C ONCEPT

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

Wroclaw, Poland August 18-22, 2014

either be model-to-model transformations or model-to-text

transformations, also called code generation. Usually more
than one transformation is needed, e.g., a model-to-model
transformation followed by code generation. To automatically
execute model- transformations some kind of tool support is
needed. Such tools can also check for possible errors.
Applying the MDE approach to the IEC 61850 and
IEC 61499 standards enables new engineering possibilities
compared to standard power utility automation. IEC 61850
introduced SCL which makes it easier to configure IEDs.
Nonetheless, since IEC 61850 does not specify how the
functions of the LNs are implemented, such a configuration
cannot be considered as complete. With an MDE approach
between IEC 61850 and IEC 61499 not only the communication can be configured, but also the functionality of the LNs
can be automatically configured, generated and deployed. An
MDE approach also provides better simulation and validation
possibilities of the application [5].
The main goal of the present work is to introduce a
model-driven approach to transform IEC 61850 models into
IEC 61499 automation models. In order to do this the platform
independent modeling approach of IEC 61499 is used. As
described in [18], [23] IEC 61499 can effectively be used in an
MDE approach, where the design of the IEC 61499 application
is done in a platform independent way. The platform specific
implementation is done once the application is mapped to the
hardware specification (i.e., IEC 61499 devices and resources).
This approach is depicted in Fig. 1.
Thus any hardware independent parts of the IEC 61850
model should be mapped to the IEC 61499 application and
hardware dependent parts should be mapped to IEC 61499
devices and resources. In this paper hardware independence
is defined as a model which can be generalized to multiple
platforms. Both IEC 61850 and IEC 61499 contain domain
specific names and expressions. To improve the readability any
expressions related to IEC 61850 are emphasized as element850 ,
and expressions related to IEC 61499 are emphasized as
element499 in the rest of the paper.
FB1

FB2

FB3

FB4

IV.

A model-transformation can be defined as an automatic

generation of one or more target models from one or more
source models. The heart of the model- transformation is
the transformation rule, which describe how one or more
constructs of the source meta-model can be transformed into
one or more constructs of the target meta-model. A set of
transformation rules can be combined into a transformation
definition describing how the source models are mapped to
target models [25].
IEC 61850-6 defines the Substation Configuration Language (SCL) for the configuration of IEC 61850 devices. SCL
is defined using XML schema. IEC 61499-2 also provides
a specification of its elements in form of Document Type
Definitions (DTD). The DTD specification are defined in XML
format to allow exchange of models between software tools.
These formal definitions can be used as meta-models for
IEC 61850 and IEC 61499 respectively. Thus it is possible
to define transformation rules between objects in IEC 61850
to elements in IEC 61499. For completeness the bi-directional
transformation should be possible, however this paper only
covers the transformation from IEC 61850 to IEC 61499.
A. Mapping of Artifacts
The main object in IEC 61850 is the LN 850 (LNode in
Fig. 2) since it act as a connector between the different models.
Summarized, the following three models with different objects
are of importance:

Functional model: a logical model containing power

conducting equipment (e.g., transformer) as well as
virtual functions (e.g., voltage level)

Product model: provides models of the IEDs850 and

their LNs850 and data objects,

Communication model: models the available access

points850 and subnetworks850 .

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

Application Model
FB5

M ODEL -T RANSFORMATION

FB6

System model: a collection of devices499 and their connections with each other through network segments499
and links499 ,

Communication Network
Device 1

Device 2

Communication Interface
Resource
A

Resource
B

Communication Interface

Resource
C

Resource
A

Resource
B

System Model

Resource
C

Application 1
Application 2

App. 4

Process Interface

Application 3

Process Interface
Controlled Process
Resource C
Communication Interface
MN

CN1

CN2

POWERL
INK_IO

POWERL
INK_IO

OUT

Resource Model

IN

POWERL
INK_MN
SUBL

PUBL

Process Interface
Scheduling function

Fig. 1.

th

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

18 Power Systems Computation Conference

Fig. 2.

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

Wroclaw, Poland August 18-22, 2014

Device model: models a hardware device which consists of one or more resources499 ,

Resource model: a resource499 is considered as a functional 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 artifacts

is seen in Table I. The corresponding transformation rules are
described below and are summarized in Fig. 3.
1) Functional to Application Model: The functional model
is intended to represent the functional structure of a substation850 . As depicted in Fig. 2 each object of the functional
model contains LNs850 . Thus the function described by the LN 850
and its IED850 is related to a part of the substation850 [26].
Since the objects of the functional model is not directly
related to power system objects (i.e, hardware devices) they are
mapped to the application499 . Thus the platform independence
is maintained. The hierarchical structure of the functional
model (e.g., substation850 containing voltage levels850 containing
LNs850 ) is realized in IEC 61499 using subapplications499 . As
shown in Fig. 2 the LN 850 is part of both the functional
model as well as the product model, i.e., the LN 850 is the
lowest hierarchy level of the functional model. Thus the
subapplication499 representing the LN 850 contains the product
model of the LN 850 .
Connections499 between the subapplications499 correspond to
the information exchange between the LNs850 . Each LN 850 can
be seen as an interface description, which makes a mapping to
adapters499 a suitable option [27]. This mapping is described
in more detail below.
2) Product to Resource/Device Model: The product model
covers the modeling of the IEDs850 used in the power system.
Each IED850 can be seen as a hardware device containing
software functions. Models of these software functions are
IEC 61850
Substation
-name = nSub

LNode
-inst = i

IEC 61499
Application

Substation2System

System

-name = nSub

-name = nSub

Subapplication

LNode2Subapp

TABLE I.

M APPING BETWEEN IEC 61850 AND IEC 61499 ARTIFACTS

IEC 61850
Substation
IED
Logical Device
LN
Communication
Abstract Communication
Service Interface (ACSI)

IEC 61499
System & Application
Device
Resource
Subapplication & Adapter
Network segments & Links
SIFB
(client/server and publisher/subscriber)

not covered by IEC 61850, however their interfaces are represented in form of LNs850 . Thus the product model defines a
hierarchical description of the IEDs850 , i.e., each IED850 contains
one or more servers850 , containing one or more logical devices
(LDevice850 ), and so on ending with the data of the LN 850 , as
presented in Fig. 2 [26].
Following this MDE approach of IEC 61499, as described
in Section III all hardware independent parts should be part of
the application499 , whereas any parts related to the hardware
should be covered by the resource499 or the device499 . In the
previous section the LN 850 was defined to be part of the application499 as it describes a hardware independent functionality.
The same applies to the data850 and therefore it is also part of
the application499 .
The IED850 is a hardware device which makes a mapping
to the device499 natural. Each IED850 contains one ore more
LDevices850 which are mapped to resources499 . The servers850
are a special case since they need to be mapped to Service
Interface Function Blocks499 . This mapping is explained in
more detail below.
3) Communication to System Model: The communication
model of IEC 61850 defines logically possible connections between 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 via
links499 to network segments499 [18]. Thus a logical mapping
is made from subnetworks850 to network segments499 and from
access points850 to links499 .
Even if IEC 61499 provide some possibilities for network
modeling it still lacks in detail. For instance link properties like
delay or statistical package drops cannot be directly modeled.
For such purposes other models are needed.

-name = lC + i

B. Logical Nodes to Subapplications/Adapters

LNodeType
-lnClass = lC

IED
-name = nIED

Server

LNodeType2Adapter

AccessPoint

-name = lC

Device

IED2Device

-name = nAP

Adapter

-name = nIED

Link

AccessPoint2Link

-commResource = iLD
-segmentName = nSunN

SubNetwork
-name = nSubN SubNetwork2NetworkSegment
-type = tSubN
Logical Device
-inst = iLD

Fig. 3.

th

LogicalDevice2Resource

NetworkSegment
-name = nSubN
-type = tSubN

Resource
-name = iLD

Transformation rule

Transformation definition between IEC 61850 and IEC 61499

18 Power Systems Computation Conference

As described in Section IV-A1 each LN 850 of an IEC 61850

model is mapped to two different objects in the IEC 61499
model, a subapplication499 and an adapter499 . The subapplication499 is intended to include the functional model of the
LN 850 , and the adapter499 models the data interface. The use
of subapplications499 makes it possible to model Smart Grid
applications in different hierarchies. Furthermore, adapters499
have the advantage that they can define a bi-directional connection499 , including both data and event connections.
When a LN 850 is mapped to an adapter499 , each data
input/output of the adapter499 has the data type matching a
Common Data Class850 (CDC) specified in IEC 61850. A
CDC850 is a complex structure made up of simple data types,

Wroclaw, Poland August 18-22, 2014

arrays or other structures. In IEC 61499 user defined structured

data types499 can also be used to model a CDC850 . Since a
CDC850 can consist of other structures the result may be a
nested structured data type499 in IEC 61499 [27].
In order to define the event interface499 of adapters499
the communication services defined by the IEC 61850 are
studied since they define how the data of LNs850 are accessed.
For example all communication services related to polling
can be mapped to a request (REQ), confirm (CNF) pattern in
IEC 61499. Fig. 4 shows how the measurement LN 850 MMXU
[28] is modeled as an adapter499 .
MMXU class
Data object Comon
Explanation
name
data class
Measured Values
TotW
MV
Total Active Power
TotVAr
MV
Total Reactive Power

T M/O/C
O
O

MMXU Adapter
Confirmation from Server EVENT
Total Active Power MV
Total Reactive Power MV

Fig. 4.

CNF

REQ

EVENT Request from Client

TotW
TotVAr

Mapping of IEC 61850 LN MMXU into IEC 61499 adapter.

The usage of adapters499 simplifies the overall structure of

the application499 , but it does not directly specify any communication link. The actual specification of the communication
configuration is done when the application499 is mapped to a
specific resource499 [27].
C. Communication Patterns

server publishes values to the client using real-time constraints,

and (iii) GOOSE messages, publishing of real-time substation
events, e.g., protection related events.
V.

E NGINEERING P ROCESS

The mappings between IEC 61850 and IEC 61499 described in Section IV define how each object of IEC 61850
is mapped to a correspondent component in IEC 61499. This
section provides some guidelines for the engineering process.
In particular it covers how IEC 61850 configurations (i.e., SCL
files) 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 from
each CDC850 . When they are available, adapters499 can be
generated from the LNs850 . Furthermore, IEC 61850 standard
as well as IEC 61499 reference model both define simple
data types, thus a mapping between them are needed, e.g.,
FLOAT32850 is mapped to REAL499 .
In step 2 an application499 can be generated from the
defined LNs850 . This means a subapplication499 is created for
each LN 850 , with adapters499 used to define the interfaces. The
content of these subapplications499 is a model of the behavior
of the LN 850 , e.g., providing measurements from a process
interface. Since the LNs850 do not define how their functionality
is implemented a semantic mapping is required between each
LN 850 and some functionality defined in IEC 61499 . Such a
logic can be expressed using a FB network499 or be defined in
a single FB499 . However, this is not a main part of this work
but will be a future research topic.

As stated above on of the main goals of IEC 61499

was 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 not
provide specific communication means for this interaction.
Generally, SIFBs are intended to provide an interface between
the application499 and the actual communication service of the
resource499 . Moreover, two generic communication patterns are
defined in the standard, representing bi-directional transactions
with a client/server model and uni-directional transactions
with a publisher/subscriber model [18]. Since the two models
are generic it is also possible to map other communication
protocols onto these patterns [29].

If report control blocks850 are defined for specific IEDs850

and LNs850 by the SCL file some connections499 may be automatically generated in the application499 . If nothing is defined
in the SCL configuration, the connections can always be added
manually, depicted as step 3 in Fig. 5.

IEC 61850 defines a number of Abstract Communication

Service Interfaces (ACSI), dedicated to different purposes,
e.g., some follow a typical polling pattern whereas other are
intended for reporting. Principally a client/server model is used
for the communication, i.e., a client needs to connect to a
server before it can use any of its services. From an application
point-of-view this may however not always be the case.

The platform independent application499 does not explicitly

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

ACSIs in IEC 61850 defined for polling purposes (e.g.,

GetDataValues, SetDataValues) are mapped to the client/server model of IEC 61499, since a poll is instantiated by a
request (REQ) from the client and answered with a response
(CNF) from the server. A number of ACSIs can also be mapped
to a publisher/subscriber model. These are mainly (i) reports,
where the server sends a collection of data to a specific
client when something changes, (ii) sampled-values, where the
th

18 Power Systems Computation Conference

After the application499 is specified it can be deployed. First

of all the devices499 and resources499 are specified and generated
from the IEDs850 and LDevices850 in the SCL configuration
(i.e., step 4). Once this is done each subapplication499 in the
application499 can be mapped to its corresponding resource499 ,
i.e., the resource499 generated from the LDevice850 containing
the LN 850 . This activity is denoted as step 5 in Fig. 5.

It may be noted that step 5 and 6 are possible to be

performed without the need of the IEC 61850 model. This
increases the number of possibilities in terms of reusability and
reconfigurability. The actual deployment of the application499
may differ from the definition in the IEC 61850 model. This
is possible due to the platform independence nature of the
application499 . Using this engineering approach the IEC 61850
interoperability model is transformed into an IEC 61499 compliant representation.

Wroclaw, Poland August 18-22, 2014

IEC 61850

SCADA : IED

IEC 61499

44

System

AP : AccessPoint

AP : Ethernet

IHMI : LN

Application

DER : IED

DER : Device

AP : AccessPoint

IHMI
IHMI

22

Server

33

55

>> MMXU

DRCC
DRCC

MMXU >>

LDevice

LDevice : Resource

DRCC >>
MMXU : LN

SCADA : Device

LDevice : Resource

MMXU
MMXU

MMXU1
MMXU1
>> DRCC

TotW : MV : CDC

f : FLOAT32
DRCC : LN

66

DRCC
DRCC

mag : AnalogueValue : DA

>> MMXU

DRCC1
DRCC1
MMXU >>

Subapplication
DRCC >>

SERVER
SERVER

OutWSet.ctlVal.f

DRCC >>

>> DRCC

11

OutWSet : APC : CDC

ctlVal : AnalogueValue : DA
f : FLOAT32

Fig. 5.

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

VI.

M ODELING U SE -C ASE

In order to give an idea of how the above defined transformation concept and rules can be implemented, a modeling
use-case is presented where an IEC 61850 configuration is
transformed into an IEC 61499 model. This example is provided in the corresponding Fig. 5.
A SCL file is provided for a power utility application where
two IEDs850 are used, one DER acting as a server and a SCADA
system as a client. The DER has two LNs850 : MMXU and DRCC
for supervisory control. DRCC is used to control the desired
active power output of the DER. Using this SCL specification
an application499 is generated which models the behavior of the
application. Using this application499 , depicted in the middle
of Fig. 5, the power utility application can also be simulated
and validated. If needed, it is also possible to deploy the
application499 to real hardware, i.e., steps 4 to 6 in Fig. 5.
For the use-case Eclipse was used. The meta-models for
IEC 61850 and IEC 61499 were imported into Eclipse, using
Eclipse Modeling Framework. Next the transformations rules
were defined using ATL for Eclipse. Two main transformation processes were defined, first of all the rules defined in
Section IV were implemented for the transformations between
IEC 61850 and IEC 61499 artifacts. Listing 1 shows one of
these rules.
rule DAType2StructuredType {
from
s : iec61850!TDAType
to
t : iec61499!DataTypeType(
name <- s.id,
comment <- s.desc,
structuredType <- strType
),
strType : iec61499!StructuredTypeType(
varDeclaration <- s.bDA
)
}
Listing 1.

th

ATL rule for transformation of data attribute to structured types

18 Power Systems Computation Conference

The rule DAType2StructuredType defines how a

TDAType850 is transformed into a DataTypeType499 . The second main transformation process is to generate an application499 based on the LNs850 defined in the SCL file.
The generated data types499 and adapters499 were imported
into an IEC 61499 tool environment. For this use-case the open
source environment 4DIAC was used. 4DIAC consist of an
engineering tool (IDE) and a runtime environment compliant
to the IEC 61499 standard.
The 4DIAC-IDE uses the same XML format for data
types499 as defined in IEC 61499-2. Thus the generated data
types499 and adapters499 could be directly imported without any
further alterations. The runtime environment need all FB499
types, data types499 and adapters499 to be compiled before the
application499 can be deployed. This can be achieved through
a model-to-text transformation from the generated types to the
appropriate source code (4DIAC runtime uses C++).
The generated application499 , shown in Fig. 6 consist of
the LNs850 defined in the SCL file. Fig. 6 also depicts the
generated DRCC adapter499 . No information is provided in the
SCL file about connections between the LNs850 and therefore
the connections499 between IHMI, MMXU and DRCC are defined
manually. The DRCC subapplication499 consists of a socket
FB499 , which converts the adapter499 interface into normal data
outputs, and a conceptual interface to the process where the
desired active power output is forwarded to the actual process,
e.g., an inverter. Once the application499 has been generated it
can be deployed to hardware devices, as described in steps 4
to 6 in Fig. 5.
VII.

S UMMARY AND C ONCLUSIONS

In order to improve the engineering process of Smart

Grid automation applications this paper introduces as modeldriven engineering approach using IEC 61850 and IEC 61499.
The main idea is to generate IEC 61499 applications based
on IEC 61850 descriptions. The paper presents the required
mappings between artifacts of IEC 61850 and IEC 61499 and

Wroclaw, Poland August 18-22, 2014

Application

[9]

Adapter

[10]

Subapplication

[11]

[12]
Fig. 6.

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

[13]

it proposes an engineering approach for the transformations of

IEC 61850 models into IEC 61499 models.
The presented model-driven engineering approach enables
the following new possibilities for the design and development of Smart Grid automation applications: (i) automatic
generation and deployment of control applications based on
IEC 61850 descriptions, (ii) increased consistency through
automatic model transformations, (iii) better simulation and
validation possibilities of the generated IEC 61499 application,
and (iv) increased reusability through platform independence.
Although both IEC 61850 and IEC 61499 in general are
suited for MDE, improvements are always possible. LNs in
IEC 61850 are currently specified as tables. If they were
provided in an exchangeable UML format it would increase
the usability. Future work will focus on the semantic mappings
between LNs and their functionality expressed in IEC 61499.

[14]

[15]

[16]

[17]
[18]
[19]

[20]

ACKNOWLEDGMENT
This work is funded by the Austrian Climate and Energy
Fund with the support of the Austrian Research Promotion
Agency (FFG) under the project DG -EV-HIL (No. 827987).
R EFERENCES
[1]
[2]

[3]

[4]
[5]

[6]

[7]
[8]

th

Technology Roadmap Smart Grids, International Energy Agency

(IEA), Tech. Rep., 2011. [Online]. Available: http://www.iea.org
M. Liserre, T. Sauter, and J. Hung, Future energy systems: Integrating
renewable energy sources into the smart power grid through industrial
electronics, IEEE Industrial Electronics Magazine, vol. 4, no. 1, pp.
1837, 2010.
V. Gungor, D. Sahin, T. Kocak, S. Ergut, C. Buccella, C. Cecati, and
G. Hancke, Smart grid technologies: Communication technologies and
standards, IEEE Transactions on Industrial Informatics, vol. 7, no. 4,
pp. 529539, 2011.
H. Farhangi, The path of the smart grid, IEEE Power and Energy
Magazine, vol. 8, no. 1, pp. 1828, 2010.
F. Andren, M. Stifter, and T. Strasser, Towards a Semantic Driven
Framework for Smart Grid Applications: Model-Driven Development
using CIM, IEC 61850 and IEC 61499, Informatik-Spektrum, vol. 36,
pp. 5868, Jan. 2013.
R. F. Arritt and R. Dugan, Distribution system analysis and the future
smart grid, IEEE Transactions on Industry Applications, vol. 47, no. 6,
pp. 23432350, 2011.
A. Apostolov, Modeling systems with distributed generators in
IEC 61850, in Power Systems Conference (PSC09), 2009.
N. Higgins, V. Vyatkin, N.-K. Nair, and K. Schwarz, Distributed
power system automation with IEC 61850, IEC 61499, and intelligent
control, IEEE Transactions on Systems, Man, and Cybernetics, Part
C: Applications and Reviews, vol. 41, no. 1, pp. 8192, 2011.

18 Power Systems Computation Conference

[21]

[22]
[23]

[24]
[25]

[26]
[27]

[28]

[29]

G. Zhabelova and V. Vyatkin, Multiagent smart grid automation

architecture based on IEC 61850/61499 intelligent logical nodes, IEEE
Transactions on Industrial Electronics, vol. 59, no. 5, pp. 23512362,
May 2012.
L. Zhu, D. Shi, and X. Duan, Standard Function Blocks for Flexible
IED in IEC 61850-Based Substation Automation, IEEE Transactions
on Power Delivery, vol. 26, no. 2, pp. 11011110, 2011.
S. Grijalva and M. Tariq, Prosumer-based smart grid architecture
enables a flat, sustainable electricity industry, in 2011 IEEE PES
Innovative Smart Grid Technologies (ISGT), 2011, pp. 16.
S. Rusitschka, C. Doblander, C. Goebel, and H.-A. Jacobsen, Adaptive
middleware for real-time prescriptive analytics in large scale power
systems, in Proceedings of the Industrial Track of the 13th ACM/IFIP/USENIX International Middleware Conference. ACM, 2013, p. 5.
SMB Smart Grid Strategic Group (SG3), IEC Smart Grid Standardization Roadmap, International Electrotechnical Commission (IEC),
Geneva, Switzerland, Tech. Rep. Ed. 1.0, 2010.
NIST Framework and Roadmap for Smart Grid Interoperability Standards, National Institute of Standards and Technology - U.S. Department of Commerce, USA, Tech. Rep. NIST Publication 1108, 2010.
The German Standardisation Roadmap E-Energy/Smart Grid, German
Commission for Electrical, Electronic & Information Technologies of
DIN and VDE, Frankfurt, Germany, Tech. Rep., 2010.
IEEE Guide for Smart Grid Interoperability of Energy Technology
and Information Technology Operation with the Electric Power System
(EPS), End-Use Applications, and Loads, IEEE Std 2030-2011, pp.
1126, Oct. 2011.
IEC 61131-3: Programmable controllers - Part 3: Programming languages, International Electrotechnical Commission (IEC) Std., 2012.
IEC 61499: Function blocks, International Electrotechnical Commission
(IEC) Std., 2012.
I. Hegny, T. Strasser, M. Melik-Merkumians, M. Wenger, and A. Zoitl,
Towards an increased reusability of distributed control applications
modeled in IEC 61499, in IEEE International Conference on Emerging
Technologies and Factory Automation (ETFA), 2012, pp. 18.
T. Strasser, M. Rooker, G. Ebenhofer, A. Zoitl, C. Sunder, A. Valentini,
and A. Martel, Structuring of large scale distributed control programs
with iec 61499 subapplications and a hierarchical plant structure
model, in IEEE International Conference on Emerging Technologies
and Factory Automation (ETFA), 2008, pp. 934941.
S. J. Mellor, S. Kendall, A. Uhl, and D. Weise, MDA Distilled.
Redwood City, CA, USA: Addison Wesley Longman Publishing Co.,
Inc., 2004.
J. Siegel, Developing in OMGs New Model-Driven Architecture,
Management, 2001.
A. Zoitl and V. Vyatkin, IEC 61499 architecture for distributed
automation: The glass half full view, IEEE Industrial Electronics
Magazine, vol. 3, no. 4, pp. 723, 2009.
R. W. Lewis, Modeling control systems using IEC 61499.
IEE
Publishing, 2001, no. ISBN: 0 85296 796 9.
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 International
Workshop on Graph and Model Transformation (GraMoT 2005)
Graph and Model Transformation 2005. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S1571066106001435
IEC 61850: Communication networks and systems for power utility automation, International Electrotechnical Commission (IEC) Std., 2010.
F. Andren, T. Strasser, and W. Kastner, Towards a common modeling
approach for smart grid automation, in 39th Annual Conference on
IEEE Industrial Electronics Society (IECON), 2013, pp. 53385344.
IEC/TR 61850-90-7 - Communication networks and systems for power
utility automation - Part 90-7: Object models for power converters in
distributed energy resources (DER) systems, International Electrotechnical Commission (IEC) Std., 2013.
F. Andren, T. Strasser, A. Zoitl, and I. Hegny, A reconfigurable
communication gateway for distributed embedded control systems,
in 38th Annual Conference on IEEE Industrial Electronics Society
(IECON), 2012, pp. 37203726.

Wroclaw, Poland August 18-22, 2014