On the Integration of Smart Grid and IoT

Salvatore Cavalieri

, Giulio Cantali

and Andrea Susinna

University of Catania, Dpt. of Electrical Electronic and Computer Engineering (DIEEI), A. Doria, 6, Catania, Italy

Consortium COMETA, S. Sofia 64, Catania, Italy

Keywords: IEC 61850, Smart Grid, Internet of Things, Web Services, REST, MQTT.

Abstract: The paper proposes a novel solution in the field of the integration of Smart Grid and Internet of Things. The

definition of a web platform able to offer to a generic web user a RESTful interface to IEC 61850 Servers is

proposed. The web platform enables the mapping of information maintained by an IEC 61850 server into

MQTT messages.

1 INTRODUCTION

The smart grid (SG) is based on a new vision of the

electric grid, which includes the maximization of the

distribution of energy demand, the minimization of

losses and the integration of renewable energy

sources on a large scale, as pointed out in (Alotaibi,

2020; Mehigan, 2018; Shi, 2020). SG aims to

overcome one of the main limitations of the current

electric grid, related to the lack of integration of novel

information and communication technologies.

Among the novel information and communication

technologies there are those based on the Internet of

Things (IoT), which play a strategic role in the era of

Industry 4.0 as shown by (Xu, 2021; Hassan, 2020,

Bader, 2020; Lu, 2017; Cotrino, 2020). The

eXtensibleMessaging Presence Protocol (XMPP) and

the Message Queue Telemetry Transport (MQTT) are

some of the most known protocols in this field (IETF,

2004; OASIS, 2014; ISO/IEC, 2016). The

REpresentational State Transfer or REST is an

architectural style defined by Roy Fielding in his PhD

dissertation (Fielding, 2000); a Web Service based on

REST is called RESTful Web Service (Richardson,

2007). RESTful Web Services is a paradigm that can

enhance the IoT application scope by making smart

things part of the Web (Benomar, 2020).

The paper proposes a novel solution in the field of

the integration of SG and IoT. In particular, the

proposed integration involves IEC 61850, which is is

an international standard defining communication

https://orcid.org/0000-0001-9077-3688

protocols for intelligent electronic devices at

electrical substations (IEC 61850, 2011; Falk, 2019).

The definition of a web platform able to offer to a

generic web user a RESTful interface to IEC 61850

Servers is proposed. The web platform is based on a

REST architecture and enables the mapping of IEC

61850 information model into MQTT messages. The

platform will be called IEC 61850 Web Platform in

the remainder of the paper.

2 RELATED WORKS

The current literature presents several studies about

enabling IoT in SG, typically referred as IoT-enabled

SG (Reka, 2018; Al-Turjman, 2019; Cavalieri, 2016;

Cavalieri, 2021).

In (Tightiz, 2020) the authors present a review of

the IoT protocols used in the SG aiming to achieve

guidelines in utilizing the proper IoT protocol that can

meet the SG requirements; addressing effective

elements in applying IoT in the SG’s future trends is

another contribution of this paper. In (Shin, 2016)

authors discuss integration of IEC 61850 and IoT. In

(Ustun, 2020) an IEC 61850 and XMPP

communication-based energy management in

microgrids with integrated electric vehicles is

introduced. In the paper (Jun, 2021), the XMPP and

MQTT are applied to an IEC 61850-based grid, and

the most suitable protocol for the micro grid

environment is derived by comparing two protocols.

Cavalieri, S., Cantali, G. and Susinna, A.

On the Integration of Smart Grid and IoT.

DOI: 10.5220/0011035300003179

In Proceedings of the 24th International Conference on Enterprise Information Systems (ICEIS 2022) - Volume 1, pages 709-716

ISBN: 978-989-758-569-2; ISSN: 2184-4992

709

Among the main approaches aimed to enable

interworking between REST and SG domains, in

(Urkia, 2018) a mapping between CoAP and IEC

61850-based substation automation systems in a SG

environment is proposed. Based on REST, CoAP is a

specialized web transmission protocol for use with

constrained nodes and constrained networks. Another

solution for the mapping of the IEC 61850 to

RESTful Services is presented in (Pedersen, 2010).

The main feature making the proposal here

present different from the other solutions present in

the literature is the capability of offering several

mechanisms, all enabling SG and IoT integration, in

the same solutions. First of all, a RESTful interface to

IEC 61850 Servers is available, allowing a generic

web user to access the information maintained by the

IEC 61850 server by a REST-based exchange. Then

a mechanism to transmit information maintained by

IEC 61850 Server, through JSON frames included in

MQTT payloads has been defined based on pub/sub

transmission mechanisms. Finally, the solution here

proposed aims to introduce syntactic interoperability;

the IEC 61850 Web Platform allows a user to share

the description of the data types maintained by IEC

61850 Server, into a standard format (JSON).

3 IEC 61850 DATA MODEL

IEC 61850 is the leading standard for substation

automation (IEC 61850, 2011), (Falk, 2019). It is

intended to structure the intelligence of protection,

control, monitoring and automation functions. The

standard fulfils automation architecture requirements

for utility subsystems, enabling communication

among multi-vendor equipment.

IEC 61850 defines an object-oriented modelling

of process data required for the power system

automation. IEC 61850 data model has been

primarily defined for the exchange of information

within substations by the document IEC 61850-7-4

(IEC 61850, 2011). IEC 61850 data model is now

extended for other domains, among which one can

include distributed energy resources (DER)s by IEC

61850-7-420 (IEC 61850, 2011).

Figure 1 shows the main elements of the IEC

61850 data model. The top parent class is the

intelligent electronic device (IED), which is hosted by

physical device, i.e., the controller part of the device.

The IED consists of one or more Logical Devices

(LDs), i.e., virtual representations of devices intended

for supervision, protection or control of automated

systems. LDs are created by combining several

Logical Nodes (LNs) which represent various device

functionality interfaces. Data Objects (DOs) are

representations of the common information of logical

nodes. DOs are typed by Common Data Classes

(CDC) from IEC 61850-7-3 or IEC 61850-7-2 (IEC

61850, 2011). Each CDC describes the type and

structure of the data object within the LN. Figure 2

gives the details of hierarchical structure of the Data

Object Type.

Figure 1: IEC 61850 Data Model.

A Data Object belongs to the Data Object Type; it

may contain elements of the Data Attribute type

and/or Structured Data Object type (i.e., Data

Attributes and Structured Data Object, respectively).

Like Data Object, Structured Data Objects are also

defined by Data Object Types, as shown by Figure 2.

Figure 2: Data Type Template Hierarchy.

A Data Attribute is defined by the Data Attribute

Type. It may be a Structured Attribute, or may be of

a customized Enumeration type, or of a Basic

Attribute type. In the simplest case, a Basic Attribute

may be of basic type like Integer, Floating Point or

Boolean. Like Data Attributes, Structured Attribute

belongs to Data Attribute type, as shown by Figure 2.

The IEC 61850 standard provides a data exchange

mechanism using an XML-based file format called

Substation Configuration Language (SCL). SCL

allows the representation of an IEC 61850 system

configuration of electrical devices, including

IED

Logical Device (LD)

Logical Node (LN)

Data Object (DO)

Logical Node Type

Data Objects

Data Object Type

Structured Data Object

Data Attribute Type

Data Attributes

Structured Attribute

Basic Attribute Type

Enumeration

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

710

representation of data and communication services, as

described in (IEC 61850, 2011). Its main purpose is

to allow an interoperable exchange of communication

system configuration data between an IED

configuration tool and a system configuration tool

from different manufacturers. The SCL file is divided

into sections, each of which provides different

information. Header section includes general topics

and details about SCL and file version.

Communication section contains communication

details. Substation section describes electrical

topology for substation or any other electrical

process. IED section describes devices capacities,

functions and data it manages. DataTypeTemplates

section describes functional data model by defining

LNs, Data Objects and Data Attributes.

IED Capability Description (ICD) file is a specific

type of Substation Configuration Language (SCL)

file, containing a generic description of the whole

capability range of a given device, including the

functions and objects it can support. The ICD file is

usually supplied by the developer/manufacturer.

IEC 61850 standardizes the set of abstract

communication services allowing for compatible

exchange of information among components of a

Power Utility Automation System. IEC 61850 offers

several types of communication models, among

which there is the Client/Server type communication

services model. An IEC 61850 Server may be used to

maintain and make available to IEC 61850 Clients, its

content is in term of data structured according to the

IEC 61850 data model shown in Figures 1 and 2. An

ICD file is always available in the IEC 61850 Server

to describe its full content.

4 IEC 61850 WEB PLATFORM

The IEC 61850 Web Platform here proposed, is based

on the adoption of a REST architectural style and is

shown by Figure 3. As it can be seen, it offers to a

Web User the access to one or more IEC 61850

Servers.

The term Web User is used in this paper to refer

to a generic application running on a generic device

which consumes the services offered by the IEC

61850 Web Platform. It is constrained neither to be

IEC 61850 compliant nor to implement the IEC

61850 communication stack. The only constraints are

the adoption of RESTful-based communication and

the MQTT-based exchange of information.

The RESTful Web Service Interface shown by

Figure 3, accepts requests submitted by an

authenticated Web User.

The Middleware module inside the IEC 61850

Web Platform, performs all the operations needed to

fulfil each request coming from a Web User. These

requests may require data exchange with the available

IEC 61850 Servers; for this reason, the Middleware

includes an IEC 61850 Client used for the access to

the IEC 61850 Servers. Communication between IEC

61850 Client and IEC 61850 Servers occurs

according to the standard IEC 61850 communication

protocol and services (i.e., using the IEC 61850

communication stack). The Middleware includes a

particular module named MQTT Publisher, which is

in charge to publish information taken from IEC

61850 Server, through a MQTT Broker, using MQTT

protocol.

Figure 3: IEC 61850 Web Platform.

Communication between Web User and the IEC

61850 Web Platform may be synchronous (based on

RESTful web services) and asynchronous (based on

MQTT Publish/Subscribe Pattern), as shown by

Figure 3.

Web User uses synchronous communication to

interact with the Web Service Interface to request one

of the services offered by the IEC 61850 Web

Platform. POST requests are realized using JSON

format. For each Web User’s request through the

RESTful Web Service Interface, the IEC 61850 Web

Platform will send a relevant response. Due to the

adoption of REST, communication between Web

User and IEC 61850 Web Platform is stateless. Each

Web User needing to use the IEC 61850 Web

Platform through the Synchronous communication,

must be previously registered (by user credentials in

terms of username and password) and authenticated

(through the use of signed token which is returned to

the Web User).

IEC 61850 Web Platform

RESTful Web Service

Interface

IEC

61850

Client

MQTT

Publisher

Asynchronous

communication

Web User

IEC 61850

Server

Middleware

Broker

IEC 61850

Server

On the Integration of Smart Grid and IoT

711

Asynchronous communication is realized through

the use of MQTT Brokers to allow the Web User to

receive data produced by the platform; data is mainly

originated by the IEC 61850 Servers. Web User will

information needed from the relevant MQTT Broker.

The Broker may be chosen by the Web User, or he

can use a given predefined Broker.

The following subsections will give more details

about both the synchronous and asynchronous data

exchange.

4.1 User Registration and

Authentication

Use of the IEC 61850 Web Platform from the Web

User may occur only after his registration. If the user

is not yet registered in the system, he must issue a

suitable POST Request to a specific Web Service

Interface, in JSON format, the body of which must

contain the credentials (username and password) with

which the user intends to register. If the registration

procedure succeeds, Web User will receive a POST

response, again in JSON, indicating that the operation

was completed successfully. If registration procedure

fails (e.g., if the user is already present in the system),

the platform response will specify the failure reason.

Before the registered Web User may proceed to

request synchronous services to the platform, he must

authenticate himself to the platform by entering his

credentials. The user will send a POST request to

another specific Web Service Interface relevant to the

authentication service, specifying his personal

credentials used during the registration. If the

authentication request succeeds, the Web user will

receive a response containing a signed token to be

used in each of the next web service synchronous

requests issued to the IEC 61850 Web Platform.

4.2 Accessing an IEC 61850 Server

The main aim of the Web Platform is to allow the

access to IEC 61850 servers by the web. According

to this aim, the Web User must pass to the platform

the details about the IEC 61850 Server he desires to

access. A POST request must be issued at a particular

Web Service Interface containing these details; in

particular, three parameters are required to be

specified.

The first parameter represents the IP address of

the remote machine hosting the IEC 61850 Server;

the other parameter is the port on which the server is

listening. Finally, it is requested that the Web User

specifies the path in the IEC 61850 Server of the ICD

file describing the content of the IEC 61850 data

model. As said in Section 2, the ICD file contains the

SCL description of the data model maintained by the

IEC 61850 Server.

As consequence of this request, the middleware

connects to the server specified in the POST request

and retrieves the SCL file on the basis of the full path

provided for by the web user. Once received, this file

is locally stored; it will be used by the Middleware as

explained in the following subsections. The IEC

61850 Web Platform will respond with a POST

Response, pointing out the success of his previous

request.

A disconnection procedure has been foreseen

through a specific POST request issued by the Web

User, when the data exchange activities with a

specific IEC 61850 Server end. All the local resources

allocated to maintain the SCL descriptions of the IEC

61850 Server accessed by the Web User are released,

if not used by other users.

4.3 Publication of Data Types

Data type is an attribute associated with a piece of

data that tells a computer system how to interpret its

value. Two or more systems exchanging data must be

capable of interpreting data; to achieve this, syntactic

interoperability must be established, at least. This

requires that the two systems must share a common

data format and data structures. Considering the

proposal here presented, Web User must be able to

interpret each information exchanged with the IEC

61850 Server through the IEC 61850 Web Platform;

this can be achieved only on the basis of the

knowledge of the data types involved in the

information exchange; this means that the data type

descriptions of the data maintained in the IEC 61850

Server must be shared with the Web User.

For this reason, it has been defined a particular

service allowing a Web User to retrieve the

description of the entire set (or a subset) of data types

maintained in each IEC 61850 Server and relevant to

the information the Web User needs to exchange with

the IEC 61850 Server. Again, a suitable POST

Request can be issued to a specific Web Service

Interface, through which the Web User specifies the

specific data type or the set of data types he wishes to

know. It has been assumed that the Web User will

receive the description of the requested data types

though a JSON-based payload inside MQTT frames,

published by a Broker after subscription to a specific

topic. In the POST request, the Web User will specify

the data types requested and the Broker to be used for

the publication of the topics. The Web User will

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

712

receive a response from the platform confirming the

publication of the requested data type on the

requested broker on a particular topic specified in the

response. After the subscription to this topic, the Web

user may retrieve the requested data types in JSON

format.

The specification of the requested data types

occurs through the use of a particular syntax defined

in this proposal. It is important to recall that each

information in the IEC 61850 server is maintained

according to the hierarchical data tree structure shown

by Figures 1 and 2; in particular, Figure 2 gives the

details about the data type structure of Data Object.

It has been assumed that the syntax used to

identify each IEC 61850 data type from the Web User

point of view, reflects that of the data model of the

IEC 61850 standard. It is defined as a sequence of

names separated by “/”. The data type identifier must

first foresee the name of the IED maintained by the

IEC 61850 Server. According to the IEC 61850-7-1

(IEC 61850, 2011), the Logical Devices inside the

IED are identified by the attribute instance name (i.e.

inst); for this reason, the value of this attribute is used

in the data type identifier. Again, the standard IEC

61850-7-1 identifies each Logical Node by a

particular concatenation of three attributes: Logical

Node Prefix (i.e. prefix), Logical Node Class (i.e.

lnClass), Logical Node Instance (i.e. inst); for this

reason, it is assumed that the name of LN inside the

structure of the data type identifier is made up by the

same concatenation of these attributes. As Data

Objects (inside a LN), Data Attributes, Structured

Data Objects (inside DO), Enumeration and Basic

Data Attributes (for the Data Attribute Type) are

univocally identified by the name attribute, this last is

used in the data type identifier for the relevant

elements.

For example, let us assume that IEC 61850 data

model features an IED whose attribute name has the

value “BCU1M19”; moreover, let us assume that the

IED contains a Logical Device whose attribute

instance name (inst) is “C1”. Among the Logical

Nodes belonging to this Logical Device, let us assume

that the LN features the value “LBAY” for the prefix

attribute, the value “1” for the instance number (inst)

attribute, and the value “MMXU” for the attribute

lnClass. The concatenation of this values, according

to the IEC 61850 standard, gives the name

“LBAYMMXU1”, which is used in the data type

identifier. Among the Data Objects inside this LN, let

us assume the presence of the Data Object with the

name attribute set to “A”, containing Data Attributes

and Structured Data Objects. Among the Structured

Data Objects that with name attribute equal to “phsB”

exists. It is made up by a set of Data Attributes,

among which there is that featuring a name attribute

set to “cVal”. Finally, it has been assumed that this

Data Attributes contains the Data Attribute of struct

type with attribute name equal to “mag”. This Data

Attribute contains only a Basic Data Attribute

(FLOAT 32) with the name attribute “f”. According

to the scenario just described, the data type identifier

of the BDA “f”, will be: “BCU1M19/C1/

LBAYMMXU1/A/phsB/cVal/mag/f”.

According to the example just done, the Web User

submits a POST request including this data type

identifier and the details about the Broker to be used

for the publication, in order to have the publication of

the data type description of the BDA “f” contained in

the Structured Attribute “mag”. The IEC 61850 Web

Platform will send a POST response confirming the

success of the previous request and giving back a

topic identifier on the specified Broker. On the

reception of this confirmation, the Web User will

subscribe to this topic on the specified Broker.

Subscription will allow the Web User to receive an

MQTT frame containing the requested data type in

JSON format. Figure 4 shows a realistic example of

the content of this topic (in JSON).

{

"DAType": {

"id": "AnalogueValue_Float",

"BDA": {

"bType": "FLOAT32",

"name": "f"

}

Figure 4: Example of JSON frame containing data type

description.

The example just done requires that the Web User

has a complete knowledge of the content of the IEC

61850 server in terms of the current hierarchical data

model tree present in the server. Some times, this can

not be achieved, and the Web User may have the need

to explore the current IEC 61850 data model

maintained by a specific server to look for a specific

data type. For this reason, another solution has been

defined in this work in order to allow the Web User

to acquire information about the entire IEC 61850

data model structure present in the IEC 61850 server.

According to the proposed solution, the Web User

may discover the full or partial structure of the data

model, finding one or more data types of his interest.

The Web user will perform several POST requests in

order to explore the entire data model tree, until the

requested data types are found. In order to achieve

this, a particular syntax has been defined to allows the

On the Integration of Smart Grid and IoT

713

Web User to make the requests to be passed to the

platform. This syntax is again based on the rules

described before for the definition of the data type

identifier according to the IEC 61850 data model tree;

moreover, the syntax contains particular keywords

here defined and aimed to make easier the exploration

of the data model.

The following keywords have been defined in

order the Web User may explore the IEC 61850 data

model tree:

 getAllIEDs. If the Web User specifies this

keyword in his request, it will receive a topic

named “IEDs”, whose subscription to the

proper Broker, allows to achieve JSON

description of the IEDs maintained by the IEC

61850 Server. Considering the example seen

before, the JSON frame shown by Figure 5,

will be received through the subscription to this

topic.

{

"IED": {

"configVersion": 1,

"name": "BCU1M19",

"type": "BCU_APPLIANCE",

"manufacturer": "ABC"

}

Figure 5: Example of JSON frame containing data type

description of IED maintained by the IEC 61850 Server.

 getAllLogicalDevices. This keyword allows

the Web User to make a request for the

publication of the data structure relevant to the

entire set of LDs contained in a specific IED.

Considering the example seen before, and

considering in particular the content of Figure

5, the Web User may specify the following

string in the request made to the platform

“BCU1M19/getAllLogicalDevices”. The topic

he will receive from the Platform will be

“BCU1M19/LDevices”; through the

subscription to this topic, the JSON frame

shown by Figure 6 will be received.

{

"IED": {

"name": "BCU1M19",

"LDevice": {

"inst": "C1"

}

Figure 6: Example of JSON frame containing data type

description of LD belonging to the IED “BCU1M19”.

 getAllLogicalNodes. It allows the Web User to

make a request for the publication of topic

relevant to the entire set of LNs contained in a

LD. Considering the example seen before, and

considering in particular the content of Figure

6, the Web User may realize the following

request “BCU1M19/C1/getAllLogicalNodes”.

The topic he will receive from the Platform will

be “BCU1M19/C1/LNodes”; through the

subscription to this topic, the Web User will

receive the details about the LNs by a JSON

frame, among which the LN “LBAYMMXU1”

described before.

 getAllDataObjects. It allows the Web User to

make a request for the publication of topics

relevant to the entire set of Data Objects

contained in a Logical Node. Considering the

example seen before, the Web user may

perform a request specifying the string

“BCU1M19/C1/LBAYMMXU1/getAllDataO

bjects”. The topic he will receive from the

Platform will be “BCU1M19/C1/LBAYMMX

U1/DObjects”; through the subscription to this

topic, the Web User will receive the details

about the DOs contained in the LN.

 getAllDA_SDO. It is used in the request aimed

to acquire information about the entire set of

Data Attribute and Structured Data Objects

inside a Data Object.

Several operators have been defined in order to

perform more powerful queries:

 ALL. The Web User may use this operator to

achieve more information with only one

request. For example, if the Web User specifies

the string “ied1/ALL/getAllLogicalNodes”, he

can receive information about all the logical

nodes belonging to whatever logical device

contained in a specific IED (“ied1”).

 &. Through this operator, the Web User may

request the publication of several elements. For

example, he may specify the string

“ied1/Inverter/getAllLogicalNodes &

ied1/Battery/getAllLogicalNodes” in the

POST request; in this way, the Web User

requires knowledge of the structure of the

logical nodes contained in the Inverter and

Battery logical devices of the IED “ied1”.

 except. The Web user may exclude information

of particular IEC 61850 elements in his request.

For example, if the Web User specifies the

request “ied1/ALL/getAllLogicalNodes except

ied1/Battery”, it gets the names of all logical

nodes of all logical devices contained in ied1,

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

714

with the exception of logical nodes contained

in Battery.

Combinations of the previous operators may be

realized. For example, it could use the & operator to

exclude multiple elements from a multiple search,

such as requesting all the logical nodes of all the

logical devices of the ied1 device with the exception

of the logical nodes contained in Battery and Inverter:

“ied1/ALL/getAllLogicalNodes except ied1/Battery

& ied1/Inverter”.

In the previous subsection, it has been told that for

each IEC 61850 Server connected, the IEC 61850

Web Platform locally maintains an image of the ICD

file retrieved from the server; the ICD file contains

the SCL description of the data model maintained by

the IEC 61850 Server. For each request received by

the Web User, the Web Service Platform will explore

this local image in order to find the information

related to the IEC 61850 data model tree, as requested

by the user. A JSON frame is built containing the

description of the data types requested by the user, as

shown by Figures 4, 5 and 6. These frames will be

published through MQTT message by the requested

broker, on a particular topic which is passed to the

Web User through the POST Response. Subscription

to this topic by the Web User, allows him the receipt

of the requested data type description.

4.4 Subscription Request

Through the Subscription request service, the Web

User requests the IEC 61850 Web Platform to publish

the values of the variables of interest. This request is

made only after the Web User has acquired

knowledge about the information related to the data

types of these variables. To use the service, the user

sends a POST request to the IEC 61850 Web Platform

containing two fields: variable identifier and interval.

Variable identifier field contains the information

about the variable to be accessed. It is given

according to the same formalism seen for the

publication of data types. For example, considering

the example pointed out in the previous subsection,

the variable identifier “BCU1M19/C1/LBAYMMX

U1/A/phsB/cVal/mag/f”, refers to the variable “f”

contained in the Structured Attribute “mag”. The

operator & may be used in order to specify a list of

variables.

The interval field is used by the Web User to

specify the desired sampling interval in milliseconds

of the specified variables; the sampling interval

corresponds to the interval at which the variables are

sampled and the relevant values are sent to the Broker

for the publication.

For each POST request made by the Web User,

the Web Server Platform will send a POST response

containing the name of the topic to which the Web

User may be subscribe; once the subscription has

been achieved, Web User will receive from the broker

the values updated according to the frequency

specified.

4.5 Updating Request

This service is used by the Web User to update the

values of variables maintained by the IEC 61850

servers through a remote POST REST request.

The Web user must specify the variable identifier

to be modified and the new value to be updated. The

variable identifier must have the same syntax already

exposed in the previous subsections.

5 FINAL REMARKS

The paper has presented a novel solution in the field

of the integration of SG and IoT. Integration involves

IEC 61850, Web Services and MQTT. The proposal

features a RESTful web platform able to offer to a

generic user a web service interface to IEC 61850

Servers. The web platform enables the mapping of

information maintained by IEC 61850 server into

MQTT messages. A very limited knowledge is

requested by the Web User in order to be able to

access the services offered by the platform. In

particular, a very simple syntax to explore the IEC

61850 data model is requested without any

knowledge about the IEC 61850 specifications and

any need to use IEC 61850 communication stacks.

The only technologies requested are REST and

MQTT, which are considered the basic ones in the

IoT.

The proposed platform has been implemented

using Java language. The main implementation

choices are the following ones. For the web User

authentication, the standard JSON Web Token was

used (RFC, 2015). The IEC 61860 Client inside the

Middleware has been implemented using the open

source library iec61850bean (IEC61850bean, 2021).

The MQTT Broker has been realized by Mosquitto

1.6.12 (Mosquitto, 2021). The implementation of the

MQTT Publisher inside the Middleware was realized

using Eclipse Paho Java Client (Paho, 2021).

On the Integration of Smart Grid and IoT

715

ACKNOWLEDGEMENTS

The research results presented in this paper have been

achieved inside the PASCAL project (CUP

G79J18000690007) funded by Sicilian region (Italy),

within the European Regional Development (P.O.

FESR 2014 -2020 line 1.1.5).

REFERENCES

Alotaibi, I., Abido, M.A., Khalid, M., Savkin, A.V. (2020).

A comprehensive review of recent advances in smart

grids: A sustainable future with renewable energy

resources. Energies 2020, 13, 6269.

Al-Turjman, F., Abujubbeh, M. (2019). IoT-enabled smart

grid via SM: An overview. Future Gener. Comput. Syst.

2019, 96, 579–590.

Bader, S.R., Maleshkova, M. (2020). SOLIOT—

Decentralized data control and interactions for IoT.

Future Internet 2020, 12, 105.

Benomar, Z., Longo F., Merlino, G., Puliafito, A. (2020).

Enabling Secure RESTful Web Services in IoT using

OpenStack. IEEE 17th International Conference on

Mobile Ad Hoc and Sensor Systems (MASS), 10-13.

Cavalieri, S. (2021). Semantic Interoperability between

IEC 61850 and oneM2M for IoT-Enabled Smart Grids.

Sensors 2021, 21, 2571.

Cavalieri, S., Regalbuto, A. (2016). Integration of IEC

61850 SCL and OPC UA to improve interoperability in

Smart Grid environment. Computer Standard

Interfaces. 2016, 47, 77–99.

Cotrino, A., Sebastián, M.A., González-Gaya, G. (2020).

Industry 4.0 Roadmap: Implementation for small and

medium-sized enterprises. Appl. Sci. 2020, 10, 8566.

Falk, H. (2019). IEC 61850 Demystified, Artech House:

Norwood, MA, USA, 2019. ISBN 978-1-63081-329-1.

Fielding, R.T. (2000). Architectural styles and the design of

network-based software architectures. Ph.D.

dissertation, Dept. Information and Computer Science,

University of California, Irvine, CA, USA, 2000.

Available on line: http://www.ics.uci.edu/~fielding/

pubs/dissertation/top.htm (accessed 17 December

2021)

Hassan, R., Qamar, F., Hasan, M.K., Aman, A.H.M.,

Ahmed, A.S. (2020). Internet of Things and its

applications: A comprehensive survey. Symmetry 2020,

12, 1674.

IEC 61850 (2011). Communication Networks and Systems

for Power Utility Automation; IEC Standards, Parts 1–

10, Edition 2.0. International Electrotechnical

Commission.

IEC61850bean. (2021). Available online: https://www.

beanit.com/iec-61850/ (accessed 17 December 2021).

IETF. (2004). XMPP RFC 3920. Internet Engineering Task

Force. Available online: https://xmpp.org/rfcs/

rfc3920.html (accessed 17 December 2021)

ISO/IEC. (2016). Information technology -- Message

Queuing Telemetry Transport (MQTT). ISO/IEC

20922.

Jun, H.-J., Yang, H.-S. (2021). Performance of the XMPP

and the MQTT Protocols on IEC 61850-Based Micro

Grid Communication Architecture. Energies 2021, 14,

5024.

Lu, Y. (2017). Industry 4.0: A survey on technologies,

applications and open research issues. J. Ind. Inf. Integr.

2017, 6, 1–10.

Mehigan, L., Deane, J.P., Gallachóir, B.P.Ó., Bertsch, V.

(2018). A review of the role of distributed generation

(DG) in future electricity systems. Energy 2018, 163,

822–836.

Mosquitto. (2021). Available online: https://mosquitto.org/

(accessed 17 December 2021).

OASIS. (2014). MQTT Specification. Vers.3.1.1.Available

online: https://mqtt.org/mqtt-specification/ (accessed

17 December 2021).

Paho. (2021). Available online: https://www.eclipse.org/

paho/index.php?page=clients/java/index.php (accessed

17 December 2021).

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

B., Træholt, C., Gantenbein, D. (2010). Facilitating a

Generic Communication Interface to Distributed

Energy Resources: Mapping IEC 61850 to RESTful

Services. Proceedings of the First IEEE International

Conference on Smart Grid Communications,

Gaithersburg, MD, USA, 4–6.

Reka, S.S., Dragicevic, T. (2018). Future effectual role of

energy delivery: A comprehensive review of Internet of

Things and smart grid. Renew. Sustain. Energy Rev.

2018, 91, 90–108.

RFC. (2015). JSON Web Token, RFC 7519, Available

online: https://tools.ietf.org/html/rfc7519. (accessed 17

December 2021).

Richardson, L. , Ruby, S.. (2007). RESTful Web Services.

Sebastopol, CA:O’Reilly, 2007.

Shi, Y., Tuan, H.D., Duong, T.Q., Poor, H.V., Savkin, A.V.

(2020) PMU placement optimization for efficient state

estimation in smart grid. IEEE J. Sel. Areas Commun.

2020, 38, 71–83.

Shin, I.-J., Song, B.-K., Eom, D.-S. (2016). Auto-mapping

and configuration method of IEC 61850 information

model based on OPC UA. Energies 2016, 9, 901.

Tightiz, L., Yang, H. (2020). A comprehensive review on

IoT protocols’ features in smart grid communication.

Energies 2020, 13, 1–24.

Urkia, M.I., Casado-Mansilla, D., Mayer, S., Bilbao, J.,

Urbieta, A. (2018). Integrating electrical substations

within the IoT using IEC 61850, CoAP and CBOR.

IEEE Internet Things Journal. 2018, 14, 8.

Ustun, T.S., Suhail Hussain, S.M.S. (2020). IEC 61850

Modeling of UPFC and XMPP communication for

power management in microgrids. IEEE Access. 2020,

8, 141696–141704.

Xu, L., Yu, X., Gulliver, T.A. (2021). Intelligent outage

probability prediction for mobile IoT networks based

on an IGWO-Elman neural network. IEEE Trans. Veh.

Technol. 2021, 70, 1365–1375.

ICEIS 2022 - 24th International Conference on Enterprise Information Systems

716