Standards-Compliant Chat-Based Middleware Platform for Smart Grid Management

The evolution of power systems towards the Smart Grid has introduced a significant number of unsolved issues degrading its accelerated deployment. The centralized control of distributed energy resources (DER) by utilizing virtual power plants is one of the essential Smart Grid ideas lacking plug and play capability. International standard IEC 61850 defines an architecture for describing Smart Grid subsystems. One of the main IEC 61850 contributions is a data model semantics describing different subsystems used for power systems production. The potential to utilize data semantics for describing DERs along with middleware technologies such as eXtensible Messaging and Presence Protocol (XMPP) can significantly decrease the integration timeframe of advanced power systems architectures such as virtual power plants and microgrids. This paper demonstrates the advantages of using the IEC 61850 standard along with the possibility of utilizing XMPP technology and how this affects new control architectures. Additionally, prototype implementation results are shown depending on the different communication infrastructure settings and application types used for DER control.


Introduction
A Smart Grid is an electricity network that can cost-efficiently integrate the behavior and actions of all users connected to it-generators, consumers and those that do both-in order to ensure an economically efficient, sustainable power system with low losses and high levels of quality and security of supply and safety [1].Its aim is to distribute and deliver sustainable and economically viable energy in an efficient manner.The large-scale integration of distributed energy resources (DERs) is one of the main Smart Grid pillars that is also making visible the issues involved in solving power system stability and regulation [2].These solutions are of key value as recent energy strategies emphasize the importance of giving the power of energy transition into the hands of end prosumers [3].The empowerment of a prosumer-based energy system, whether it is in the context of energy communities, microgrids [4], virtual power plants [5] or other aggregator-based concepts [6], changes not only the operational and planning concepts of today's conventional single direction power system, but also all aspects of communication and data exchange.
Virtual power plants can be regarded as a number of DERs that act as self-contained units in power system dynamics and the electricity market.They represent a suitable control architecture for DER management and control.Accelerated virtual power plant integration requires suitable communication technologies and a data model that could facilitate DER integration processes [7,8].Standardization activities along with leading power system automation equipment manufacturers have provided several guidelines on how to use interoperable devices in the Smart Grid.All mentioned guidelines share common principles: standards-based integration of intelligent devices is a key prerequisite for successful and secure Smart Grid deployment [9], and all referenced guidelines recommend the IEC 61850 standard as a crucial document defining Smart Grid automation rules [10].This paper describes the benefits of using the IEC 61850 standard along with eXtensible Messaging and Presence Protocol (XMPP) middleware technology [11].XMPP is commonly used for developing chat-based applications on the Web.XMPP based IEC 61850 mapping has already been analyzed in several papers [12][13][14].Afteal et al. [12] analyzed the IEC 61850 semantic models describing the data exchange between microgrids and electric vehicles (EV) required for energy management.They provide Abstract Communication Service Interface (ACSI) mapping analysis for XMPP communication services but the XMPP stack implementation, and performance measurements are out of the scope of the paper.Similarly, Hussein et al. [13] modeled the IEC 61850 STATCOM data model required for reactive power management in microgrids.They provide a detailed use case and communication architecture, but the XMPP stack implementation is out of the scope of the paper.Fries et al. [14] analyzed the security architecture required by IEC 61850 systems based on XMPP mapping not dealing with the implantation limitations.
The original contribution of this paper compared to other papers is that an XMPP-based IEC 61850 stack was implemented and thoroughly analyzed.The stack was tested for specific IEC 61850 data management use cases in order to demonstrate the feasibility of the proposed solution.The testing results benchmarked key communication stack features and provided insights for real-world virtual power plant applications.It was shown that XMPP features can streamline and accelerate the deployment of DERs in Smart Grid management applications.

Middleware Selection
Even though the IEC 61850 is primarily made for substation automation, its further releases allowed its expansion for wind power plants, hydropower plants and other Smart Grid subsystems [15].The IEC 61850 defines data models enabling interoperability of different automation equipment vendors.Along with standardized data models, it also defines abstract communication services that can be used for data exchange based on different middleware technology [16].Motivation to use XMPP, compared to other middleware platforms [17], is the widespread use of XMPP.XMPP enables two-way data exchange via HTTP, presence monitoring of new system users, and dynamic addition of new users.An additional advantage to XMPP is relaying client and server architecture, therefore, enabling multi-user chat-based applications.Regarding power systems data exchange, both client and server are represented as XMPP application-level clients that exchange information in the form of chat-based applications.This feature makes it so that electricity producers and consumers can be assembled in dynamic and adaptable automation architecture such as virtual power plants or microgrids, as shown in Figure 1.
The following section provides the IEC 61850 standard and XMPP overview outlining integration requirements.The Section 4 describes the semantics enablement process based on IEC 61850 and XMPP middleware.The Section 5 shows the relationship between abstract services and XMPP data exchange mechanisms.The last section gives an overview of the prototype IEC 61850 application implementation based on XMPP middleware.The following section provides the IEC 61850 standard and XMPP overview outlining integration requirements.The fourth section describes the semantics enablement process based on IEC 61850 and XMPP middleware.The fifth section shows the relationship between abstract services and XMPP data exchange mechanisms.The last section gives an overview of the prototype IEC 61850 application implementation based on XMPP middleware.

IEC 61850 and XMPP Smart Grid Automation
IEC 61850 is often regarded as just another telecontrol protocol used for remote Intelligent Electronic Device (IED) management, but the standard represents significantly more than a set of encoding and data exchange rules for automated subsystems [18].The IEC 61850 expands towards functional aspects by standardizing data semantics and providing guidelines for client-server (vertical) and peer-to-peer (horizontal) communication [15].Moreover, it defines abstract communication services enabling usage of different middleware technologies.Despite this fact, the only standardized mapping platform is based on the Manufacturing Message Specification (MMS) [19].However, XMPP capabilities have been recognized by standardization experts, who are working towards developing standardized XMPP mapping for the IEC 61850.
XMPP is a set of open technologies commonly used for instant messaging applications (e.g., online chatting), presence publishing, multi-user chat, and eXtesnible Markup Language (XML) streaming.The main advantages of XMPP include:

IEC 61850 and XMPP Smart Grid Automation
IEC 61850 is often regarded as just another telecontrol protocol used for remote Intelligent Electronic Device (IED) management, but the standard represents significantly more than a set of encoding and data exchange rules for automated subsystems [18].The IEC 61850 expands towards functional aspects by standardizing data semantics and providing guidelines for client-server (vertical) and peer-to-peer (horizontal) communication [15].Moreover, it defines abstract communication services enabling usage of different middleware technologies.Despite this fact, the only standardized mapping platform is based on the Manufacturing Message Specification (MMS) [19].However, XMPP capabilities have been recognized by standardization experts, who are working towards developing standardized XMPP mapping for the IEC 61850.
XMPP is a set of open technologies commonly used for instant messaging applications (e.g., online chatting), presence publishing, multi-user chat, and eXtesnible Markup Language (XML) streaming.The main advantages of XMPP include:

•
Openness (standardized, publicly available specifications) XMPP offers several advantages above MMS, and the most obvious of these are presence publishing and XML streaming over servers.XMPP features such as expandability, flexibility, and diversity make it a suitable replacement candidate for MMS and for enabling Smart Grid accelerated integration, which has been recognized in the IEC 61850-80-3 [20].

XMPP and IEC 61850 Mapping Prerequisites
In order to use XMPP as underlying IEC 61850 technology, it is necessary to fulfill two basic mapping requirements:

•
Represent the IEC 61850 data model in the form of XML structures • Enable IEC 61850 data-exchange services in the form of XMPP services By taking into account these requirements, it is possible to utilize MMS (Abstract Syntax Notation One) ASN.1 [21] definitions for the mapping process and therefore, enable application-level logic compatibility with already existing IEC 61850 management applications.The following sections show IEC 61850 and XMPP feature mapping analysis.

IEC 61850 Data Model Adapted to the XMPP Middleware
The IEC 61850 data semantics is based on devices' functionalities in their utility subsystems.It is enabled over object-oriented data modeling to enable direct hierarchies for remote monitoring and control.This section shows an overview of the method for mapping the IEC 61850 data model for transmitting via XMPP middleware.

IEC 61850 Data Model
The IEC 61850 data model is based on a hierarchical structure, as shown in Figure 2. The top-level class is Physical Device (PD) and represents real physical devices, e.g., the IEC 61850 physical server.PD includes one or more logical devices (LD) representing a virtual instance of monitoring, controlling or protection equipment inside automated subsystems.LD consists of several Logical Nodes (LNs), which represent equipment functions.Therefore, LNs are basic elements of the IEC 61850 semantic structure.The first letter of LN notation defines function group while the rest of LN notation marks function.Common Data Classes (CDCs) enable the creation of domain specific information models used by namespaces.Instanced CDCs create Data Objects (DOs) that are included in the LN structure.Data Attributes (DAs) are leaf attributes.DOs and DAs can be nested recursively.Each DA can be limited with Functional Constraint (FC).Application level reference to the DOs and its subtypes can be organized in the Data Sets (DSs).

•
Community support (number of well supported open source implementations) XMPP offers several advantages above MMS, and the most obvious of these are presence publishing and XML streaming over servers.XMPP features such as expandability, flexibility, and diversity make it a suitable replacement candidate for MMS and for enabling Smart Grid accelerated integration, which has been recognized in the IEC 61850-80-3 [20].

XMPP and IEC 61850 Mapping Prerequisites
In order to use XMPP as underlying IEC 61850 technology, it is necessary to fulfill two basic mapping requirements:

•
Represent the IEC 61850 data model in the form of XML structures • Enable IEC 61850 data-exchange services in the form of XMPP services By taking into account these requirements, it is possible to utilize MMS (Abstract Syntax Notation One) ASN.1 [21] definitions for the mapping process and therefore, enable application-level logic compatibility with already existing IEC 61850 management applications.The following sections show IEC 61850 and XMPP feature mapping analysis.

IEC 61850 Data Model Adapted to the XMPP Middleware
The IEC 61850 data semantics is based on devices' functionalities in their utility subsystems.It is enabled over object-oriented data modeling to enable direct hierarchies for remote monitoring and control.This section shows an overview of the method for mapping the IEC 61850 data model for transmitting via XMPP middleware.

IEC 61850 Data Model
The IEC 61850 data model is based on a hierarchical structure, as shown in Figure 2. The toplevel class is Physical Device (PD) and represents real physical devices, e.g., the IEC 61850 physical server.PD includes one or more logical devices (LD) representing a virtual instance of monitoring, controlling or protection equipment inside automated subsystems.LD consists of several Logical Nodes (LNs), which represent equipment functions.Therefore, LNs are basic elements of the IEC 61850 semantic structure.The first letter of LN notation defines function group while the rest of LN notation marks function.Common Data Classes (CDCs) enable the creation of domain specific information models used by namespaces.Instanced CDCs create Data Objects (DOs) that are included in the LN structure.Data Attributes (DAs) are leaf attributes.DOs and DAs can be nested recursively.Each DA can be limited with Functional Constraint (FC).Application level reference to the DOs and its subtypes can be organized in the Data Sets (DSs).61850-8-1 [22] and which are therefore inherited from the MMS standard.Moreover, XML-based XMPP messages are compliant to MMS notation.The IEC 61850-7-2 [23] document defines an algorithm for mapping MMS Named Variables (NV) to the LN instances, as shown in Figure 3.Each NV consists of an LN instance and the rest of the hierarchical structure consisting of several nested levels.Figure 4 shows an example of such a structure.In case there is no DO defined by instanced FC, this DO will not be shown as a part of the NV.The order of the FC subcomponents is defined in Subsystem Configuration Language (SCL) DOs.Furthermore, the order of DO subcomponents are defined in CDCs. Figure 4 shows the LN data hierarchy.NV hierarchical structure can present the LN as a set of separated NVs, i.e., each for every component (node or leaf) in the hierarchical structure.The name of the NV that maps to the tree component is made by concatenating component names available in the component path.Concatenation is delimited with the character "$".Full NV names are shown in Figure 5.The aforementioned procedure enables seamless mapping of tree-based MMS structures into the XML as the first precondition for mapping the IEC 61850 to the XMPP chat-based middleware.

IEC 61850 Data Model Mapping to XMPP
XMPP uses XML Schema Definition (XSD) for sending messages which describe the main association context.Mapping IEC 61850 objects use several concepts already defined in the IEC 61850-8-1 [22] and which are therefore inherited from the MMS standard.Moreover, XML-based XMPP messages are compliant to MMS notation.The IEC 61850-7-2 [23] document defines an algorithm for mapping MMS Named Variables (NV) to the LN instances, as shown in Figure 3.Each NV consists of an LN instance and the rest of the hierarchical structure consisting of several nested levels.Figure 4 shows an example of such a structure.In case there is no DO defined by instanced FC, this DO will not be shown as a part of the NV.The order of the FC subcomponents is defined in Subsystem Configuration Language (SCL) DOs.Furthermore, the order of DO subcomponents are defined in CDCs. Figure 4 shows the LN data hierarchy.NV hierarchical structure can present the LN as a set of separated NVs, i.e., each for every component (node or leaf) in the hierarchical structure.The name of the NV that maps to the tree component is made by concatenating component names available in the component path.Concatenation is delimited with the character "$".Full NV names are shown in Figure 5.The aforementioned procedure enables seamless mapping of tree-based MMS structures into the XML as the first precondition for mapping the IEC 61850 to the XMPP chat-based middleware.

IEC 61850 Data Model Mapping to XMPP
XMPP uses XML Schema Definition (XSD) for sending messages which describe the main association context.Mapping IEC 61850 objects use several concepts already defined in the IEC 61850-8-1 [22] and which are therefore inherited from the MMS standard.Moreover, XML-based XMPP messages are compliant to MMS notation.The IEC 61850-7-2 [23] document defines an algorithm for mapping MMS Named Variables (NV) to the LN instances, as shown in Figure 3.Each NV consists of an LN instance and the rest of the hierarchical structure consisting of several nested levels.Figure 4 shows an example of such a structure.In case there is no DO defined by instanced FC, this DO will not be shown as a part of the NV.The order of the FC subcomponents is defined in Subsystem Configuration Language (SCL) DOs.Furthermore, the order of DO subcomponents are defined in CDCs. Figure 4 shows the LN data hierarchy.NV hierarchical structure can present the LN as a set of separated NVs, i.e., each for every component (node or leaf) in the hierarchical structure.The name of the NV that maps to the tree component is made by concatenating component names available in the component path.Concatenation is delimited with the character "$".Full NV names are shown in Figure 5.The aforementioned procedure enables seamless mapping of tree-based MMS structures into the XML as the first precondition for mapping the IEC 61850 to the XMPP chat-based middleware.

IEC 61850 and XMPP Data Exchange Mechanisms
The ACSI [23] is a new paradigm defined by the IEC 61850 standard to describe data exchange procedures in subsystems such as substations or virtual power plants.The ACSI enables the use of different implementation technologies such as chat-based XMPP to provide an IEC 61850 compliant communication.ACSIs required for developing Smart Grid management applications are: ACSIs define a standardized interface for data exchange between devices realized as IEC 61850 servers.Therefore, any IEC 61850 compliant client application can fully control and manage an automated IEC 61850 subsystem.ACSI messages can be divided into request/response and spontaneous (unsolicited) messages.Both message commutation types can be shown as XML messages transmitted between a called and calling application via XMPP protocol.XMPP architecture enables XML data streaming over an additional XMPP server acting as a relay.XML messages representing ACSI services are called stanzas.Each stanza is sent in a data stream from the XMPP source and is relayed through a new XMPP data stream.Each XML message consists of three separated, nested parts: • Service PDU-enables ACSI service and is placed in the most nested stanza level.It is represented as <confirmed-RequestPDU> or <confirmed-ResponsePDU> for each request or reply message, or <unconfirmed-PDU> for spontaneous messages.• Secure PDU-encapsulates Service PDU and includes security information such as certificates, session keys, and other parameters.This information is used for enabling a secure end-to-end communication channel.• Association Context-direct XMPP stanza child encapsulating Service PDU and Secure PDU.It transfers attribute ID to create and maintain application association.
An XML message example representing a GetDataValues request is shown in Figure 6.A described mapping process fulfills the second precondition for transferring IEC 61850 messages over

IEC 61850 and XMPP Data Exchange Mechanisms
The ACSI [23] is a new paradigm defined by the IEC 61850 standard to describe data exchange procedures in subsystems such as substations or virtual power plants.The ACSI enables the use of different implementation technologies such as chat-based XMPP to provide an IEC 61850 compliant communication.ACSIs required for developing Smart Grid management applications are:

•
Association ACSI-enables managing two-way data exchange between clients and servers ACSIs define a standardized interface for data exchange between devices realized as IEC 61850 servers.Therefore, any IEC 61850 compliant client application can fully control and manage an automated IEC 61850 subsystem.ACSI messages can be divided into request/response and spontaneous (unsolicited) messages.Both message commutation types can be shown as XML messages transmitted between a called and calling application via XMPP protocol.XMPP architecture enables XML data streaming over an additional XMPP server acting as a relay.XML messages representing ACSI services are called stanzas.Each stanza is sent in a data stream from the XMPP source and is relayed through a new XMPP data stream.Each XML message consists of three separated, nested parts:

•
Service PDU-enables ACSI service and is placed in the most nested stanza level.It is represented as <confirmed-RequestPDU> or <confirmed-ResponsePDU> for each request or reply message, or <unconfirmed-PDU> for spontaneous messages.

•
Secure PDU-encapsulates Service PDU and includes security information such as certificates, session keys, and other parameters.This information is used for enabling a secure end-to-end communication channel.

•
Association Context-direct XMPP stanza child encapsulating Service PDU and Secure PDU.It transfers attribute ID to create and maintain application association.
An XML message example representing a GetDataValues request is shown in Figure 6.A described mapping process fulfills the second precondition for transferring IEC 61850 messages over the chat-based XMPP middleware.An example of the communication profile provided by XMPP is shown in Figure 7.

Prototype Testing Results Overview
In this paper, testing the prototype implementation of using IEC 61850 data traffic over XMPP was done on Local Area Network (LAN) and Wide Area Network (WAN) networks.Both testing environments included three computers: an IEC 61850-8-2 client, a server and an XMPP server for forwarding network traffic, as shown in Figure 8.
A complete LAN network was set up in an office on company premises, while the WAN network was set up between Croatia and Greece over the public Internet.The network topology was dependent on Internet Service providers.All testing services were based on ping-pong methodology, as shown in Figure 8. Depending on the testing type, parameter ttotal represents the cumulative time required for the test.the chat-based XMPP middleware.An example of the communication profile provided by XMPP is shown in Figure 7.

Prototype Testing Results Overview
In this paper, testing the prototype implementation of using IEC 61850 data traffic over XMPP was done on Local Area Network (LAN) and Wide Area Network (WAN) networks.Both testing environments included three computers: an IEC 61850-8-2 client, a server and an XMPP server for forwarding network traffic, as shown in Figure 8.
A complete LAN network was set up in an office on company premises, while the WAN network was set up between Croatia and Greece over the public Internet.The network topology was dependent on Internet Service providers.All testing services were based on ping-pong methodology, as shown in Figure 8. Depending on the testing type, parameter ttotal represents the cumulative time required for the test.

Prototype Testing Results Overview
In this paper, testing the prototype implementation of using IEC 61850 data traffic over XMPP was done on Local Area Network (LAN) and Wide Area Network (WAN) networks.Both testing environments included three computers: an IEC 61850-8-2 client, a server and an XMPP server for forwarding network traffic, as shown in Figure 8.
A complete LAN network was set up in an office on company premises, while the WAN network was set up between Croatia and Greece over the public Internet.The network topology was dependent on Internet Service providers.All testing services were based on ping-pong methodology, as shown in Figure 8. Depending on the testing type, parameter ttotal represents the cumulative time required for the test.

Unsolicited Messages Testing
Testing unsolicited messages was based on sending larger data sets (10-100 items).Data sets for each test were incremented by 10.Testing was done for 1000 iterations to show the box plot diagram.The timestamp ttotal shows the total time from sending a request from the IEC 61850-8-2 client to the start of the reporting mechanism, to sending a request through towards the IEC 61850 server where the request was analyzed and finally sent towards the client via the XMPP server.Results are shown in quartiles (Figure 9).Minimal value is shown by the line on the left side of the box; the second quartile is shown in the blue box surrounded by an orange line (representing the median value) the third box on the right side of the square shows the maximal value in the fourth box.Figure 9 shows the ttotal parameters for experiments done in LAN, and Figure 10 the experiments done in WAN.The results demonstrated that increasing datasets elements increased time delays linearly in both LAN and WAN however, in WAN with significantly more upward slope and a larger number of outliers.The median ttotal in both cases were below 1s, making it suitable for slow automatic interactions such as retrieving measurement updates.

Unsolicited Messages Testing
Testing unsolicited messages was based on sending larger data sets (10-100 items).Data sets for each test were incremented by 10.Testing was done for 1000 iterations to show the box plot diagram.The timestamp t total shows the total time from sending a request from the IEC 61850-8-2 client to the start of the reporting mechanism, to sending a request through towards the IEC 61850 server where the request was analyzed and finally sent towards the client via the XMPP server.Results are shown in quartiles (Figure 9).Minimal value is shown by the line on the left side of the box; the second quartile is shown in the blue box surrounded by an orange line (representing the median value) the third box on the right side of the square shows the maximal value in the fourth box.Figure 9 shows the t total parameters for experiments done in LAN, and Figure 10 the experiments done in WAN.The results demonstrated that increasing datasets elements increased time delays linearly in both LAN and WAN however, in WAN with significantly more upward slope and a larger number of outliers.The median t total in both cases were below 1s, making it suitable for slow automatic interactions such as retrieving measurement updates.

Testing Request-Response Messages Testing
For request-response messages, t total represents total time starting from sending a request message sent from the IEC 61850 client side, relayed over the XMPP server and forwarded towards the IEC 61850-8-2 server and received back towards the client.Testing request-response messages were done via the Write request Service on the LAN and WAN networks.Figure 11 shows the ttotal parameters for experiments done in LAN, and Figure 12 the experiments done in WAN.The median value in both cases was below 1 s, making it possible to conduct Human Machine Interface (HMI) control and slow automatic interactions.

Testing Request-Response Messages Testing
For request-response messages, ttotal represents total time starting from sending a request message sent from the IEC 61850 client side, relayed over the XMPP server and forwarded towards the IEC 61850-8-2 server and received back towards the client.Testing request-response messages were done via the Write request Service on the LAN and WAN networks.Figure 11 shows the ttotal parameters for experiments done in LAN, and Figure 12 the experiments done in WAN.The median value in both cases was below 1 s, making it possible to conduct Human Machine Interface (HMI) control and slow automatic interactions.

Testing Encryption Mechanism Latencies
Fries et al. [14] provide an overview of cybersecurity mechanisms required by IEC 61850 systems.A detailed analysis of IEC 61850 cybersecurity is out of the scope of this paper.However, significant implications to communication latencies of time-critical data exchange can be introduced by encryption mechanisms.Therefore, an aspect of cybersecurity has been analyzed.Figure 13 shows the time difference between encrypted and unencrypted reports with a 100 item dataset.The average difference for the encrypted and unencrypted report was 20 ms. Figure 14 shows a Write service response time for encrypted and unencrypted traffic.The average differences were less than 1ms.These results implied that that using message encryption is a suitable solution for XMPP mapping as part of cyber security mechanisms.

Testing Encryption Mechanism Latencies
Fries et al. [14] provide an overview of cybersecurity mechanisms required by IEC 61850 systems.A detailed analysis of IEC 61850 cybersecurity is out of the scope of this paper.However, significant implications to communication latencies of time-critical data exchange can be introduced by encryption mechanisms.Therefore, an aspect of cybersecurity has been analyzed.Figure 13 shows the time difference between encrypted and unencrypted reports with a 100 item dataset.The average difference for the encrypted and unencrypted report was 20 ms. Figure 14 shows a Write service response time for encrypted and unencrypted traffic.The average differences were less than 1ms.These results implied that that using message encryption is a suitable solution for XMPP mapping as part of cyber security mechanisms.

Conclusion
The development of power systems towards the Smart Grid is a complex and effortful mission.Group DER management and control is one of the most difficult Smart Grid problems where

Conclusions
The development of power systems towards the Smart Grid is a complex and effortful mission.Group DER management and control is one of the most difficult Smart Grid problems where streamlined virtual power plant integration is enabled by the utilization of standards-compliant Smart Grid communication.Introducing XMPP as chat-based middleware is one of the possible integration approaches that could provide an adequate solution.
This paper proposed the utilization of XMPP together with the IEC 61850 communication standard for large scale Smart Grid architectures such as virtual power plants.The main features of IEC 61850 and XMPP have been compared.It has been shown that the IEC 61850 data model is essential for data semantics in Smart Grid applications where DERs are utilized as standardized semantic services.The proposed automation architecture is flexible, adaptable and scalable and therefore can be regarded as a promising technological candidate that could accelerate the integration of new automation architecture such as virtual power plants and microgrids.The communication stack implementation was tested according to specific IEC 61850 data management use cases.The conducted tests have shown that the proposed solution is feasible and suitable for the remote monitoring and management of DERs by utilizing a chat-based middleware platform.Encryption of IEC 61850 data traffic has also been tested and this demonstrated its sucessful applicability as part of cybersecurity mechanisms due to the fact that it does not introduce significant data exchange latencies.

Figure 1 .
Figure 1.Chat-based middleware platform for Smart Grid management.

Figure 1 .
Figure 1.Chat-based middleware platform for Smart Grid management.

4. 2 .
IEC 61850 Data Model Mapping to XMPP XMPP uses XML Schema Definition (XSD) for sending messages which describe the main association context.Mapping IEC 61850 objects use several concepts already defined in the IEC Energies 2019, 12, 694 5 of 12

•
Association ACSI-enables managing two-way data exchange between clients and servers • Data model ACSI-enables managing and browsing of data structures • Setting group ACSI-enables selecting a predefined set of values for a set of DOs • Control ACSI-enables sending control commands • Reporting ACSI-enables event-based data exchange based on a publish/subscribe paradigm • Logging ACSI-enables archiving historical data

Figure 7 .
Figure 7. IEC 61850 communication profile based on eXtensible Messaging and Presence Protocol (XMPP) middleware.

Figure 9 .
Figure 9. Transferring unsolicited reports in LAN.Figure 9. Transferring unsolicited reports in LAN.

Figure 10 .
Figure 10.Transferring unsolicited reports in WAN.Figure 10.Transferring unsolicited reports in WAN.

Figure 11 .
Figure 11.Write request Service in LAN.

Figure 12 .
Figure 12.Write request Service in WAN.

Figure 14 .
Figure 14.Write service response time for encrypted and unencrypted traffic.