Virtual61850: A Model-Driven Tool to Support the Design and

Validation of Virtualized Controllers in Power Industry

Nadine Kabbara, Timothe Grisot and Jerome Cantenot

EDF R&D Paris Saclay, France

Keywords:

Model-Driven Engineering, Metamodels, Eclipse EMF, OCL, IEC 61850, Interoperability, Power Systems.

Abstract:

Model driven engineering (MDE) has seen a rising interest by the power industry particularly for supporting

application and standards developments. Modern power systems often still involve many manual, error-prone

conﬁguration works. Examples include speciﬁcation developments and conﬁguration of communicating con-

trollers. Recently, new concepts such as virtualized controllers (deployed in virtual machines or containers)

have emerged. However, such a concept still remains rather new for power system experts where integrating

virtualized controllers into their existing engineered information systems is a non straight-forward task. This

study thus proposes to tackle some of the engineering and integration problems faced by this new concept

thanks to the beneﬁts offered by MDE. Virtual61850 is an implementation of a model-driven tool for support-

ing the conﬁguration of future virtualized controllers into the power industry’s information systems. It supports

basic industry requirements including platform independence, standardized legacy conﬁguration languages

(IEC 61850 standard), modularity, and integrated testing and validation. The application was benchmarked

for scalable models creation, editing, and validations that are necessary for advanced industrial simulation and

ﬁeld deployments of virtualized controllers.

1 INTRODUCTION

The exploitation of formalized models for the design

of software artifacts (e.g. source code, documenta-

tion, tests) is the core principle of Model-driven engi-

neering (MDE), a discipline in computer science. The

model-centric approach allows the speciﬁcation and

design of software applications at a high level of ab-

straction, which can then be automatically validated

before any platform-speciﬁc code generation (Clark

et al., 2015).

Every model, in the context of MDE, can be

mapped to a higher ‘type model’ describing all the

knowledge of that model (i.e., elements, transitions,

connection types). The ‘type model’, otherwise

known as ‘meta-model’, aims to create an elegant lan-

guage for representing domain artifacts (abstract syn-

tax). Each syntax is associated with formally deﬁned

meanings or semantics that represent the concepts of

a domain (composing a Domain-Speciﬁc Language

DSL) (Kent, 2002).

Meta-modeling is also particularly beneﬁcial for

developing precise speciﬁcations of domain stan-

dards (e.g. systems engineering, telecoms, process

modeling) (Clark et al., 2015). It helps enhance

the standard’s comprehension and implementation by

the involved parties. In addition, meta-models pro-

vide consistent documentation generation and facil-

itate the standards’ development and maintenance.

These beneﬁts were particularly observed by (Andren

et al., 2013) for the power industry domain as in the

case of the IEC 61850 standard (Communication net-

works and systems for power utility automation (IEC,

2020)).

The motivation for adopting MDE principles in

the power industry is driven by the increased inter-

est in smarter electrical grid developments. The high

reliance on complex information and communication

technologies necessitated utilizing standardized se-

mantics to maintain system-level interoperability of

the power grid information systems (Andren et al.,

2013).

Currently, there exists different power system

standards covering communication, control, or au-

tomation ﬁelds. They focus on data interoperability

in terms of i) data syntax, ii) semantics, iii) and pro-

tocols. However, existing tools that allow to conﬁg-

ure and manipulate the speciﬁed data are inconsistent

(Andr

en et al., 2017). This thus constraints the stan-

dard’s complete adoption and integration by the in-

Kabbara, N., Grisot, T. and Cantenot, J.

Virtual61850: A Model-Driven Tool to Support the Design and Validation of Virtualized Controllers in Power Industry.

DOI: 10.5220/0012360600003645

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 12th International Conference on Model-Based Software and Systems Engineering (MODELSWARD 2024), pages 157-168

ISBN: 978-989-758-682-8; ISSN: 2184-4348

157

volved parties. Moreover, the heterogeneous tools of-

ten rely on non-formalized data which makes adopt-

ing an automated approach to manage the develop-

ment process more problematic.

A study from 2002 showed that over 22% of

human conﬁguration errors were observed in con-

ﬁgured control devices that are crucial for protect-

ing the power grid in case of faults (Lundqvist and

Aabo, 2002). The errors primarily included missing

or wrong data settings. A more recent study in 2020

by (Resch et al., 2020) showed that despite the tech-

nological advancement (and the existing often propri-

etary editing tools), the power industry is still highly

reliant on many manual, time-consuming, and error-

prone engineering efforts.

The tedious efforts are still especially noticed in

the case of 1) speciﬁcation developments, 2) conﬁg-

urations of communicating devices in substations, 3)

and data exchanges at the level of the grid control cen-

ter IT systems (Resch et al., 2020). Often, there is

a lack of inherent validations to identify early prob-

lems when conﬁguring local control devices. More

speciﬁcally, validations can be acted upon at three

distinct levels: 1) basic ﬁle format level, 2) basic

data elements and naming level, and 3) semantic level

for rich data interpretation (Marcadet and Lambert,

2016). For example, trivial tests such as the conﬁg-

ured connections of human-machine interfaces and

basic reachability tests still constitute an important

sum of the total solution costs due to the dedicated

manual resources needed (Resch et al., 2020).

Motivated by these issues, we propose to fur-

ther enhance the engineering process for new power

and control systems developments (based on the IEC

61850 standard) by adopting an MDE approach. The

main contribution of the paper is the implementation

of a novel model-driven tool for the development of

virtualized power system control command applica-

tions that supports existing standard data models.

The rest of the paper is organized as follows: Sec-

tion 2 presents the state of art of MDE in different in-

dustries. Section 3 speciﬁcally introduces the power

industry domain and its data model needs. Section 4

explains the concept of virtualized intelligent devices.

Section 5 introduces a high level functional descrip-

tion of the Virtual61850 tool. Section 6 presents the

implementation details and general architecture of the

tool. Section 7 details the evaluation of Virtual61850

by the creation and editing of instances based on real

industrial substation conﬁguration data models. Fi-

nally, section 8 concludes the study and its future

works.

2 STATE OF THE ART

Many researchers in various industries have previ-

ously studied the use of model-driven concepts for

improving application development efforts. The au-

thors in (Ledeczi et al., 2003) developed a modeling

framework based on a domain language for the sim-

ulation of embedded systems. The framework aims

to unify embedded application development by ab-

stracting the different tool formalisms and seman-

tics. (Ledeczi et al., 2003) developed metamodels

to capture the application design and dataﬂow (hard-

ware; functionality; mappings) where nonfunctional

requirements were added as model constraints using

the Eclipse Object Constraint Language (OCL) (OCL,

2023).

Similarly, (Corradini et al., 2022) proposed a

model-driven tool to reduce application development

efforts for heterogeneous Internet of things (IoT) plat-

forms. A graphical tool for the modeling and dynamic

management of Docker (Docker, 2023) containers

was developed by (Paraiso et al., 2016). The work

thus proposes a model-driven solution to abstract the

docker model and its execution environment based on

the Open Cloud Computing Interface (OCCI) (OCCI-

WG, 2023). Container topology is also validated with

Eclipse OCL constraints.

As for the power system industry, adopting a

model-driven approach based on the standardized

electrical grid data formats was argued by (Br

edillet

et al., 2010) as a key enabler for the smart grid vi-

sion. Authors in (Neis et al., 2019) developed a survey

on model-driven practices for power system control

applications including the software design (source),

code format (target), and their transformation process

(source/target). (Neis et al., 2019) observed the dom-

inance of power system-speciﬁc modeling techniques

(e.g. control theory) and the need for a transparent,

explicit methodology to transform speciﬁcations into

executable functional software. Most work was inter-

ested in proposing a comprehensive framework that

includes a static and functional speciﬁcation, espe-

cially for engineering control and automation appli-

cations.

3 DIGITAL ELECTRICAL GRID

DEVELOPMENTS AND

INFORMATION MODEL

NEEDS

The electrical grid is a cyber-physical system of sys-

tems with a hierarchy of control, monitoring, and

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

158

management. Its operation requires the streaming of

large amounts of data spread across distributed sens-

ing nodes (from large-scale power plants, distributed

energy resources (DERs), remote terminal units, etc.)

which must be accurately interpreted in real time. To

perform a seamless exchange of critical electrical grid

data, an equally complex information system is re-

quired. Currently, power system information systems

are managed by utilities and grid operators that most

often respect certain international standards.

However, correctly describing and conﬁguring

the necessary data (e.g., process, controller, primary

asset data) by different tools becomes a complex

task. Adopting a system-level and standards-based

approach for power system developments is thought

to reduce their overall lifecycle and operational costs

by 20% compared to the traditional siloed approach

(2019, 2019). To respond to these needs, the IEC in-

troduced different standards semantically deﬁned for

power systems: 1) IEC 61850 for power automation,

2) Common Information Model (CIM) for power sys-

tem operation and planning, and 3) IEC 62056 for me-

tering part (Marcadet and Lambert, 2016).

These standards aim to provide a more efﬁcient,

reliable, and safer power system where informa-

tion can be exchanged without lock-ins from propri-

etary deﬁnitions (CENELEC, 2012). An information

model in the context of power systems is a repre-

sentational set of real-world physical or logical com-

ponents (e.g. physical primary equipment, logical

functional applications, functional parametrizations,

etc) that need to be communicated to other system

parties (e.g. another device, human operator) in an

easily comprehensible format. A library of domain-

speciﬁc information models has been elaborated in

each standard. The libraries include common seman-

tic names used by power system actors with self-

describing meta-data covering system topology, mea-

surement location, etc.

The speciﬁed information can then be transmitted

to multiple devices or hosts with no additional map-

ping of essential meta-data (e.g. value, unit, scale,

etc.). These communicating devices are known per

IEC 61850-5 (IEC, 2013) as intelligent electronic de-

vices IEDs and can be deﬁned as: ”a device incorpo-

rating one or more processors with the capability to

execute application functions, store data locally in a

memory, and exchange data with other IEDs (sources

or sinks) over a digital link”.

VM1

Hypervisor

vIED

Bins/libs

Container1

vIED

Bins/libs

Guest OS

Bins/libs

Guest OS

VM2

Container

Engine

Compute

Network

Storage

vIED

Physical Server

IED

eth0

IEC 61850

Communication

Stack

Functional

Stack

eth1

Physical Server

IED

eth0

IEC 61850

Communication

Stack

Functional

Stack

eth1

Physical Server

IED

eth0

IEC 61850

Communication

Stack

Functional

Stack

eth1

Figure 1: Example of possible vIED architecture based on

virtual machines and containers.

4 VIRTUALIZATION OF IEDS

In the following subsections, the idea of IED virtu-

alization and the motivation for using MDE in vIED

developments are presented.

4.1 Context & Motivation

The traditional mode of deploying IEDs was on small

industrial physical servers. However, more recently,

the idea of virtualizing the IEDs and deploying them

in virtual machines (VMs) or containers has been a

rising research topic (seen in Figure 1) (Kabbara et al.,

2022). The advantages of such new deployment lie in

reducing the number of devices that need to be oper-

ated and managed and hence their capital and opera-

tional costs. Moreover, the well-established virtual-

ization environments and tools for Information Tech-

nology IT systems can be adjusted and reutilized for

virtual IEDs (vIEDs) management.

This includes remote accessibility and monitor-

ing, clones and backups, as well as redundancy and

recovery support. Also, the emulated environment of

VMs and containers provides the required conditions

to perform advanced simulations and tests of IEDs

including communication, data models, functionality,

etc. Despite these promising new features, the power

industry is often hesitant to integrate novel technolo-

gies that can easily scale into their existing (rather al-

ready functional and critical) information systems.

Moreover, power system engineers often have

limited knowledge of purely IT-based technology like

virtualization. Their knowledge of power system

communication and control also can’t be replaced by

IT experts on virtualization. This leads to more dif-

ﬁculties in coordinating the work of both parties as

in the case of vIEDs developments. Another concern

is the heterogeneity of the available tools that support

virtualization (e.g. VMWare (VMware, 2023), KVM

(RedHat, 2023), Docker (Docker, 2023), etc). The di-

Virtual61850: A Model-Driven Tool to Support the Design and Validation of Virtualized Controllers in Power Industry

159

versity of the different tools adds another layer of con-

fusion for power system experts trying to test vIEDs

where tool interoperability for large-scale information

systems becomes non-evident.

We claim that, up to our knowledge, there is still

no generic tool that supports the virtualization pro-

cess and conﬁguration of virtual IEDs. The main nov-

elty of this study is in facilitating the development and

adoption process of IED virtualization by developing

a new tool based on MDE principles.

The tool characteristics are:

• Platform independence from any speciﬁc virtual-

ization technology

• Supporting the existing IEC 61850 conﬁguration

language for IEDs

• Modularity to support cooperation between ex-

perts from different domains (Power systems, IT,

communications)

• Enhancing the testing and simulation process of

vIEDs by automating the generation of conﬁgura-

tion ﬁles necessary for vIED testing.

We note that the purpose of this study was not

to generate any application logic (low-level source

code); it is outside the scope of the described pro-

cess. Also, the initial focus was not on assuring or

benchmarking any real-time performance of the vIED

instances; the following study is limited to the data

modeling speciﬁcation level.

4.2 Relevant MDE Advantages for

vIED Developments

The conformance of an instantiated model to a partic-

ular meta-model can be easily validated thanks to pre-

deﬁned syntax (e.g. parsing) and semantic constraints

(based on domain rules). Another advantage pro-

vided by MDE is its separation between conceptual or

platform-independent models and platform-speciﬁc

models for implementations (code executables) (see

Figure 2). This separation, formally speciﬁed by the

Object Management Group (OMG) (Kleppe et al.,

2003; OMG, 2023), helps to increase application

portability and reduce development efforts and errors.

A seamless translation between platform-

independent and platform-speciﬁc models

(PIM/PSM) can be done by describing a set of

transformational rules with pre/post conditions. The

transformation target can itself be a model conform-

ing to an external (or the source) meta-model in the

case of a model-to-model transformation (M2M)

(QVTo, 2023) or can be a generated code in the case

of model-to-text transformation (M2T) (Czarnecki

and Helsen, 2006). There exists an open-source

community for MDE as part of the Eclipse foun-

dation, which has provided the Eclipse Modelling

Framework (EMF) Ecore (Eclipse-EMF, 2023) (im-

plemented in the Java programming language) with

several model transformation plugins (e.g. Acceleo

for M2T (Acceleo, 2023) and QVTo for M2M).

Ecore

QVTo

Acceleo

Creation of meta-model

M2M

Transformation

M2T

Transformation

Figure 2: MDE principle and strengths.

5 APPLICATION

FUNCTIONALITIES

The main idea was to implement a tool to support the

design and validation of virtualized control devices

for power grids. The objectives and criteria deﬁned

for Virtual61850 are described in Table 1. The overall

toolchain can be seen in Figure 3.

Mini-

DockerCompose

Services &

Networks

Virtualisation

M2M

Config File

Docker

Compose

Generation

M2T

SCL

Substation

Configuration

Language

IEC 61850

ResourceNode

Computational

Stack

TOSCA profile

NetworkNode

Internal

Network Stack

TOSCA profile

+ +

Wrapper

Simulated

networked

virtualized IEDs

Docker Engine

Physical Host

NIC

Compute

Network

Storage

vSwitch

vNIC

vBridge

L2 VLAN

Linux OS

Virtual

IED

Container

Linux OS

Virtual

IED

Container

Figure 3: MDE tool chain for IED virtualization followed

in Virtual61850 application.

5.1 Virtual61850 Models Integration

The application references various models that are es-

sential to our work on IED virtualization, as listed be-

low in Figure 4. Our speciﬁc workﬂow (the virtual-

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

160

Table 1: Objectives and criteria of the Virtual61850 appli-

cation.

Item Description

Objectives

O1 Model navigation, editing support;

O2 Import/export existing speciﬁcations (i.e.,

IEC 61850) into/from a common root

model;

O3 Model validations of syntax and semantic

(business) constraints;

O4 Automated model transformations to gen-

erate platform-speciﬁc conﬁgurations;

O5 Support the simulation and testing of the

generated conﬁguration topology on the

target platform;

O6 Reiteration to enhance the quality of the

utilized models and their representative in-

formation.

Criteria

C1 Ease of use with validated models;

C2 Modularity (partial) of the tool interface

to support new models and transformations

additions and modify existing ones;

C3 Scalability to support design and validation

of large model instances;

C4 Conformity to standard models.

ization of IEDs) requires dealing with several models:

SCL, ResourceNode, NetworkNode, and OpenAPI.

Thus, the user needs to manipulate several instances

related to different models.

• SCL (Substation Conﬁguration Language): a

model published as part of the IEC 61850 stan-

dard (IEC, 2013). it includes the functional de-

scription of the IEDs;

• ResourceNode: a model describing the comput-

ing resources available for the virtualization pro-

cess;

• NetworkNode: a model allowing to deﬁne a vir-

tual network stack between the various virtualized

elements;

• OpenAPI: a model that describes an API and can

be referenced from the ResourceNode, based on

the OpenAPI standard (LinuxFoundation, 2023);

• Wrapper: serves as a root model that groups

instances of SCL, ResourceNode, NetworkNode,

and the OpenAPI models;

• Mini-DockerCompose: a model that is a simpli-

ﬁed representation of the Docker Compose speci-

ﬁcation.

It is noted that both ResourceNode and Networ-

kNode models are solutions based on the existing

SCL

Sub-station Configuration

Language

IEC 61850

References

Resource Node

Virtualization Computing

Resource Definition

References

Network Node

Virtual Network Stack

Description

OpenAPI 2

Standard-based

API descriptor

Acceleo Transformation

Mini-DockerCompose

Simplified Interpretation of

Docker Compose spec.

References References

References

QVTo Transformation

References

Wrapper

Root model for user

operations simplification

YAML

Docker Compose

Configuration file

Figure 4: Models and transformations of the ”Virtualiza-

tion” process.

ETSI NFV TOSCA standard (ETSI, 2023). The ETSI

TOSCA models are specializations of the TOSCA

standard (OASIS, 2023) for network function virtual-

ization covering computing resource descriptors, in-

ternal and external connection points, links, and life-

cycle management and policy metadata. However, we

observed that the ETSI TOSCA model was too large

and complex to manipulate for our own needs.

The resource descriptors and virtual networking

elements were proﬁled and separated into individ-

ual smaller models (ResouceNode, NetworkNode).

The proﬁling was done manually by comparing the

IEC 61850 data model contents and ﬁlling the miss-

ing information that are critical for VM or container

deployments. This separation helped us better un-

derstand the TOSCA models and allowed us to jus-

tify some simpliﬁcations, eliminations, and power

domain-speciﬁc additions. For example, the elements

of the ETSI TOSCA model covering life-cycle man-

agement and policy were omitted. Also, the separa-

tion of virtual links and connections points CP into

internal and external ones was simpliﬁed to a single

generic link or CP. The relationship types were not ex-

plicitly modelled but represented within the inherent

model and meta-model relationships as per the uniﬁed

modelling language.

To simplify the handling of different instances,

it was decided to introduce a ”wrapper” model that

groups all the models within the same node. Using a

root model greatly simpliﬁes references between el-

ements of various instances. It avoids the need for

inter-document references that are both hard to man-

age from a developer’s point of view, as well as the

source of possible misunderstanding and issues for

the user due to multiple ﬁle manipulations.

The ﬁrst implementation targets the Docker plat-

form using Docker Compose speciﬁcation (Docker-

Compose, 2023). Docker-compose was chosen as a

proof of concept implementation due to its ease of use

and support for scalability. However, the modular-

Virtual61850: A Model-Driven Tool to Support the Design and Validation of Virtualized Controllers in Power Industry

161

ity developed within Virtual61850 allows it to target

other virtualization platforms in the future. This con-

tributes to the achievement of objective O5 of Table

5.2 Editor Behaviour

The application is built following the principles of a

classic editor. The user can load and save instances

of the various models from and to the ﬁle system, as

well as view and edit their contents. Model instances

are typically stored as XML ﬁles. The XML format,

although offers a robust structure, is difﬁcult to ma-

nipulate by humans. Thus, it was decided that upon

opening a ﬁle containing an instance of a model, the

user would be shown a clean tree view that focuses

on the instance’s structure and makes it easily under-

standable.

Along that, when the user selects an element of

the tree, the element’s properties are displayed as a

form in a separate view so that he can view and edit

the attributes and references of the selected element.

Figure 5 shows a typical state of the application in-

terface as described above. These editor functionali-

ties correspond to objective O1 of Table 1. It is also

important to note that when editing a model instance

through the editor, the syntax conformity to the sup-

ported domain standards is automatically ensured by

construction, thus ensuring criteria C4 of Table 1.

5.3 Instances Import/Export

Mechanism

Instances of the Wrapper model can become quite

large as virtualization projects become more complex.

Also, users might want to transfer only relevant in-

formation to some experts (i.e., network information

to telecom expert). Thus, the application provides an

import/export mechanism; it is possible to import and

export instances of SCL, ResourceNode, NetworkN-

ode, and OpenAPI models into and from an instance

of the Wrapper model. This mechanism is related to

objective O2 of Table 1.

5.4 OCL Validation

Model instance validation plays an important role in

speeding up the development process as it reduces hu-

man errors at the design stage. Eclipse EMF makes

it possible to deﬁne both business rules and seman-

tic constraints directly in the model, which can then

be checked for every instance of the corresponding

model. These constraints are deﬁned using OCL and

a tool is provided by EMF for validating instances.

The application thus embarks on the OCL valida-

tion functionality, meaning the user can select an in-

stance and validate it, that is, check all the business

rules on every object of the instance. The tool also

displays a report to the user so that he can obtain de-

tails on potential OCL rules violations, as well as ex-

port it to a text ﬁle if needed. An example of a val-

idation report produced by the application is shown

in Figure 5. This contributes to the achievement of

objective O3 of Table 1.

OCL validation is directly integrated into the ap-

plication. Each generated model code comes with a

special Java class called a validator, containing meth-

ods for validating objects related to all classes of the

model. When the user selects an object of an instance

and validates it, this object is validated as well as all of

its ”children”. The principle of the recursive strategy

is based on a depth-ﬁrst search approach (Goodrich,

2023).

/ / Make s u r e p o r t s e t h n bs ar e un i qu e

s e l f . p o r t s −>f o r A l l ( e1 , e2 | e1<> e2

i m p l i e s e1 . e th

n u mb er <> e2 .

e th n um b er )

/ / Max nb o f p o r t s p er Co nn ec tio nN od e

p o r t s −>s i z e ( ) < 12

/ / O n ly L2 or L3 Data v a l u e s a t t h e same

t i m e

s e l f . l 2 p r o t o c o l d a t a −>n otEmpty ( )

i m p l i e s s e l f . l 3 p r o t o c o l d a t a −>

is Em pt y ( )

s e l f . l 3 p r o t o c o l d a t a −>n otE mpty ( )

i m p l i e s s e l f . l 2 p r o t o c o l d a t a −>

is E m pt y ( )

/ / O n ly one a d d r e s s a t t h e same t i m e

a d d r e s s −>notE mpt y ( ) i m p l i e s g o o s e s e −>

is E m pt y ( ) and smv−>i sE m p ty ( )

g o o s e s e −>notEmp ty ( ) i m p l i e s a d d r e s s −>

is E m pt y ( ) and smv−>i sE m p ty ( )

Listing 1: Examples of OCL constraints on the Wrapper

model.

6 IMPLEMENTATION

To implement the various functionalities described

above, it has been decided to develop a heavy client

(also called rich client). Eclipse EMF provides

the Eclipse Rich Client Platform (RCP) framework,

which ﬁts to our needs. RCP also relies on a model-

driven approach for building complete graphical in-

terfaces.

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

162

Properties of selected objectInstance tree view

Instance validation report

Figure 5: Interface of the Virtual61850 application.

6.1 General Architecture

The framework provides a context system coupled

with dependency injection to enhance the ability to

separate an application’s components into various

dedicated services. The use of such a framework

helps speed up the development of our proof-of-

concept application, and its native compatibility with

the various Eclipse tools simpliﬁes implementation.

Models are designed using Ecore, a meta-model

that is the central component of EMF. Ecore is capa-

ble of generating model code for the Java language,

which can then be used in our application to easily

manipulate instances of various models. When gen-

erating model code, Ecore can also generate utility-

related classes like the Resource Factory that make

it possible to persist model instances to the ﬁle sys-

tem in the form of XML ﬁles and load these instances

back by parsing the XML content.

Our application needs to display information

about the instances the user wants to edit, that is, some

kind of view model or forms. Creating forms for edit-

ing an object’s properties can be a tedious task espe-

cially when models contain dozens of classes, with

each class potentially containing multiple attributes

and references. To speed up this process, EMF

provides the EMF Forms framework (Eclipse-EMF,

2023), which automatically generates view models

from the model deﬁnition ﬁle (an instance of the

Ecore meta-model) that can be customized using a

graphical editor.

Generated view models are compatible with mul-

tiple graphical libraries and can be easily integrated

into our Eclipse RCP application, as shown in the Ob-

ject Properties part of Figure 5. The following para-

graphs describe the implementation choices that allow

partial modularity and extensibility of the application

covering criteria C2 of Table 1.

6.2 Models and Transformations

Integration

The application needs to handle all parts of the root

Wrapper model. Internally, the application uses an

enumeration to keep track of all managed models.

This enumeration contains important ﬁelds related to

the model, such as the human-readable name, and the

root class of the model. Also, it contains the corre-

sponding object validator (used for OCL validation)

or the resource factory by generating or parsing the

data instances.

This system is a ﬁrst step towards a fully modular

Virtual61850: A Model-Driven Tool to Support the Design and Validation of Virtualized Controllers in Power Industry

163

model integration as described in criteria C2 in Table

1. This contributes to the achievement of objective O4

of Table 1. It is possible to add new supported mod-

els, but this must be done manually, that is, by adding

an item to the corresponding enumeration. Any newly

added model is automatically compatible with the ed-

itor, that is, the application becomes fully capable of

opening instances of this model, validating instances

(if OCL rules are deﬁned), and executing transforma-

tions that are compatible with it.

6.2.1 M2M Transformation

QVTo is a model transformation language that is in-

cluded in the EMF. It is used for specifying and

executing model transformations, which consists of

transforming an instance of a model into an instance

of another model, which is a process that is very fre-

quently used in the context of MDD. QVTo uses a

high-level declarative syntax for expressing transfor-

mation rules and is based on the OMG QVT speciﬁ-

cation which ensures interoperability and consistency.

Every QVTo transformation starts by referencing

the models that it needs to handle. Then, we deﬁne

the signature of the transformation that is, its input

and output and its main entry point in the main func-

tion. The mapping function for creating Docker ser-

vices from a Wrapper model are seen in Listing 1.

Deployments are more complicated to determine

because we need to navigate in the NetworkNode in-

stance of the Wrapper in order to determine the vir-

tual connection points that are associated with our

ResourceNode image. For each connection point, we

create a container for the service by using the toDock-

erContainer mapping function.

m o d e l t y p e WRAPPER ” s t r i c t ” u s e s w r a p p e r

( ’ . . . ’ ) ;

m o d e l t y p e MINI DOCKER COMPOSE ” s t r i c t ”

u s e s miniDocke r Compos e ( ’ . . . ’ ) ;

m o d e l t y p e RESOURCE NODE ” s t r i c t ” u s e s

r e s o u r c e N o d e ( ’ . . . ’ ) ;

m o d e l t y p e NETWORK NODE ” s t r i c t ” u s e s

net w or k No de ( ’ . . . ’ ) ;

mapping re s o u r c e N o d e : : Image : :

t o D o c k e r S e r v i c e ( ) : S e r v i c e {

r e s u l t . name : = s e l f . name ;

r e s u l t . v e r s i o n : = ” 1 ” ;

r e s u l t . ima ge := s e l f −>map

to D o c k e r I m a g e ( )−> s e l e c t O n e (

miniDoc kerCom pose : : Image ) ;

r e s u l t . d e p l o y m e n t s : = i n p u t .

r o o t O b j e c t s ( ) [ Wrapper ] .

net w or k No de .

v i r t u a l C o n n e c t i o n P o i n t s −>

s e l e c t ( vcp | vcp .

d e p l o y e d I m a g e = s e l f )−>map

t o D o c k e r C o n t a i n e r ( ) ;

}

Listing 2: QVTo M2M transformation example from

Wrapper resourceNode to miniDockerCompose models.

An instance of the SCL model contains the def-

inition of the various IEDs installed in a substation.

Each of these IEDs must be virtualized, consequently,

we need to create a ResourceNode instance in which

we deﬁne a VM or container image for each IED. A

simple transformation that generates a pre-initialized

ResourceNode instance was created. Along with cre-

ating instances of the Image class, it also pre-ﬁlls in

some attributes to speed up development and help us

support scalability.

6.2.2 M2T Transformation

Acceleo is a M2T transformation language tool that

is used to generate textual artifacts such as source

code, documentation or conﬁguration ﬁles from mod-

els. Acceleo allows you to deﬁne templates and rules

that specify how to transform model instances into

text output.

Automatically generating Docker Compose

YAML conﬁguration ﬁles from an instance of the

Mini-DockerCompose model supports an iterative

development process, where models can be improved

based on feedback and testing. Changes to the models

can then be easily propagated by re-generating code,

for example. The principle of the transformation

mainly relies on generating the correct YAML tree

for Docker Compose conﬁguration ﬁles with all

possible data found in the Compose instance. In

case the Mini-DockerCompose instance contains at

least one network, we write the networks’ top-level

element. Then, for each network, we add an entry

to this element which corresponds to the name

of the network. Eventually, we add another layer

with the properties of the corresponding network.

Similar code is used for deﬁning Docker volumes and

conﬁgs.

[ t e m p l a t e p u b l i c g e n e r a t e E l e m e n t (

compose : Compose ) ]

[ comment @main / ]

[ i f ( compose . n e t w or k s −>s i z e ( ) > 0 ) ]

n e t w o r k s :

[ f o r ( n e t w o r k : Network | compose .

n e t w o r k s ) ]

[ n e t w o r k . name / ] :

[ f o r ( p r o p e r t y : P r o p e r t y | n e t w o r k .

p r o p e r t i e s ) ]

[ p r o p e r t y . key / ] : [ p r o p e r t y . v a l u e / ]

[ / f o r ]

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

164

[ / i f ]

Listing 3: Acceleo M2T transformation example from

miniDockerCompose models to .yml conﬁg ﬁle.

6.3 Internal Services Modularity

Various features of the application were implemented

using a service system, that is, an implementation

that is separated in a dedicated package. This is the

case for functionalities such as OCL validation, QVTo

and Acceleo transformations executors, instance per-

sistence, and the embedded program launcher. Each

service can be used in any part of the application by

using the dependency injection mechanism combined

with Eclipse context annotations. This contributes to

the achievement of objective O6 of Table 1.

Validation Severities

Highlighting System

Preferences

Service/Page

Preferences

Item

Item Serialization

Factory

Hidden Classes

Service

Hidden Classes

Page

Hidden Class

Serial. Factory

Interfaces

DIA

Service

DIA

Page

Default Identifier

Attribute

DIA

Serial. Factory

VSH

Service

VSH

Page

Validation Severity

Highlighting

VSH

Serial. Factory

User Preferences Enumeration

Hidden Classes System

Default Identifier Attributes

System

Figure 6: User Preferences system overview.

6.4 Extensible User Preferences System

The application provides a simple user preferences

system so that the user can customize how the appli-

cation behaves. As shown in Figure 6, three prefer-

ences have been implemented: 1) the possibility to

hide certain classes in the instance tree view, 2) cus-

tomizing which attributes are used to display a name

in the instance tree view, and 3) how validation errors

and warnings are highlighted.

The RCP framework provides a way to persist

data across application launches called persisted state,

which our implementation uses to store user prefer-

ences. However, the only way to store data is by us-

ing key-value pairs, both the key and the value be-

ing strings. We could have decided to implement our

own user preferences persistence system, but using a

mechanism that is directly integrated within Eclipse

RCP was much simpler and less time-consuming.

In case one wants to store objects and not only

primitive types, it is thus necessary to implement a se-

rialization system. One important and useful aspect of

the Eclipse preferences system is the notion of scope.

The application uses two different scopes: the default

scope which is useful for providing a default initial

conﬁguration, and the instance scope which contains

the actual user preferences. This system mainly re-

lies on one class and two interfaces that are described

below.

• Preferences Manager: This class is in charge of

providing a standard way to access, store, and

delete key-value pairs in the preferences. As the

Eclipse preferences system works using a node

tree, each preferences type stores its data in a spe-

ciﬁc and exclusive node. The class implements

three main methods: get, put, and remove. It is

capable of accessing both the default and instance

scope.

• Preferences Item Serialization Factory: This is

an interface that is used to implement the seri-

alization factory for each preferences item type.

This is where the programmer implements the se-

rialization mechanism. It deﬁnes three methods:

getInstance (this is intended to be a singleton),

serialize and unserialize.

• Preferences Item: This is an interface that is used

to implement all preferences items. It only de-

ﬁnes one method serialize that generally just

calls the serialize method from the correspond-

ing preferences item serialization factory.

6.5 Embedded Java Programs

Sometimes our users might need to use external tools.

In the case of our ”Virtualization” process, users may

need to use a Java program called ”Genconﬁg” pro-

vided as a *.jar ﬁle. This program is used to gen-

erate additional conﬁguration ﬁles for the IEC 61850

communication of IEDs based on the SCL instances

(.scd ﬁles) (MzAutomation, 2023). The *.jar ﬁle

has been included in the application’s resources and

is executable by the user from the interface.

The application source code contains an enumer-

ation that holds items that reference each embedded

Java program. It contains all the information needed

to execute the program including its name and how to

retrieve the parameters from the user.

The application integrates a service, the Em-

bedded Program Launcher, that is responsible for

Virtual61850: A Model-Driven Tool to Support the Design and Validation of Virtualized Controllers in Power Industry

165

prompting the user for the various parameters re-

quired by the program (as deﬁned in the enumeration

item) and then launching the execution of the program

using the provided parameters. A new separate pro-

cess is created alongside the application, which can

be interrupted at any time by the user. The service

also reports back any errors that might occur during

the program’s execution.

7 PoC EVALUATION

The Virtual61850 tool was ﬁrst utilized for basic

testing purposes of different sets of instances. Vir-

tual61850 source code builds (Linux and Windows),

manuals, and test example public data have been

anonymously archived on the public Zenodo page.

We invite the reviewers to view and test our appli-

cation by following the tutorial found on Zenodo

7.1 Instance Example

The stability and ease of use of the application as per

criteria C1 were observed. In general, we noticed a

very stable performance for the Windows build ver-

sion while the Linux build had some minor instability

(originating from Eclipse for Linux).

Figure 7 shows an example from the start to end

conﬁguration ﬁle generated. The process starts by im-

porting an existing SCD ﬁle describing the communi-

cation interfaces and data model of the IED as per

IEC 61850. Both generic (non-real) SCD ﬁles and

real scd ﬁles from a digital substation commissioning

project were included. Each IED was mapped to an

image with its appropriate resource and network de-

scriptions within a Wrapper model.

The editor allows to perform a navigation of

the model thanks to a tree view. We note that in

real digital substations, a system topology with over

200 vIEDs can be needed. The time to create a

proper instance is hence signiﬁcantly reduced com-

pared to manual manipulations. The M2M transfor-

mation maps each image to a service to be ran. Fi-

nally, an M2T transformation allows us to generate

the platform-speciﬁc conﬁguration, which in our case

was a docker-compose YAML ﬁle, that can be used

by the power system engineer for further testing the

vIEDs’ environment and their performance.

anonym. (2023). Virtual61850 application. Zenodo.

https://zenodo.org/records/10041282

7.2 Application Quantitative Analysis

In order to evaluate the performances of the devel-

oped application, we ran several benchmarks each re-

lated to a speciﬁc metric. Two major metrics were

identiﬁed including instance size and validation time.

These metrics can help us determine how well criteria

C1 from Table 1 is considered.

Each metric presented in Tables 2 and 3 is the

average of 10 samples. A sample is created by

launching the application, opening a speciﬁc ﬁle, and

eventually executing a transformation. All samples

were produced on a machine with a 1.60 GHz Intel

Core i5-8265U processor, 8 GB 1800 MHz DDR3

memory running on Windows 10 Enterprise version

10.0.19045 and OpenJDK 17.0.6.

7.2.1 Handling Large-size Instances

In the context of our motivating example, in-

stance ﬁles can become as large as a few hundred

megabytes in the case of large substation commis-

sioning projects. Thus it is interesting to evaluate

how our application behaves in these cases as per the

requested criteria C3 in Table 1. Table 2 below de-

scribes the results we obtained in terms of memory

consumption in various scenarios. For each scenario,

the application is either in an idle state or with a single

opened instance or ﬁle of the speciﬁed size.

These results show that as the manipulated in-

stance grows in size, the memory consumption grows

as well but in a more pronounced way (for instance,

opening a 1 MB instance uses 34 MB). This growing

factor seems to decrease as the instances become big-

ger: only 610 MB is used for a 50 MB instance, so

a factor of 12. In the case of ﬁles, the memory con-

sumption also increases although approximately half

as much as for instances. Again, as ﬁles become big-

ger, the memory consumption factor becomes smaller.

From a user point of view, manipulating large-size

instances should not be a real issue, as the memory

consumption stays at an acceptable level when edit-

ing instances of a few dozen megabytes. However, it

is argued that the benchmarking has only been con-

ducted for instances with limited and restricted model

sizes. Therefore, the current results are not yet gener-

alizable to larger instances.

7.2.2 Validation Time

Another challenge when dealing with large-size in-

stances is the duration of the OCL validation. As it

is a critical feature of our application, it is important

that it can stay usable when working with instances

of several hundred megabytes. Table 3 displays the

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

166

Mini-DockerCompose

generated

YAML config

Initial Wrapper Model

M2M

Transformation

QVTo

M2T

Transformation

Acceleo

Figure 7: Instance example of Wrapper model transformed into miniDockerCompose through M2M and a .yaml conﬁg ﬁle

with M2T by importing an existing SCD ﬁle.

Table 2: Memory usage in typical scenarios.

Scenario Memory / Idle

Idle 225 MB //

1 MB instance 259 MB + 34 MB

18 MB instance 583 MB + 358 MB

50 MB instance 835 MB + 610 MB

1 MB ﬁle 237 MB + 12 MB

10 MB ﬁle 299 MB + 74 MB

100 MB ﬁle 864 MB + 639 MB

execution times measured in various scenarios with

instances of different sizes. In general, the validation

times are highly dependant on the number and time of

constraints under test. The results obtained were for

the Wrapper model with increasing number of con-

straints as the size of instance increases. We note that

the validation times are relatively acceptable for our

proof of concept study, but merit further optimization

to obtain a more rapid toolchain behaviour.

Table 3: OCL validation duration in typical scenarios.

Scenario Validation Time

1 MB instance 0.40 s

10 MB instance 2.02 s

18 MB instance 4.01 s

50 MB instance 6.61 s

8 CONCLUSION

This paper presented how a Model-Driven Engineer-

ing approach could be beneﬁcial for facilitating the

adoption of virtualized controllers by the power in-

dustry. Virtual61850, a proposed tool for editing

and conﬁguring virtualized power controller instances

was detailed and benchmarked based on some indus-

trial requirements. These requirements include plat-

form independence, legacy standards support, valida-

tion times and error reductions, as well as scalability

and support of large instances.

A graphical interface used as a proof-of-concept

tool editor for conﬁguring virtualized controllers was

developed. It is based on Eclipse EMF and integrates

various models (61850 communication, resources,

and networking descriptors, OpenAPI) as well as val-

idation and transformation engines (based on OCL,

QVTo, and Acceleo technologies). The application

provides a set of functionalities that satisfy the var-

ious objectives regarding model editing, validation,

and transformations (O1..O6) initially set, and has

been designed to be easily extensible for future de-

velopments, following a modularity logic as speciﬁed

by criteria C2.

The validation by design capabilities can prevent

conﬁguration errors from an early design stage of the

development process. This is highly useful when in-

tegrating and testing new concepts as virtualized con-

trollers within a well deﬁned and iterative toolchain

process. Also, the possibility of supporting scalable

large instances was validated thanks to measuring

both memory consumption from the application and

validation time.

Future works include implementing a tool to syn-

chronize between the model environment and the

Docker Engine API so that the user can simulate the

virtualized controllers directly from the application.

Additional Model-to-Model transformations allowing

users to virtualize controllers using virtual machines

or other virtualization technologies can be added to

adapt to multiple platforms. Also, the multi-threaded

OCL validation mechanism can be reworked by im-

Virtual61850: A Model-Driven Tool to Support the Design and Validation of Virtualized Controllers in Power Industry

167

plementing a thread pool and load balancing system

to precisely adjust the number of threads and address

the unbalanced tree issue. Finally, it is possible to

support a mechanism that could convert instances cre-

ated using an old version of a model to instances com-

patible with the newest version of this model. This en-

courages even further the iterative development prin-

ciple.

REFERENCES

2019, I. E. R. (2019). Standards pour les smartgrids itech

edf r&d e. lambert.

Acceleo (2023). Acceleo. https://wiki.eclipse.org/

Acceleo/Getting_Started.

Andren, F., Strasser, T., Rohjans, S., and Uslar, M. (2013).

Analyzing the need for a common modeling language

for Smart Grid applications. In 2013 11th IEEE In-

ternational Conference on Industrial Informatics (IN-

DIN), pages 440–446, Bochum, Germany. IEEE.

Andr

en, F., Strasser, T., and Kastner, W. (2017). Engineer-

ing Smart Grids: Applying Model-Driven Develop-

ment from Use Case Design to Deployment. Energies,

10:374.

edillet, P., Lambert, E., and Schultz, E. (2010). Cim,

61850, cosem standards used in a model driven inte-

gration approach to build the smart grid service ori-

ented architecture.

CENELEC (2012). Smart grid coordination group smart

grid reference architecture.

Clark, T., Sammut, P., and Willans, J. (2015). Applied

Metamodelling: A Foundation for Language Driven

Development (Third Edition). arXiv:1505.00149 [cs].

Corradini, F., Fedeli, A., Fornari, F., Polini, A., and Re, B.

(2022). X-IoT: a model-driven approach for cross-

platform IoT applications development. In Proceed-

ings of the 37th ACM/SIGAPP Symposium on Applied

Computing, Virtual Event. ACM.

Czarnecki, K. and Helsen, S. (2006). Feature-based survey

of model transformation approaches.

Docker (2023). Docker inc. https://www.docker.com/.

Docker-Compose (2023). Docker compose. https://

docs.docker.com/compose/.

Eclipse-EMF (2023). Eclipse emf forms. https://

eclipse.dev/ecp/emfforms/.

ETSI (2023). Etsi-nfv-sol001. https://forge.etsi.

org/rep/nfv/SOL001.

Goodrich, M. T. (2023). Depth-ﬁrst search.

https://www.ics.uci.edu/

goodrich/teach/

cs260P/notes/DFS.pdf.

IEC (2013). Communication networks and systems for

power utility automation – part 5: Communication re-

quirements for functions and device models.

IEC (2020). Communication networks and systems for

power utility automation – part 7-1: Basic commu-

nication structure – principles and models. In IEC TR

61850.

Kabbara, N., Nait Belaid, M. O., Gibescu, M., Camargo,

L. R., Cantenot, J., Coste, T., Audebert, V., and

Morais, H. (2022). Towards software-deﬁned protec-

tion, automation, and control in power systems: Con-

cepts, state of the art, and future challenges. Energies.

Kent, S. (2002). Model driven engineering. In International

conference on integrated formal methods, pages 286–

298. Springer.

Kleppe, A., Warmer, J., and Bast, W. (2003). MDA Ex-

plained: The Model Driven Architecture: Practice

and Promise.

Ledeczi, A., Davis, J., Neema, S., and Agrawal, A. (2003).

Modeling methodology for integrated simulation of

embedded systems. ACM Transactions on Modeling

and Computer Simulation.

LinuxFoundation (2023). Openapi. https://www.

openapis.org/.

Lundqvist, B. and Aabo, Y. (2002). The cost beneﬁt of mod-

ern Substation Automation in Electrical High Voltage

Installations, abb automation.

Marcadet, D. and Lambert, E. (2016). Riseclipse: Why

working at the model level is better for validating data

conforming to iec standards. In 2016 Power Systems

Computation Conference (PSCC).

MzAutomation (2023). lib61850. https://github.com/

mz-automation/libiec61850.

Neis, P., Wehrmeister, M. A., and Mendes, M. F. (2019).

Model Driven Software Engineering of Power Sys-

tems Applications: Literature Review and Trends.

7:177761–177773.

OASIS (2023). Oasis-tosca. http://docs.oasis-open.

org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.

html.

OCCI-WG (2023). Occi. https://

2020.standict.eu/standards-watch/

occi-12-open-cloud-computing-interface-%

E2%80%93-infrastructure.

OCL (2023). Ocl. https://projects.eclipse.org/

projects/modeling.mdt.ocl.

OMG (2023). Meta-modeling and the omg meta ob-

ject facility (mof). https://www.omg.org/ocup-2/

documents/Meta-ModelingAndtheMOF.pdf.

Paraiso, F., Challita, S., Al-Dhuraibi, Y., and Merle, P.

(2016). Model-Driven Management of Docker Con-

tainers. In 2016 IEEE 9th International Conference

on Cloud Computing (CLOUD). IEEE.

QVTo (2023). Qvto. https://projects.eclipse.org/

projects/modeling.mmt.qvt-oml.

RedHat (2023). Kvm. https://www.linux-kvm.org/

page/Main_Page.

Resch, J., Schuiki, B., Sch

ondorfer, S., Brandauer, C.,

Panholzer, G., Pr

ostl Andr

en, F., and Strasser, T. I.

(2020). Engineering and validation support frame-

work for power system automation and control appli-

cations. (8).

VMware (2023). Vmware. https://www.vmware.com/

fr.html.

MODELSWARD 2024 - 12th International Conference on Model-Based Software and Systems Engineering

168