TRILATERAL: Software Product Line based Multidomain IoT Artifact

Generation for Industrial CPS

Aitziber Iglesias, Markel Iglesias-Urkia, Beatriz L

opez-Davalillo, Santiago Charramendieta

and Aitor Urbieta

IK4-Ikerlan Technology Research Centre, Information and Communication Technologies Area, P. J. M. Arizmendiarrieta,

2, 20500, Arrasate-Mondrag

on, Spain

Keywords:

Internet of Things, Cyber-Physical System, Domain Speciﬁc Language, Software Product Line, IEC 61850.

Abstract:

Internet of Things (IoT) devices are usually advanced embedded systems that require functionalities monitor-

ing and control. The design, development and validation of these devices is complex, even more when com-

munication capabilities need to be included. In industrial environments, where safety is of critical importance,

reducing this complexity can help to achieve the vision of Industry 4.0 by reducing development time and costs

as well as increasing quality. To this end, the use of Model-Driven Engineering (MDE) methodology and the

Software Product Line (SPL) paradigm is becoming increasingly important as they help to accelerate and ease

the development of software, while reducing bugs and errors. Thus, in this work we present TRILATERAL, a

SPL Model Based tool that uses a Domain Speciﬁc Language (DSL) to allow users to graphically deﬁne the

IEC 61850 information model of the Industrial Cyber-Physical System (ICPS). TRILATERAL automatically

generates the source code for communicating devices with the monitoring framework, also supporting a vari-

ety of communication protocols, namely HTTP-REST, WS-SOAP and CoAP in order to control/monitor any

ICPS. In addition, the solution was evaluated deploying it in different industrial domains (Wind Farm, Smart

Elevator, Catenary-free Tram) from which we gained important lessons.

1 INTRODUCTION

Industry 4.0 is playing an important role in many in-

dustrial domains, such as Smart Grids, Smart Man-

ufacturing and Smart Logistics (Leit

ao et al., 2016;

Suri et al., 2017). This paradigm involves the tech-

nical integration of Cyber-Physical Systems (CPS)

along with the use of the Internet of Things (IoT) in

industrial processes (Kagermann et al., 2013). IoT

devices in industrial scenarios are embedded devices

that usually have advanced requirements in terms

of monitoring and control (Tao et al., 2014). CPS

are “integrations of computation with physical pro-

cesses. Embedded computers and networks moni-

tor and control the physical processes” (Kagermann

et al., 2013). In Industry 4.0, the monitoring and

control of Industrial CPS (ICPS) is becoming essen-

tial, as it allows to control it from outside the ICPS

and enable automated analysis, decision making, and

anomaly detection. Thus, monitoring and control-

ling enables the transition of a traditional industrial

system towards an ICPS. The number of devices an

ICPS can have is high, and capturing data and be-

ing aware of the state of the ICPS during operation

is important (Iglesias et al., 2018). In these scenarios,

IoT communication protocols make the communica-

tion between the stakeholder and the ICPS possible.

Each stakeholder has different needs, hence, monitor-

ing/controlling systems and IoT communication pro-

tocols must be adapted.

For this reason, IoT communication protocols will

vary according to the stakeholder’s needs or due to the

industrial environment. Likewise, every ICPS is com-

posed by different devices even if they are from the

same domain. Therefore, in industrial environments,

where safety is of critical importance, reducing com-

plexity of the design, development and validation can

help to achieve the vision of Industry 4.0. In this man-

ner, development time and costs are reduced while in-

creasing quality. Thus, Software Product Line (SPL)

paradigm can be beneﬁcial to improve productivity

and reduce costs (Capilla et al., 2014). In addition, a

Domain Speciﬁc Language (DSL) promotes effective

communication with stakeholders thanks to the sim-

pliﬁcation of complex codes (Fowler, 2011). Thanks

to DSL, the ﬂexibility of a system is improved in ad-

Iglesias, A., Iglesias-Urkia, M., López-Davalillo, B., Charramendieta, S. and Urbieta, A.

TRILATERAL: Software Product Line based Multidomain IoT Artifact Generation for Industrial CPS.

DOI: 10.5220/0007343500620071

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 62-71

ISBN: 978-989-758-358-2

dition to providing a more immediate response to the

stakeholder (Kelly and Tolvanen, 2008), and with a

SPL users can produce speciﬁc systems by reusing

common elements and conﬁguring the variability.

In order to transfer ICPS data via IoT, we analyzed

an international standard, IEC 61850. The Interna-

tional Electrotechnical Commission (IEC) deﬁned the

IEC 61850 standard (TC-57, 2003) to model, control

and monitor electrical substations. The standard de-

ﬁnes a Basic Information Model, services to interact

with it, and some recommendations for the use of dif-

ferent communication protocols. It is divided in dif-

ferent parts for general speciﬁcations, conﬁguration,

deﬁning the model and communications, and testing.

In the Industry 4.0 context, the needs of stakehold-

ers and industry to control and monitor an ICPS have

to be taken into account to provide a common solu-

tion, both in terms of devices and communications.

That is why in this paper TRILATERAL (sofTware

pRoduct lIne based muLtidomain iot ArTifact gEner-

ation for industRiAL cps) is presented, a tool to join

IEC 61850, Industry 4.0 (including IoT and CPS),

and SPL. TRILATERAL is a Model Based Engineer-

ing (MBE) tool using the IEC 61850 standard, SPL

paradigm and DSL. Thanks to our solution, the user

can graphically conﬁgure IoT communication proto-

cols (HTTP-REST, WS-SOAP and CoAP) and the

tool automatically generates the source code accord-

ing to the conﬁguration. The code allows to transmit

data between the cyber and the physics part in order

to monitor/control a ICPS.

The rest of this paper is organized as follows.

The next section introduces the problem while Sec-

tion 3 summarizes the technical background explain-

ing the IEC 61850 standard. Section 4 presents the

used IoT protocols and TRILATERAL for generating

code based on the model, followed by three industrial

use cases where TRILATERAL is used. Section 5 de-

scribes the lessons learned during the development of

the tool and deployment of the ICPS. Next, we present

the related work to ﬁnally conclude the paper with

some conclusions and future lines for continuing the

work.

2 USE CASE ANALYSIS

Thanks to the proximity of our institution to the in-

dustrial reality, it is possible to know the necessities

of different industrial domains. Thus, considering the

domain analysis fulﬁlled in the previous work (Igle-

sias et al., 2017), we realize that different domains

have common needs (i.e., monitor a ICPS to capture

information with the ﬁnal goal of being aware of the

state of the industrial domain) due to the important

role that Industry 4.0 is playing. Although a common

monitoring solution was a real need, when analyzing

other industrial domains, i.e., Smart Elevators (Sec-

tion 2.2), Wind Farms (Section 2.1) and Catenary-

free Trams (Section 2.3), we realized that variability

in IoT communications exists, i.e., how to commu-

nicate the devices (physical systems) with the soft-

ware platform that monitors/controls the devices (cy-

ber system), which was not considered in our previous

work.

We noticed that depending on the industrial needs,

the IoT communications are different, e.g., CoAP is

more lightweight but for large payloads the overhead

can be bigger than HTTP-REST (Iglesias-Urkia et al.,

2018). Additionally, we realize that for some do-

mains using more than one communication protocol

can be beneﬁcial (e.g. Catenary-free Tram, Section

2.3). That is why a new challenge was found after an-

alyzing these three domains, being entirely applica-

ble to other domains such as automated warehouses

or press machines.

Considering that the SPL paradigm shows poten-

tial to improve productivity and reduce costs when

variabilities and commonalities exist (Capilla et al.,

2014; Iglesias et al., 2017), we consider important and

necessary to use this paradigm to provide a solution

to our challenge. Therefore, a SPL was designed and

developed to give the user the opportunity to conﬁg-

ure different IoT communication protocols. Likewise,

with the purpose of improving this conﬁguration, a

DSL was created, because it provides simplicity as

well as ﬂexibility when making the necessary conﬁg-

urations (Fowler, 2011; Hussain et al., 2018).

Taking into account the need to use different IoT

communication protocols to communicate the physi-

cal world with the cyber world, we analyzed an inter-

national standard, IEC 61850. This standard has also

showed being valuable for other industrial domains

outside electrical substations, such as Press Machines

or Automated Warehouses (Iglesias et al., 2017).

2.1 Wind Farm

In a Wind Farm, wind turbines generate energy using

wind. These need to be monitored, to know in real

time how much energy they are generating. As they

are critical infrastructures that can create huge prob-

lems if they fail, different parameters have to be mon-

itored to ensure safety. To this end, it is necessary to

represent the particular features in every wind turbine

that exist in a speciﬁc wind farm. Thus, variability

exist and generating code for every use case is time

consuming.

TRILATERAL: Software Product Line based Multidomain IoT Artifact Generation for Industrial CPS

In addition, Wind Farms are usually located in re-

mote locations, where wind is stronger or more con-

stant. They are located far from cities, on top of

mountains or offshore, places where connectivity can

be limited. The environment is not mobile, but to be

able to connect to the Internet, heavyweight protocols

can be a handicap.

2.2 Smart Elevator

In a big building there are several elevators, and a sys-

tem can be created to control and monitor the eleva-

tors, and make a more efﬁcient use of them. Cur-

rently, some elevators are equipped with batteries.

The energy generated when the elevator is moving

down is stored for its later use to improve the ener-

getic efﬁciency of the building (stored energy is re-

leased when energy cost is more expensive). In this

case, if we are able to monitor and control the bat-

teries in each elevator, we will be able to make deci-

sion, i.e., it allows us to remotely monitor the state of

the different energy storage resources and to activate

them when necessary.

Note that elevators are located inside buildings,

therefore, a controlled environment. This controlled

environments do not usually have connectivity or en-

ergy supply issues, thus, the constraints on the com-

munication protocols are not as severe as in other sce-

narios.

2.3 Catenary-free Tram

Any transportation system has different parameters

to monitor its state, from critical parameters such as

speed, direction or maintenance related information

(e.g., state of the power source, break wear, etc.) to

non critical systems such as information or multi-

media features, or climate systems. Hence, an efﬁ-

cient energy system needs to be developed in order to

charge trams via induction on stops and to control the

amount of energy needed to reach the next stop (con-

trolling the climate system to optimize the amount to

charge the tram in each stop). Thus, we can operate

autonomously, without human intervention.

In this scenario, two different use cases need to be

taken into account. On the one hand, when the tram

is ongoing, the environment is mobile and can have

power or connectivity limitations. On the other hand,

the tram can bulk much more information when it is

on a station or a stop, while charging or not, where the

aforementioned constraints are not applicable. How-

ever, since the Tram has to follow a schedule, the time

for bulking the data is limited, so the data transfer

time must be taken into account.

3 TECHNOLOGICAL

BACKGROUND

To model the intelligent electronic devices at electri-

cal substations, IEC 61850 makes use of two build-

ing classes, i.e., Basic Information Model and Con-

trol Blocks (CB) for additional functions. The Ba-

sic Information Model deﬁnes the elements of the

real world and deﬁnes their information with a sim-

ple structure:

• Server: exposes systems to the outside and in-

cludes one or more Logical Devices (LDs).

• Logical Device: virtual representation of a real

device, composed of one or more Logical Nodes

(LNs).

• Logical Node: virtual abstraction application

functionalities. All LDs have a Logical Node

Zero (LLN0) to represent common data for the

LD.

• Data: physical world information, associated to a

LN.

• DataAttribute: information piece of a Data, e.g.,

value, timestamp. The values of a DataAttribute

are deﬁned by a type (e.g., Float, boolean).

• Dataset: group of existing Data and DataAt-

tributes of a LD.

The CBs are specialized classes to interact with

the information model through some additional func-

tionalities:

• Reporting: Buffered Report Control Blocks

(BRCP) and Unbuffered Report Control Blocks

(URCB) deﬁne the generation of reports, the for-

mer ensures that the reports arrive to the destina-

tion while the latter works on a best effort basis.

• Logging: Log Control Block (LCB) conﬁgures the

creation of logs from Datasets, what to log and

under which circumstances.

• Conﬁguration: Setting Group Control Block

(SGCB) groups settings and allows to change be-

tween the deﬁned groups.

• Eventing: Generic Object Oriented Substa-

tion Event (GOOSE) and Generic Substation

State Event (GSSE) are respectively managed by

GOOSE Control Block (GoCB) and GSSE Con-

trol Block (GsCB) to deliver Datasets containing

DataAttributes and basic state change informa-

tion. The events are based on publish-subscribe

communications.

• Sampled Values: manage the transfer of sam-

pled information in Datasets of DataAttributes in

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

a time controlled way. It can be implemented in

two ways: using multicast communication with a

Multicast Sample Value Control block (MSVCB)

or unicast communication with an Unicast Sam-

ple Value Control Block (USCVB).

Figure 1 deﬁnes the different elements, both on

the Basic Information Model and the CBs. All the

elements have a name and an absolute reference to

uniquely identify them throughout the entire model.

Figure 1: The information model of the IEC 61850 stan-

dard.

4 CONFIGURING IoT

COMMUNICATIONS

The need to monitor/control each ICPS makes IoT

communications essential. IoT communications can

communicate the Cyber part with the Physical part.

Each protocol has different characteristics, so their

use depends on the use case. Thus, we have developed

a MBE tool (TRILATERAL) using the SPL paradigm

and DSL to make it easier for the user to graphically

conﬁgure the IoT communication protocols in order

to monitor/control the ICPS. TRILATERAL is based

on the IEC 61850 standard.

4.1 IoT Communication Protocols

There are several communication protocols. For this

work, we used WS-SOAP, HTTP-REST and CoAP.

However, other protocols might be included in the

tool in the future, if the need for them arises, e.g.,

MQTT, DDS or AMQP (Iglesias-Urkia et al., 2017a).

WS-SOAP uses HTTP to communicate, send-

ing XML ﬁles using POST requests. In HTTP-

REST, JSON resource representation and different re-

quest methods are used, such as GET, PUT, POST

and DELETE. Finally, CoAP (Iglesias-Urkia et al.,

2017b),(Iglesias-Urkia et al., 2018) is a lightweight

protocol with a smaller header than the rest and also

uses GET, PUT, POST and DELETE methods and

pub-sub communication with the observe extension

(Iglesias-Urkia et al., 2018). For more extended de-

scription of the protocols and a comparison in their

performance using concrete examples with the IEC

61850 standard see (Iglesias-Urkia et al., 2018) and

(Iglesias-Urkia et al., 2018).

WS-SOAP and HTTP-REST were not designed

for resource constrained devices. However, they have

historically been used on machine-to-machine com-

munications, the precursor of IoT, so although they

are not technically IoT communication protocols, in

this work, we also refer to them as IoT communica-

tion protocols.

4.2 TRILATERAL: Overview

Figure 2 presents the different parts to conﬁgure an

ICPS to monitor/control. TRILATERAL is a MBE

practice based on the SPL paradigm to generate a

speciﬁc software for each ICPS and uses a DSL for

the selection and conﬁguration of the generated soft-

ware. TRILATERAL is divided into two parts: 1) the

server model deﬁnition and 2) the data model deﬁni-

tion. Both of them are conﬁgured by the user using

the DSL (e.g., Figure 4). The former one, i.e., server

model deﬁnition, is used for conﬁguring the IoT com-

munications for data transition. The latter one, is for

conﬁguring the data model based on IEC 61850 with

the main objective to represent a ICPS.

Thanks to the created DSL, conﬁguring the server

in addition to the data model is faster and less error-

prone. TRILATERAL is used to conﬁgure the model

graphically. In addition, it is not only valid for a

speciﬁc use case, but thanks to the SPL and the de-

signed DSL, several industrial domains such as Wind

Turbine Farms, Smart Elevators, and Catenary-free

Trams can be conﬁgured.

First, the user conﬁgures the server model by

choosing the IoT communication protocol (step 1).

They can conﬁgure more than one IoT communi-

cation protocol if required. Hence, the user must

choose the protocol that best suits their ICPS. Cur-

rently, TRILATERAL provides three IoT communi-

cation protocols, i.e., WS-SOAP, HTTP-REST and

CoAP, with the latter’s implementation explained in

(Iglesias-Urkia et al., 2018). Thus, the user can con-

ﬁgure the server according to the stakeholder’s needs.

Figure 3 shows the feature model where the combina-

TRILATERAL: Software Product Line based Multidomain IoT Artifact Generation for Industrial CPS

SOURCE CODESOURCE CODE

DATA MODEL

DEFINITION

API

(1)

(2)

(3)

Insert

(5)

monitor / control

(7)

ACTUATOR SENSORDISPLAY

LIBRARY

EXECUTABLE

DRIVER

Insert

(4)

GENERATED

CODE

(6) (6)

IoT

COMMUNICATION

SOAP

CoAP

HTTP

-> CRUD

functionality

-> CRUD

functionality

(6)

User configuration file

Files folder

Certification file folder

Server configuration file

User configuration file

Files folder

Certification file folder

Server configuration file

SERVER MODEL

DEFINITION

Figure 2: TRILATERAL overview.

tions that the user can choose to conﬁgure the server

model.

Once the IoT communication protocol is chosen

and the user has selected all the conﬁgurations it

needs, TRILATERAL automatically creates user and

server conﬁguration ﬁles where the user will enter the

necessary information for the system to be adapted.

Then, TRILATERAL automatically generates two di-

rectories: one for certiﬁcates, where all security cer-

tiﬁcates are stored; and another one where the ﬁles re-

lated to the ﬁle management functionalities offered by

the IEC 61850 standard are uploaded or downloaded.

This is possible thanks to the DSL and the interac-

tion with the user. Thus, the server model is auto-

matically created considering stakeholder needs and

avoiding conﬁguration errors.

Afterward, the user conﬁgures the data model

based on IEC 61850 (step 2). Figure 1 shows the

detailed information model of the IEC 61850. To

do so, the user conﬁgures the Servers, LDs, LNs,

Datas, DataAttributes and the Datasets with TRI-

LATERAL. Therefore, once the user conﬁgures the

server model and the data model, TRILATERAL au-

tomatically generates the code (generated code) us-

ing model to text (M2T) transformation (step 3). The

generated code is speciﬁc for an ICPS. Then (step 4),

the user compiles the generated code with a speciﬁc

driver (the connector that links the devices with the

data model). The driver is different in each case, it de-

pends on the hardware of the ICPS. Hence, it needs to

be developed separately in order to create the speciﬁc

communication between the generated code and the

hardware. Once the driver is compiled with the gener-

ated code, some libraries and executables are created,

i.e., artifact.

The artifact is introduced in the ICPS (step 5) and

this is the responsible for monitoring/controlling all

the devices inside the ICPS, i.e., displays, actuators,

and sensors (Iglesias et al., 2017) (step 6). But to do

so, an external API is necessary to interact with the

ICPS, i.e., all the data needs to be controlled by the

stakeholder somehow. That is how the stakeholder

is able to interact with the ICPS remotely, using the

API by the selected IoT communication protocol, i.e.,

WS-SOAP, HTTP-REST, CoAP.

An IEC 61850 compliant external API is able to

do Create, Read, Update and Delete (CRUD) opera-

tions on the ICPS. To do so, the API uses predeﬁned

functions such as DeleteDataSet or GetAllDataVal-

ues. These functionalities are speciﬁc to the IEC

61850 standard and they are explained in more detail

in (Iglesias-Urkia et al., 2017c).

Thus, thanks to TRILATERAL, an IoT commu-

nication middleware is created in order to moni-

tor/control the entire ICPS. Although there is an inter-

action with the user to achieve the objective, it is im-

portant to note that if the stakeholder has its require-

ments and knows the real structure of its industrial

domain, the generation of the generated code through

TRILATERAL is faster and less error-prone. In ad-

dition, despite the standard being created for electri-

cal substations, it is also suitable for other industrial

domains (Iglesias et al., 2017; Iglesias-Urkia et al.,

2017c).

4.3 TRILATERAL: Technical Detail

TRILATERAL is a graphical eclipse plugin devel-

oped with the Eclipse Modeling Framework

. The

data model, i.e., the tree structure of the ICPS to be

https://www.eclipse.org/modeling/emf/

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

FILE PATH

REFRESH PERIOD

SERVER NAME

CHECK PERIOD

SESSION FILE

USERS FILE

SERVER

SESSIONREPORTING

COMMUNICATION PROTOCOL

PATHBUFFER

SIZE

TIME

LOCATION

INFO

WS-SOAPHTTP-REST

CoAP

SECURITY

PORT

TIMEOUT

SECURITYPORTTIMEOUT PORTTIMEOUT

PATH

CERT

SECURITY

POOLMAX DATAMAX IP

KERNEL

Mandatory OptionalMandatory Optional

KEY

CERT

PATH

CERT

Figure 3: TRILATERAL server feature model.

monitored/controlled, can be represented with TRI-

LATERAL. Figure 4 shows a screenshot of TRILAT-

ERAL, where a Server named SERVER NODE can

be seen. The Server has the SmartElevator LD LD,

which includes several LNs. Those LNs then have dif-

ferent Datas, Datasets and CBs.

Figure 4: Screenshot of TRILATERAL.

As previously mentioned (Section 4.2), the code

is generated automatically from the designed data

model with TRILATERAL. Additionally, the user can

choose one or more protocol between WS-SOAP,

HTTP-REST or CoAP. The code which is generated

composes several Eclipse projects, in three different

layers, i.e., kernel, libraries and applications. The lay-

ers of projects and libraries are shown in Figure 5.

The kernel of the ICPS is in the lower level. It in-

cludes the lib-model-kernel for the generic parts of

the model along with the lib-model-speciﬁc-model,

which is the model generated with TRILATERAL.

On top of that (i.e., libraries layer), lib-service-server-

rest, lib-service-server-soap and lib-service-server-

coap are the libraries to create the servers for HTTP-

REST, WS-SOAP and CoAP respectively. Other aux-

iliary libraries are also in this layer, i.e., libcoap

for CoAP communication, libcbor for CBOR infor-

mation representation, jsoncpp for JSON represen-

tation, microhttpd for HTTP-REST communication,

and gSOAP for using WS-SOAP. The server for each

protocol is on the top layer, i.e., application layer.

Even though the reporting servers are generated

apart from the general server, they also have the

same three layers. WS-SOAP and HTTP-REST need

separate servers and clients because the communi-

cation paradigm changes. This does not happen

with CoAP due to its Observe extension for Pub/Sub

communication. Each of HTTP-REST and WS-

SOAP reporting server and clients are generated from

its own library, namely lib-reporting-server-rest, lib-

reporting-client-rest, lib-reporting-server-soap and

lib-reporting-client-soap. For reporting functions

both WS-SOAP and HTTP-REST work in a similar

way, where the service server stores the reports on a

folder deﬁned in the system’s conﬁguration ﬁle. The

reporting client has to periodically check if there is

any report on that folder, and if so, it sends it to the

reporting server. CoAP implementation includes the

Observe extension to allow Pub/Sub communications,

thus, the client just subscribes to the reports and the

server pushes them to the client when generated.

5 DEPLOYMENT AND LESSONS

LEARNED

TRILATERAL was successfully used on three differ-

ent industrial domains and thanks to the development

and deployment we learned several lessons.

5.1 Deployment

For each of the three presented use cases, TRILAT-

ERAL was used to generate ﬁrst the model and then

the source code that allows to construct the set of ar-

tifacts that are deployed on the ICPS. These artifacts

compose and provide the core functionality that al-

TRILATERAL: Software Product Line based Multidomain IoT Artifact Generation for Industrial CPS

Figure 5: Layers of the IEC tool.

lows to remotely monitor/control IEC 61850 compli-

ant devices using various IoT communication proto-

cols.

The ﬁrst deployment was the Smart Elevator,

where a controlled environment had to be modelled

and there are no connectivity or power issues, hence,

WS-SOAP communication performs satisfactorily. In

this scenario, we used one LD for each elevator. Then,

we deployed the second use case, i.e., Catenary-free

Tram. For this, two different use cases were deﬁned:

1) when the tram is on route, or 2) when it is on a sta-

tion. In addition, there were three LDs, one to repre-

sent the batteries and electrical components, a second

one to represent the active demand management sys-

tem and ﬁnally, a last one to represent the climate sys-

tem of the tram. An issue arouse on the deployment

process, i.e., the system was too heavyweight. This

led to a change in TRILATERAL, making the ker-

nel more modularized and providing the selection of

what modules of the kernel should be included in each

part of the system, thus, decreasing the weight of each

part of the system. Finally, it became clear that this

was a good change in the implementation of the Wind

Farm, where we used one LD for each wind turbine.

With this change, the ﬁrst use case, i.e., Smart Eleva-

tor, was easily rebuild in order to update the system

and the new build was more lightweight. In the Ta-

ble 1, the Wind Farm, Smart Elevator and Catenary-

free Tram scenarios are connected to the used pro-

tocols, describing the characteristics of the scenarios

and why they ﬁt with each communication protocol.

In summary, TRILATERAL has allowed IK4-

Ikerlan to improve the engineering process of ICPS

development, not only reducing time and costs but

also improving the validation and maintenance tasks.

It has also allowed to open new opportunities to ex-

tend TRILATERAL to other IoT domains such as Au-

tomated Warehouses or Press Machines.

5.2 Lessons Learned

TRILATERAL was deployed and tested in different

industrial use cases (Section 2). These three use cases

used TRILATERAL with different conﬁgurations, re-

sulting on diverse generated code. Based on the de-

velopment and deployment of these artifacts the fol-

lowing lessons have been learned:

5.2.1 Decrease Development and Deployment

Time

The time to develop and deploy the Artifact has rad-

ically decreased from previous similar projects. This

is because of the improvement of the overall ICPS de-

velopment process, removing tasks that where being

done manually and automating source code genera-

tion. This has led to a reduction of time and costs of

development as well as a improvement of the quality

of the delivered artifacts. This has also reduced engi-

neering and maintenance costs of the overall process.

5.2.2 Useful in Other Domains

The use cases are mainly related to energy IoT sys-

tems. The variability of these systems is so high that

they represent characteristics of very diverse IoT sys-

tems (device-to-cloud systems and device-to-device

systems). Therefore, we believe that the proposed

solution can be used in any IoT environment (man-

ufacturing, transport, etc.) that needs to be moni-

tored/controlled remotely.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

Table 1: IoT communication protocols for each use case characteristics.

Protocol

Use case

Wind Farm Smart Elevator Catenary-free Tram

WS-SOAP

- Controlled environment

- No connectivity/power issues

HTTP-REST

- Remote location Station

- Connectivity issues - Controlled environment

- Smaller header with big payloads

CoAP

On route

- Mobile

- Connectivity/Power issues

5.2.3 IEC 61850 Outside the Electrical

Substations

The validation of the system has also been improved

due to the fact that the same IEC 61850 kernel code

is used on all scenarios. In this way, a new scenario

need not be extensively evaluated because its core has

already been validated and veriﬁed before with each

model’s development.

5.2.4 SPL and DSL Beneﬁts Industry 4.0

Thanks to this work, we realized how beneﬁcial the

SPL paradigm can be in industrial domains. Because

even though many domains exist they share similar re-

quirements, as explained in Section 2, and many com-

monalities exist between them. In addition we also

noticed the beneﬁts a DSL can achieve. Although its

development was complex, once it was well designed

and developed, the conﬁguration of an IoT communi-

cation protocol becomes much simpler, mainly due to

the use of a visual environment. That is why thanks to

the union of SPL and DSL, as mentioned in the ﬁrst

lesson learned, the development time decreases con-

siderably. We have therefore learned the signiﬁcance

of using SPL and DSL in industry, considering both

beneﬁcial.

6 RELATED WORK

Reducing development time in addition to mainte-

nance cost is possible by using reuse techniques such

as SPL and MBE. These two paradigms are becoming

increasingly common in industry (Capilla et al., 2014;

Young et al., 2017). Some research has previously

been done in terms of ICPS, SPL and MBE (Iglesias

et al., 2017; Tang et al., 2018; Sinnhofer et al., 2017;

Ayala et al., 2015) where the variability between the

different devices inside the ICPS is managed. Sev-

eral authors also use DSL for managing variability in

ICPS (Sinnhofer et al., 2017).

Regarding the IEC 61850, Iglesias et al. (Igle-

sias et al., 2017) use the combination of two stan-

dards (IEC 61850 + IEC 62264) to capture all mon-

itored data from the ICPS by using SPL and MBE.

Regarding the communication protocols used along

the IEC 61850, (Iglesias-Urkia et al., 2017c) and

(Iglesias-Urkia et al., 2018) review previous related

work. Apart from the MMS communication proto-

col already included in the IEC 61850 standard doc-

uments, the related IEC 61400 also includes SOAP

Web-Services (IEC TC-88, 2016). Some authors

have proposed other protocols, such as CORBA (Sanz

et al., 2001), DDS (Calvo et al., 2012; Bi et al.,

2013), or a combination of both (Calvo et al., 2009).

A RESTful approach has been considered (Peder-

sen et al., 2010; Parra, 2016) using HTTP and also

a Pub/Sub communication through XMPP (Hussain

et al., 2018). Following this evolution, the ﬁrst pro-

posals to use a speciﬁc IoT communication protocol

use CoAP (Shin et al., 2017; Iglesias-Urkia et al.,

2017c).

To the best of our knowledge, this is the ﬁrst work

where the IEC 61850 is modeled by a DSL for gener-

ating an Artifact based on SPL and MBE, capable of

monitoring/controlling ICPS. Besides, we also give

the chance to the user to conﬁgure the IoT commu-

nication protocol (e.g., HTTP-REST, WS-SOAP and

CoAP).

7 CONCLUSION

This paper presents TRILATERAL, a MBE SPL so-

lution using IEC 61850 for conﬁguring IoT commu-

nication protocols graphically. Thanks to the deﬁ-

nition of a DSL which is integrated in the solution

we are able to represent the data model of any ICPS.

Thus, IoT communication protocols are automatically

developed considering stakeholders’ needs. In addi-

tion, TRILATERAL was evaluated in different indus-

trial domains i.e., Wind Farm, Smart Elevator and

Catenary-free Tram, where some lesson have been

learned. Even more, we think it may be applicable

TRILATERAL: Software Product Line based Multidomain IoT Artifact Generation for Industrial CPS

to other domains.

Some future lines are expected to be addressed in

the short-medium term:

1. Use TRILATERAL in other domains, such as Au-

tomated Warehouses or Press Machine domains,

that could allow to validate its suitability for any

kind of ICPS.

2. Enhance TRILATERAL from a SPL to a dynamic

SPL (DSPL), regarding physical element changes

(update, add or remove physical nodes). Cur-

rently, the model is static and can only be changed

by means of an update.

3. Add new functionality to the TRILATERAL that

could allow the artifacts to be remotely updated.

This way, the ICPS could easily adapt to the

surrounding context and to changes on the data

model of the ICPS and related hardware.

4. Automatically generate drivers that link the data

model with the sensors, displays, and actuators lo-

cated on the devices. Currently, this is a manual

task and requires many resources. This task is also

very dependant of the target hardware where the

artifact is going to be deployed.

ACKNOWLEDGEMENTS

This work has received funding from the Electronic

Component Systems for European Leadership Joint

Undertaking under the MegaM@Rt2 project (Grant

agreement No. 737494) in the EU Horizon 2020 pro-

gram and the Basque Government through the Elka-

rtek program under the TEKINTZE project (Grant

agreement No. KK-2018/00104). We thank Shaukat

Ali of Simula Research Laboratory (Oslo, Norway)

for comments that greatly improved the manuscript.

REFERENCES

Ayala, I., Amor, M., Fuentes, L., and Troya, J. M. (2015).

A software product line process to develop agents for

the iot. Sensors, 15(7):15640–15660.

Bi, Y., Jiang, L., Wang, X. J., and Cui, L. Z. (2013). Map-

ping of IEC 61850 to Data Distribute Service for dig-

ital substation communication. In IEEE Power and

Energy Society General Meeting, pages 1–5.

Calvo, I., Garc

ıa De Alb

eniz, O., Noguero, A., and P

erez,

F. (2009). Towards a modular and scalable design

for the communications of electrical protection relays.

IECON Proceedings (Industrial Electronics Confer-

ence), pages 2511–2516.

Calvo, I., Garcia de Alb

eniz, O., and P

erez, F. (2012).

A communication backbone for Substation Automa-

tion Systems based on the OMG DDS standard. In

Przeglad Elektrotechniczny, volume 88, pages 146–

150.

Capilla, R., Bosch, J., Trinidad, P., Ruiz-Cort

es, A., and

Hinchey, M. (2014). An overview of dynamic soft-

ware product line architectures and techniques: Ob-

servations from research and industry. Journal of Sys-

tems and Software, 91:3 – 23.

Fowler, M. (2011). Domain-Speciﬁc Languages. The

Addison-Wesley signature series. Addison-Wesley.

Hussain, S. M. S., Aftab, M. A., and Ali, I. (2018). Iec

61850 modeling of dstatcom and xmpp communica-

tion for reactive power management in microgrids.

IEEE Systems Journal, pages 1–11.

IEC TC-88 (2016). Wind energy generation systems - part

25-4: Communications for monitoring and control of

wind power plants - mapping to communication pro-

ﬁle.

Iglesias, A., Arellano, C., Yue, T., Ali, S., and Sagar-

dui, G. (2018). Model- based personalized visu-

alization system for monitoring evolving industrial

cyber-physical system. In Accepted for Publishing in

25th Asia-Paciﬁc Software Engineering Conference,

APSEC 2018.

Iglesias, A., Lu, H., Arellano, C., Yue, T., Ali, S., and Sagar-

dui, G. (2017). Product line engineering of monitoring

functionality in industrial cyber-physical systems: A

domain analysis. In Proceedings of the 21st Interna-

tional Systems and Software Product Line Conference,

SPLC 2017, Volume A, pages 195–204.

Iglesias-Urkia, M., Casado-Mansilla, D., Mayer, S., and Ur-

bieta, A. (2018). Enhanced publish/subscribe in coap:

describing advanced subscription mechanisms for the

observe extension. In Proceedings of the 8th Interna-

tional Conference on the Internet of Things, IOT 2018,

pages 14:1–14:8.

Iglesias-Urkia, M., Casado-Mansilla, D., Mayer, S., and

Urbieta, A. (2018). Integrating electrical substations

within the iot using iec 61850, coap and cbor. Submit-

ted to IEEE Internet of Things Journal.

Iglesias-Urkia, M., Casado-Mansilla, D., Mayer, S., and

Urbieta, A. (2018). Validation of a coap to IEC

61850 mapping and benchmarking vs HTTP-REST

and WS-SOAP. In 23rd IEEE International Confer-

ence on Emerging Technologies and Factory Automa-

tion, ETFA 2018, pages 1015–1022.

Iglesias-Urkia, M., Orive, A., Barcelo, M., Moran, A.,

Bilbao, J., and Urbieta, A. (2017a). Towards a

lightweight protocol for industry 4.0: An implemen-

tation based benchmark. In Proceedings of the 2017

IEEE International Workshop of Electronics, Con-

trol, Measurement, Signals and their Application to

Mechatronics, ECMSM 2017.

Iglesias-Urkia, M., Orive, A., and Urbieta, A. (2017b).

Analysis of coap implementations for industrial inter-

net of things: A survey. In Procedia Computer Sci-

ence, volume 109, pages 188–195.

Iglesias-Urkia, M., Orive, A., Urbieta, A., and Casado-

Mansilla, D. (2018). Analysis of coap implementa-

tions for industrial internet of things: a survey. Jour-

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

nal of Ambient Intelligence and Humanized Comput-

ing.

Iglesias-Urkia, M., Urbieta, A., Parra, J., and Casado-

Mansilla, D. (2017c). IEC 61850 meets coap: towards

the integration of smart grids and iot standards. In

Proceedings of the Seventh International Conference

on the Internet of Things, IOT 2017, pages 3:1–3:9.

Kagermann, H., Helbig, J., Hellinger, A., and Wahlster,

W. (2013). Recommendations for Implementing the

Strategic Initiative INDUSTRIE 4.0: Securing the Fu-

ture of German Manufacturing Industry; Final Report

of the Industrie 4.0 Working Group. Forschungsunion.

Kelly, S. and Tolvanen, J. (2008). Domain-Speciﬁc Model-

ing - Enabling Full Code Generation. Wiley.

Leit

ao, P., Colombo, A. W., and Karnouskos, S. (2016). In-

dustrial automation based on cyber-physical systems

technologies: Prototype implementations and chal-

lenges. Computers in Industry, 81:11–25.

Parra, J. (2016). Restful Framework for Collaborative In-

ternet of Things Based on IEC 61850. PhD thesis,

Universidad del Pa

ıs Vasco - Euskal Herriko Unibert-

sitatea (UPV/EHU).

Pedersen, A. B., Hauksson, E. B., Andersen, P. B., Poulsen,

B., Træholt, C., and Gantenbein, D. (2010). Facilitat-

ing a Generic Communication Interface to Distributed

Energy Resources: Mapping IEC 61850 to RESTful

Services. Smart Grid Communications (SmartGrid-

Comm), 2010 First IEEE International Conference

on, pages 61–66.

Sanz, R., Clavijo, J. A., Segarra, M. J., de Antonio, A., and

Alonso, M. (2001). CORBA-Based Substation Au-

tomation Systems. In Proceedings of IEEE Confer-

ence on Control Applications.

Shin, I.-J., Song, B.-K., and Eom, D.-S. (2017). Inter-

national Electronical Committee (IEC) 61850 Map-

ping with Constrained Application Protocol (CoAP)

in Smart Grids Based European Telecommunications

Standard Institute Machine-to-Machine (M2M) Envi-

ronment. Energies, 10(3):393.

Sinnhofer, A. D., P

uhringer, P., Oppermann, F. J., Potz-

mader, K., Orthacker, C., Steger, C., and Kreiner, C.

(2017). Combining business process variability and

software variability using traceable links. In Busi-

ness Modeling and Software Design - 7th Interna-

tional Symposium, BMSD 2017, Revised Selected Pa-

pers, pages 67–86.

Suri, K., Cuccuru, A., Cadavid, J., Gerard, S., Gaaloul,

W., and Tata, S. (2017). Model-based development of

modular complex systems for accomplishing system

integration for industry 4.0. In Proceedings of the 5th

International Conference on Model-Driven Engineer-

ing and Software Development - MODELSWARD,,

pages 487–495. INSTICC, SciTePress.

Tang, H., Li, D., Wang, S., and Dong, Z. (2018). CASOA:

an architecture for agent-based manufacturing system

in the context of industry 4.0. IEEE Access, 6:12746–

12754.

Tao, F., Zuo, Y., Xu, L. D., and Zhang, L. (2014). Iot-based

intelligent perception and access of manufacturing re-

source toward cloud manufacturing. IEEE Trans. In-

dustrial Informatics, 10(2):1547–1557.

TC-57, I. (2003). Communication networks and systems in

substations - part 7-1: Basic communication structure

for substation and feeder equipment - principles and

models.

Young, B., Cheatwood, J., Peterson, T., Flores, R., and

Clements, P. C. (2017). Product line engineering

meets model based engineering in the defense and au-

tomotive industries. In Proceedings of the 21st Inter-

national Systems and Software Product Line Confer-

ence, SPLC 2017, Volume A, pages 175–179.

TRILATERAL: Software Product Line based Multidomain IoT Artifact Generation for Industrial CPS