Modeling and Integrating PV Stations into IEC 61850 XMPP Intelligent Edge Computing Gateway

Distributed energy resources (DERs) are being widely interconnected to electrical power grids. The dispersed and intermittent generational mixes bring technical and economic challenges to the power systems in terms of stability, reliability, and interoperability. In practice, most of the communication technologies in DER are provided by proprietary communication protocols, which are not designed for the prevention of cyber security over a wide area network, and methodology of DER integration is not unified. This has made it technically difficult for power utilities and aggregators to monitor and control the DER systems after they are interconnected with the electrical grids. Moreover, peer to peer communication between DER systems as well as local intelligent computation is required to reduce decision latency and enhance the stability of the smart grid or microgrid. In this paper, the first, novel architecture of IEC 61850 XMPP (extensible messaging and presence protocol) of the edge computing gateway, involving advanced concepts and technologies, was developed and completely studied to counter the abovementioned challenges. The results show that the proposed architecture can enhance the DER system’s effective integration, security in data communication and transparency for interoperability. The novel and advanced concepts involve first modeling the topology of the photovoltaic (PV) station to IEC 61850 information models according to the IEC 61850-7-4 logical nodes and the DER-specific logical nodes defined in IEC 61850-7-420. This guarantees the interoperability between DER and DER, DER and utility and DER and the energy service operator. The second step was to map the information models to IEC 61850-8-2 XMPP for the specific communication protocol in DER applications. XMPP protocol, a publish/subscribe communication mechanism, is recommended in DER applications because of its characteristics of cybersecurity and authenticated encryption. After that we enabled the edge computing capability for data processing and the analytics of the DER side for time-critical missions. The aggregated data was then sent to the control center in the cloud. By applying the edge computing architecture, the system reduced decision latency, improved data privacy and enhanced security. The goal of this paper was to introduce the practical methodologies of these novel concepts to academics and industrial engineers.


Introduction
Overexploitation of fossil fuel is a critical issue that impacts the Earth's environment and brings catastrophic disasters to the human race; moreover, the ever-growing demand for energy usage accelerates these situations.Renewable energy is a new type of energy resource that is a clean and environmentally friendly energy generation approach.As of today, the energy source transition from traditional fossil fuels to renewable energy is quickly accelerating.According to the DNV GL (an international accredited registrar and classification society) Energy Transition Outlook 2018, energy development, policy, and investment continue to favor renewable technologies.As of 2050, the energy Page 2 of 23 popularity and supplying more than two-thirds of the energy generation in the world while the traditional energy sources such as coal and oil are dramatically reduced [1].The development of the energy resource paradigm is shifting toward Distributed Energy Resource (DER), an irrevocable trend.The authors of Reference [2] summarized the global DER development: Total DER implementation will be equal to fossil oil-based generation worldwide, and the high penetration of DER brings unprecedented challenges to the power systems in terms of grid stability, reliability, and efficiency.According to the International Energy Agency (EIA), China, the USA, Germany, and India are the major producers of DER generation.Figure 1 presents the DER installations as of 2018; Wind power, solar PV (Photovoltaic), hydropower and bio-power have reached 646.9 GW, 240.9 GW, 111.6 GW, and 106 GW from China, the USA, Germany, and India respectively [3].
Due to the intermittent power generation of DER, especially for solar PV and wind power, which are highly dependent on weather conditions and uncontrollable, the increasing penetration of DERs in the grid brings technical and operational challenges, for example, voltage instability, asset degradation, and duck curve related issues such as the complexity of the reserve margin and spinning reserves in base-load generation plants, the fast ramping rates of the generation units, and high rotational inertia and frequency control reserves [4][5][6].DER devices are dispersed everywhere in a decentralized system, and the system has various generational characteristics, multi-vendor equipment with proprietary protocols, large amounts of data transmission, remote device management, cybersecurity, and data security.Therefore, the key challenges in terms of integrating DER systems are the standardization of the communication architecture and the unification of the data models for all types of renewable energy resources.Cyber and data security must be taken into consideration as the data are transmitted over a wide area network that is susceptible to cyber-attack if no proper measure is applied.The IEC 61850 standard was developed by the International Electrotechnical Commission (IEC) for the interoperability and communication of power system applications [7].This standard was initially applied in substation automated communication within a local area network.Some research has been conducted studying different levels of IEC 61850 for substation automation, such as the process level, bay level and station level.However, in recent studies, the IEC 61850 standard was extended to applications in wide area networks to fit the smart grid related applications in which the DER system is included [8].In recent years, several works have introduced IEC 61850 standards for The IEC 61850 standard was developed by the International Electrotechnical Commission (IEC) for the interoperability and communication of power system applications [7].This standard was initially applied in substation automated communication within a local area network.Some research has been conducted studying different levels of IEC 61850 for substation automation, such as the process level, bay level and station level.However, in recent studies, the IEC 61850 standard was extended to applications in wide area networks to fit the smart grid related applications in which the Energies 2019, 12, 1442 3 of 23 DER system is included [8].In recent years, several works have introduced IEC 61850 standards for DER integration.For example, in earlier reference [9] two testbeds to standardize the communication architecture and integration of DER using IEC 61850 were applied in the Korea Smart Grid Energy Research Center and the Korea Institute of Energy Research.The authors of References [10][11][12][13] presented the testbeds for DER integration based on the IEC 61850 standard and introduced the concept of DER data models according to IEC 61850-7-420.In Reference [14], the authors introduced research for the integration of IEC 61850 into a vehicle-to-grid system.The authors of Reference [15] proposed protocol translation between Modbus and IEC 61850 in a distributed DER based on diesel generators and conducted a thorough test for latency performance.However, none of these research papers have conducted a complete study or complied new standard for DER integration considering network topology, cybersecurity, data security, and standardization of data models.Moreover, previous research introduced IEC 61850 based on the manufacturing message specification (MMS) protocol (IEC 61850-8-1), which is not originally designed to address wide area networks.The DER system is truly an application based on wide area network as its large-scale connections of devices dynamically changes the network topology.In this paper, the novel concepts of IEC 61850-8-2 XMPP and edge computing gateway were studied, implemented and tested.
The edge computing gateway is a decentralized computing infrastructure by which computing resources and application services can be distributed and located near the end devices.Its features include data collection, protocol conversion, data model building, data storage, intelligent computing, data analytics and decision-taking.It communicates with the service in the cloud or a central server.The benefits of the edge computing gateway are its improved performance, compliance, and data privacy, and data security concerns are satisfied and operational cost is reduced [16].Figure 2 shows various protocols, such as IEC 870, DNP3, Modbus, OPC, BACnet, SNMP and IEC 61850, being integrated and the information being mapped to the data model of DER based on IEC 61850-7-4 and IEC 61850-7-420, to guarantee the interoperability of the applications.The IEC 61850-8-2 XMPP communication protocol, a publish/subscribe communication mechanism, was implemented in the DER application because of its strong cybersecurity and user registry characteristics.The edge computing gateway enables the capability of data processing and analytics in every DER site for time-critical missions to reduce the decision latency and improve data privacy and security.This paper presents the practical methodologies of DER integration and guides the state-owned Taiwan Power Research Institute toward implementation of Taiwan's DER applications based on the IEC 61850 standards and the Internet of Things technologies.
Page 3 of 23 DER integration.For example, in earlier reference [9] two testbeds to standardize the communication architecture and integration of DER using IEC 61850 were applied in the Korea Smart Grid Energy Research Center and the Korea Institute of Energy Research.The authors of References [10][11][12][13] presented the testbeds for DER integration based on the IEC 61850 standard and introduced the concept of DER data models according to IEC 61850-7-420.In Reference [14], the authors introduced research for the integration of IEC 61850 into a vehicle-to-grid system.The authors of Reference [15] proposed protocol translation between Modbus and IEC 61850 in a distributed DER based on diesel generators and conducted a thorough test for latency performance.However, none of these research papers have conducted a complete study or complied new standard for DER integration considering network topology, cybersecurity, data security, and standardization of data models.Moreover, previous research introduced IEC 61850 based on the manufacturing message specification (MMS) protocol (IEC 61850-8-1), which is not originally designed to address wide area networks.The DER system is truly an application based on wide area network as its large-scale connections of devices dynamically changes the network topology.In this paper, the novel concepts of IEC 61850-8-2 XMPP and edge computing gateway were studied, implemented and tested.
The edge computing gateway is a decentralized computing infrastructure by which computing resources and application services can be distributed and located near the end devices.Its features include data collection, protocol conversion, data model building, data storage, intelligent computing, data analytics and decision-taking.It communicates with the service in the cloud or a central server.The benefits of the edge computing gateway are its improved performance, compliance, and data privacy, and data security concerns are satisfied and operational cost is reduced [16].Figure 2 shows various protocols, such as IEC 870, DNP3, Modbus, OPC, BACnet, SNMP and IEC 61850, being integrated and the information being mapped to the data model of DER based on IEC 61850-7-4 and IEC 61850-7-420, to guarantee the interoperability of the applications.The IEC 61850-8-2 XMPP communication protocol, a publish/subscribe communication mechanism, was implemented in the DER application because of its strong cybersecurity and user registry characteristics.The edge computing gateway enables the capability of data processing and analytics in every DER site for time-critical missions to reduce the decision latency and improve data privacy and security.This paper presents the practical methodologies of DER integration and guides the state-owned Taiwan Power Research Institute toward implementation of Taiwan's DER applications based on the IEC 61850 standards and the Internet of Things technologies.

Importance of PV Modeling in DER Management
With the growing demand for green energy production, the number of DERs connected to the power grid is continuously increasing.The decentralization of electric power production is motivated by an increased global demand for efficient, cost-effective, and reliable electrical energy, but also an increasing demand for renewable energy sources to reduce the usage of conventional energy resources known to be responsible for polluting emissions and many fields of energy market deregulation.This increasing demand for DER management systems requires standards to resolve the issue of interoperability between different equipment, which was a recurrent problem when equipment vendors developed their own protocols.By using standards, grid-connected DER devices ensure interoperability, resulting in easier implementation, lower maintenance costs, and better performance [17].

IEC 61850 Standardized Communication for Distributed Energy Resources
IEC 65850 is an international standard designed for substation automation that effectively reduces the complexity and diversity of utility automated solutions and minimizes engineering, operating and maintenance costs.The IEC 61850 standard has a model-driven approach that describes the communication between equipment in a substation and the related system requirements.It features all substation functions and engineering by using object-oriented data models that describe the processes to be controlled and implemented.IEC 61850 features device models that describe physical devices with properties and the allocation of functions.It also defines generic services for the transfer of all types of data and the client/server interactions between substation devices while respecting transmission requirements such as reliability, security, and speed.
IEC 61850-7-4 is an extension of compatible data classes and logical nodes applied to power generation equipment such as solar panels, diesel, fuel cells, and combined heat and power.It includes:

•
Interconnection management between the DER unit and the power systems to which they are connected, such as local power systems, protection devices, and circuit breakers.

•
Controlling and monitoring of the DER.
In IEC 61850-7-420, the systems are modeled in a holistic manner.DER characteristics for internal parameters, types of grid connections, microgrid operating commands, and control units are described.The IEC 61850-7-420 logical nodes can be grouped into the following categories: DER unit controllers, grid connection units, network operator units and, internal parameters [18].

IEC 61850-7-420 Model for Photovoltaic Systems
In IEC 61850-7-420, specific logical nodes have described the photovoltaic system information models as a major source of electrical energy.Figure 3 shows typical logical nodes associated with a photovoltaic system configuration and Table 1 shows the abbreviations of logical nodes.Real implementations differ according to the system requirements [19,20].
The following functions would be required for logical devices to automate the operation of a PV system: • Array operation functions to maximize the array power output.It includes adjustments of voltage and current levels to acquire the cell's maximum power point and the operation of a tracking system to follow the movement of the sun.Logical nodes are included in the specific IEC 61850-7-420 standard DPVC, DTRC.

•
Islanding functions to synchronize operations between the PV systems and the power systems.Logical nodes are covered in the specific IEC 61850-7-420 standard DOPR, DRCT, and RSYN is covered in IEC 61850-7-4.

•
Energy storage functions to store excess energy produced by the system.Batteries for energy storage are included in the IEC 61850-7-420 standard with ZBAT, ZBTC.

•
Meteorological monitoring functions to acquire meteorological measurements like ambient temperature and solar irradiation.These are covered in MMET and STMP in IEC 61850-7-420 [21].The following functions would be required for logical devices to automate the operation of a PV system: • Switchgear operation functions to disconnect devices and monitor and control breakers.Logical nodes are already defined in IEC 61850-7-4, XCBR, CSWI, XSWI, etc.
• Protection functions to protect personnel and electrical equipment in the case of a malfunction.Logical nodes are also included in IEC 61850-7-4, PTOC, PHIZ, PTTR, PTOV, etc.In recent years, IEC 61850-8-1 MMS protocol, instead of DNP3 and IEC 60870-5-101/104, has been largely applied to substation automation systems in which communication networks are based on the fixed local area networks that are far more secure than wide area networks.However, the growing demand for smart grid applications involving large scale connections of devices (IEDs) and dynamically changing network topology requires robotic and secured information to guarantee the stability of the power system integration.MMS-based SCSM (specific communication service mapping) is not originally designed to address the aforementioned issues.Therefore, a solution that supports the scalability and cybersecurity must be used in such an application.IEC 61850-80-3 proposed an XMPP as a solution [22].Table 2 gives a comparison of several other proposed middleware solutions and XMPP was chosen because it provides robust security using simple authentication and security layer for secure authentication and transport layer security for encryption [23].XMPP is an open XML (Extensible Markup Language) protocol specified by the Internet Engineering Task Force.With their domain in a wide area network, XMPP clients connect to the XMPP servers and exchange through the XMPP pieces of server data called "stanzas", via unique system identifiers called JabberIDs (or JID) and domain names.The format of a JabberID is "client_name@domain.com" where "client_name" is the client identifier and "domain.com" is the server identifier.Three types of XMPP messages are defined in the XMPP protocol: iq stanza, message stanza, and presence stanza.
The agent-to-server communication interval (ASCI) serves as an automated source code security measure mapped to the XMPP protocol and defined in IEC 61850-8-2 [24].XMPP communication is based on client-server architecture.As illustrated in Figure 4, IEC 61850 devices are hosted by XMPP clients.XMPP clients initiate a TCP/IP connection to the XMPP servers.A transport layer security (TLS) connection is negotiated once the TPC/IP connection is established.XMPP clients and servers exchange pieces of XMPP data called "stanzas", the most basic unit of communication in XMPP.A stanza is the smallest piece of XML data a client can send to a server (server sends to the client) in one package.A stanza is like a mail message, each stanza contains an attribute "from" (from="JID of the source of the message") and an attribute "to" (to="JID of the destination of the message").The three different message formats are: • <iq> (dedicated for request/response exchange-solicited service) • <message> (dedicated for push-exchange -unsolicited communication) • <presence> (dedicated for presence announcement) An IEC 61850 request is sent by the IEC 61850 client, hosted by XMPP client-1.The request is received by an IEC 61850 server, hosted by XMPP client-2.The MMS request is encapsulated in XER (XML encoding rules) message format and encoded.It is first received by the XMPP client-1.Then the current XER request is routed using its JID address to the XMPP client-2 via the XMPP server.Hosting the IEC 61850 server, the XMPP client-2 unwraps the XER message and converts it to the first IEC 61850 request and reroutes it to the IEC 61850 server.The IEC 61850 server answers the IEC 61850 response via its XMPP client-2.The response message is wrapped again in the XER message format and rerouted again the XMPP server by the XMPP client-2.Finally, the XER response is sent to the XMPP client-1 that initiated the communication via the XMPP server.The IEC61850 client, hosted by the XMPP client-1, unwraps the XER response and converts it to an IEC 61850 response before delivering it to the IEC 61850 client.The communication process is then finalized.

Page 7 of 23
exchange pieces of XMPP data called "stanzas", the most basic unit of communication in XMPP.A stanza is the smallest piece of XML data a client can send to a server (server sends to the client) in one package.A stanza is like a mail message, each stanza contains an attribute "from" (from="JID of the source of the message") and an attribute "to" (to="JID of the destination of the message").The three different message formats are:

XMPP Enforced Security with TLS and Peer Authentication
XMPP security features client concern and server communication.XMPP, as defined in RFC 6120 [25] and illustrated in Figure 5, considers the transport layer protection combining the transport layer Security protocol and XMPP peer authentication as integrated security measures [26].

XMPP Enforced Security with TLS and Peer Authentication
XMPP security features client concern and server communication.XMPP, as defined in RFC 6120 [25] and illustrated in Figure 5, considers the transport layer protection combining the transport layer Security protocol and XMPP peer authentication as integrated security measures [26].

Communication System Architecture
Photovoltaic site equipment is connected to gateways as shown in the system architecture (Figure 6).The downstream communication between the equipment and the gateway is established either by Modbus, DNP3 or OPC.Legacy protocols can be used as the gateway is technically accepting a large range of available protocols such as IEC 870, DNP3, Modbus, OPC, BACnet, SNMP, and IEC 61850.At gateway level, tags are imported from the template ICD file described previously.Following IEC 61850-7-4 and IEC 61850-7-420, logical devices are created for each type of existing equipment: solar panel (DPVA), PV module (DVPM), battery (ZBAT), inverter (ZINV), and power meter (MMTR), etc.The gateway internally forwards each SCADA (Supervision Control and Data Acquisition) tag (values, quality, and timestamp) to its IEC 61850-8-2 server driver.Protocol data is transported over the XMPP protocol through an XMPP server.

Communication System Architecture
Photovoltaic site equipment is connected to gateways as shown in the system architecture (Figure 6).The downstream communication between the equipment and the gateway is established either by Modbus, DNP3 or OPC.Legacy protocols can be used as the gateway is technically accepting a large range of available protocols such as IEC 870, DNP3, Modbus, OPC, BACnet, SNMP, and IEC 61850.

Communication System Architecture
Photovoltaic site equipment is connected to gateways as shown in the system architecture (Figure 6).The downstream communication between the equipment and the gateway is established either by Modbus, DNP3 or OPC.Legacy protocols can be used as the gateway is technically accepting a large range of available protocols such as IEC 870, DNP3, Modbus, OPC, BACnet, SNMP, and IEC 61850.At gateway level, tags are imported from the template ICD file described previously.Following IEC 61850-7-4 and IEC 61850-7-420, logical devices are created for each type of existing equipment: solar panel (DPVA), PV module (DVPM), battery (ZBAT), inverter (ZINV), and power meter (MMTR), etc.The gateway internally forwards each SCADA (Supervision Control and Data Acquisition) tag (values, quality, and timestamp) to its IEC 61850-8-2 server driver.Protocol data is transported over the XMPP protocol through an XMPP server.At gateway level, tags are imported from the template ICD file described previously.Following IEC 61850-7-4 and IEC 61850-7-420, logical devices are created for each type of existing equipment: solar panel (DPVA), PV module (DVPM), battery (ZBAT), inverter (ZINV), and power meter (MMTR), etc.The gateway internally forwards each SCADA (Supervision Control and Data Acquisition) tag (values, quality, and timestamp) to its IEC 61850-8-2 server driver.Protocol data is transported over the XMPP protocol through an XMPP server.

IED Capability Description Files for PV Model
The configuration of electrical substation devices is specified by IEC 61850 with the language and representation format of configuration description language (SCL).It features data representation of substation equipment and associated functions such as logical nodes, communication systems and capabilities.The complete data representation allows complete interoperability by exchange of the SCL files between different devices of a substation.The IED (Intelligent Electronic Device) capability description file of one DER is created with the help of an ICD (IED Capability Description) editor [27].One logical inverter is created for each type of equipment, as shown in Figure 7.

Page 9 of 23
The configuration of electrical substation devices is specified by IEC 61850 with the language and representation format of configuration description language (SCL).It features data representation of substation equipment and associated functions such as logical nodes, communication systems and capabilities.The complete data representation allows complete interoperability by exchange of the SCL files between different devices of a substation.The IED (Intelligent Electronic Device) capability description file of one DER is created with the help of an ICD (IED Capability Description) editor [27].One logical inverter is created for each type of equipment, as shown in Figure 7.The IED capability description file of one DER is created with the help of an ICD editor.One logical inverter is created for each type of equipment and the XML codes as shown in Table 3:  The IED capability description file of one DER is created with the help of an ICD editor.One logical inverter is created for each type of equipment and the XML codes as shown in Table 3.

Performance Evaluation
Performance evaluation takes mainly latency calculations, throughput and the number of packages into consideration.Latency is a statistical value, depending on the generation rate of the nodes sharing the network, of the topology, policy within the nodes and link capacities [28,29].The authors of Reference [15] introduced an experimental test environment based on a VPN over a 10 Mbps Ethernet link.According to the test results, the proposed protocol conversion mechanism (SPCM) outperformed the conventional protocol conversion mechanism.In general, the latency delay increased, and the throughput decreased when the package count grew.The delay was nearly 150 ms when the package count was 500.
However, in our study, a longer latency delay was expected because the network architecture was over a public wide area network not a VPN or local area network.This was more challenging because the network quality was uncertain, but it was a practical condition.Five scenarios based on the different locations of XMPP servers were tested.Wireless 4G/LTE and wired ADSL were provided for different scenarios.

Latency Calculation Method for Sequence of Event Protocol
The IEC 61850 protocol features a sequence of events, and the resulting data, quality and timestamp information to be faithfully transmitted from server to client.Therefore, latency calculations cannot be obtained from the difference between these two timestamps.The total latency is illustrated in Figure 8 with the following understanding of t: t1: time for Modbus to IEC 61850 conversion; t2: time for XER message and encoding; t3: time for network latency; t4: time for XMPP server processing; t5: time for network latency; t6: time for XMPP message and decoding; t7: time for IEC 61850 client data processing; t8: time to assign the time stamp when receiving the data; T: the total latency.The IED capability description file of one DER is created with the help of an ICD editor.One logical inverter is created for each type of equipment and the XML codes as shown in Table 3:  The IED capability description file of one DER is created with the help of an ICD editor.One logical inverter is created for each type of equipment and the XML codes as shown in Table 3: Logical Device "PVArray" Logical Device "WeatherStation"

Performance Evaluation
Performance evaluation takes mainly latency calculations, throughput and the number of packages into consideration.Latency is a statistical value, depending on the generation rate of the nodes sharing the network, of the topology, policy within the nodes and link capacities [28] [29].The authors of Reference [15] introduced an experimental test environment based on a VPN over a 10 Mbps Ethernet link.According to the test results, the proposed protocol conversion mechanism (SPCM) outperformed the conventional protocol conversion mechanism.In general, the latency delay increased, and the throughput decreased when the package count grew.The delay was nearly 150 ms when the package count was 500.
However, in our study, a longer latency delay was expected because the network architecture was over a public wide area network not a VPN or local area network.This was more challenging because the network quality was uncertain, but it was a practical condition.Five scenarios based on the different locations of XMPP servers were tested.Wireless 4G/LTE and wired ADSL were provided for different scenarios.Logical Device "PVArray" Logical Device "WeatherStation"

Performance Evaluation
Performance evaluation takes mainly latency calculations, throughput and the number of packages into consideration.Latency is a statistical value, depending on the generation rate of the nodes sharing the network, of the topology, policy within the nodes and link capacities [28] [29].The authors of Reference [15] introduced an experimental test environment based on a VPN over a 10 Mbps Ethernet link.According to the test results, the proposed protocol conversion mechanism (SPCM) outperformed the conventional protocol conversion mechanism.In general, the latency delay increased, and the throughput decreased when the package count grew.The delay was nearly 150 ms when the package count was 500.
However, in our study, a longer latency delay was expected because the network architecture was over a public wide area network not a VPN or local area network.This was more challenging because the network quality was uncertain, but it was a practical condition.Five scenarios based on the different locations of XMPP servers were tested.Wireless 4G/LTE and wired ADSL were provided for different scenarios.

Latency Calculation Method for Sequence of Event Protocol
The IEC 61850 protocol features a sequence of events, and the resulting data, quality and timestamp information to be faithfully transmitted from server to client.Therefore, latency calculations cannot be obtained from the difference between these two timestamps.The total latency is illustrated in Figure 8 with the following understanding of t: t1: time for Modbus to IEC 61850 conversion; t2: time for XER message and encoding; t3: time for network latency; t4: time for XMPP server processing; Logical Device "PVArray" Logical Device "WeatherStation"

Performance Evaluation
Performance evaluation takes mainly latency calculations, throughput and the number of packages into consideration.Latency is a statistical value, depending on the generation rate of the nodes sharing the network, of the topology, policy within the nodes and link capacities [28] [29].The authors of Reference [15] introduced an experimental test environment based on a VPN over a 10 Mbps Ethernet link.According to the test results, the proposed protocol conversion mechanism (SPCM) outperformed the conventional protocol conversion mechanism.In general, the latency delay increased, and the throughput decreased when the package count grew.The delay was nearly 150 ms when the package count was 500.
However, in our study, a longer latency delay was expected because the network architecture was over a public wide area network not a VPN or local area network.This was more challenging because the network quality was uncertain, but it was a practical condition.Five scenarios based on the different locations of XMPP servers were tested.Wireless 4G/LTE and wired ADSL were provided for different scenarios.

Latency Calculation Method for Sequence of Event Protocol
The IEC 61850 protocol features a sequence of events, and the resulting data, quality and Logical Device "WeatherStation" The latency calculation and results are shown in Table 4.In principle, the timestamp for the same tag between the IEC 61850 server and client must be the same as it is configured as a report with the dataset.Therefore, when the client receives a report with tags and timestamps, an internal link process will be activated to appoint the value of dataset to those internal tags with the associated computer timestamp.The total latency will be the difference between the timestamp of the internal tag and the timestamp of the IEC 61850 server.The results show the average latency delay of 500 tags with 10 time tests.

Page 11 of 23
t8: time to assign the time stamp when receiving the data; T: the total latency.The latency calculation and results are shown in Table 4.In principle, the timestamp for the same tag between the IEC 61850 server and client must be the same as it is configured as a report with the dataset.Therefore, when the client receives a report with tags and timestamps, an internal link process will be activated to appoint the value of dataset to those internal tags with the associated computer timestamp.The total latency will be the difference between the timestamp of the internal tag and the timestamp of the IEC 61850 server.The results show the average latency delay of 500 tags with 10 time tests.

Implementation, Evaluation and Test Results
This section provides the implementation, evaluation and test results of the system model described earlier.It includes the test environment, the software used during evaluation, the different test cases and the results.

Implementation, Evaluation and Test Results
This section provides the implementation, evaluation and test results of the system model described earlier.It includes the test environment, the software used during evaluation, the different test cases and the results.

Test Environment
In order to reproduce real conditions, the simplified architecture of a PV site communicating with its management was recreated.The field equipment was simulated by 500 Modbus tags that generated random values.These values were sent to the gateway by Modbus TCP and then forwarded to the control center by IEC 61850-8-2.Figure 9 shows the architecture of the test environment.The XMPP servers were in different locations (370 km and 2310 km away).

Page 12 of 23
In order to reproduce real conditions, the simplified architecture of a PV site communicating with its management was recreated.The field equipment was simulated by 500 Modbus tags that generated random values.These values were sent to the gateway by Modbus TCP and then forwarded to the control center by IEC 61850-8-2.Figure 9 shows the architecture of the test environment.The XMPP servers were in different locations (370 km and 2310 km away).

IEC 61850-8-2 XMPP Report Latency Calculation
The first test case generated 500 values from the Modbus slave (simulator) and transmitted these values through the Modbus protocol to the edge computing gateway where the IEC 61850-8-2 server application was running.Once the values were read by the Modbus master, they were copied on the IEC 61850 server tags, defined into a dataset and linked to a buffered report control block (BRCB).The report published events through the XMPP transport layer received by the IEC 61850-8-2 client application.Latency time was obtained by calculating the time differences between when the tag changed on the IEC 61850-8-2 server and when the same value was read by the IEC 61850-8-2 client.Figure 10 presents the test environment for the latency report test.The IEC 61850-8-2 server and client application used Elipse Power and the XMPP server hosted in the Cloud PC was OpenFire.

IEC 61850-8-2 XMPP Report Latency Calculation
The first test case generated 500 values from the Modbus slave (simulator) and transmitted these values through the Modbus protocol to the edge computing gateway where the IEC 61850-8-2 server application was running.Once the values were read by the Modbus master, they were copied on the IEC 61850 server tags, defined into a dataset and linked to a buffered report control block (BRCB).The report published events through the XMPP transport layer received by the IEC 61850-8-2 client application.Latency time was obtained by calculating the time differences between when the tag changed on the IEC 61850-8-2 server and when the same value was read by the IEC 61850-8-2 client.Figure 10 presents the test environment for the latency report test.The IEC 61850-8-2 server and client application used Elipse Power and the XMPP server hosted in the Cloud PC was OpenFire.

Page 12 of 23
In order to reproduce real conditions, the simplified architecture of a PV site communicating with its management was recreated.The field equipment was simulated by 500 Modbus tags that generated random values.These values were sent to the gateway by Modbus TCP and then forwarded to the control center by IEC 61850-8-2.Figure 9 shows the architecture of the test environment.The XMPP servers were in different locations (370 km and 2310 km away).

IEC 61850-8-2 XMPP Report Latency Calculation
The first test case generated 500 values from the Modbus slave (simulator) and transmitted these values through the Modbus protocol to the edge computing gateway where the IEC 61850-8-2 server application was running.Once the values were read by the Modbus master, they were copied on the IEC 61850 server tags, defined into a dataset and linked to a buffered report control block (BRCB).The report published events through the XMPP transport layer received by the IEC 61850-8-2 client application.Latency time was obtained by calculating the time differences between when the tag changed on the IEC 61850-8-2 server and when the same value was read by the IEC 61850-8-2 client.Figure 10 presents the test environment for the latency report test.The IEC 61850-8-2 server and client application used Elipse Power and the XMPP server hosted in the Cloud PC was OpenFire.

IEC 61850-8-2 XMPP Command Latency Calculation
The second test case sent a direct operate command (either command open or command close) from the IEC 61850-8-2 client that was received by the IEC 61850-8-2 server.Upon receipt of the command, the server driver replied by command feedback to the client.Latency time was obtained by calculating the time between the moment the command was sent by the IEC 61850-8-2 client to the server and the moment the client received the command feedback from the server.Figure 11 shows the test environment for the latency command test.

Page 13 of 23
by calculating the time between the moment the command was sent by the IEC 61850-8-2 client to the server and the moment the client received the command feedback from the server.Figure 11 shows the test environment for the latency command test.

Software
The DER was simulated by a Modbus slave simulator.Elipse Modbus simulation is a tool provided by Elipse Software to simulate up to 10 Modbus PLC (Programmable Language Controller) devices.Each simulated PLC device can randomly generate up to 255 tags.Therefore two devices could be created at two different ports (502, 503) to provide a total of 500 tags.The simulator was running on a test PC and acting as a Modbus slave (Figure 12).
The IEC 61850-8-2 gateway application ran on Elipse Power.Elipse Power is a software provided by Elipse Software.It features an advanced SCADA environment that combines gateway and HMI (human machine interface).It also supports the latest IEC 61850-8-2 server and client drivers.The application was used to build the edge computing gateway to receive the values of the 500 tags on the Modbus master driver and to convert the values to an IEC 61850-8-2 server driver (Figure 13).An HMI was built to calculate the latency time and show the results on screen.

Software
The DER was simulated by a Modbus slave simulator.Elipse Modbus simulation is a tool provided by Elipse Software to simulate up to 10 Modbus PLC (Programmable Language Controller) devices.Each simulated PLC device can randomly generate up to 255 tags.Therefore two devices could be created at two different ports (502, 503) to provide a total of 500 tags.The simulator was running on a test PC and acting as a Modbus slave (Figure 12).The IEC 61850-8-2 gateway application ran on Elipse Power.Elipse Power is a software provided by Elipse Software.It features an advanced SCADA environment that combines gateway and HMI (human machine interface).It also supports the latest IEC 61850-8-2 server and client drivers.The application was used to build the edge computing gateway to receive the values of the 500 tags on the Modbus master driver and to convert the values to an IEC 61850-8-2 server driver (Figure 13).An HMI was built to calculate the latency time and show the results on screen.The ICD file had one logical device 'LDInverter' and two logical nodes.In the report test, 500 tags were implemented as phase current measurements in the logical node 'MMXU1'.In the command test, a command for breaker was implemented in the logical node 'XCBR1' (Figure 14).The ICD file was edited with the INFOTECH ICD editor, a tool to open, edit and save ICD files.An IED capability description (ICD) file defined the complete capability of the intelligent electronic device.For our experiment, we first created and monitored a PV model of the DER.Due to the limited bandwidth of the 3G communication, we deliberately reduced the number of tags and logical devices.The DER unit is described in the ICD file.

Page 14 of 23
The ICD file had one logical device 'LDInverter' and two logical nodes.In the report test, 500 tags were implemented as phase current measurements in the logical node 'MMXU1'.In the command test, a command for breaker was implemented in the logical node 'XCBR1' (Figure 14).The ICD file was edited with the INFOTECH ICD editor, a tool to open, edit and save ICD files.An IED capability description (ICD) file defined the complete capability of the intelligent electronic device.For our experiment, we first created and monitored a PV model of the DER.Due to the limited bandwidth of the 3G communication, we deliberately reduced the number of tags and logical devices.The DER unit is described in the ICD file.

Page 14 of 23
The ICD file had one logical device 'LDInverter' and two logical nodes.In the report test, 500 tags were implemented as phase current measurements in the logical node 'MMXU1'.In the command test, a command for breaker was implemented in the logical node 'XCBR1' (Figure 14).The XMPP server was built with OpenFire, a real-time collaboration (RTC) server.The software is licensed under the Open Source Apache License.XMPP is a widely adopted open protocol for instant messaging also called Jabber.The details are described in Reference [30].The server driver used an account created on the XMPP server and only accepted connection to listed clients.The important parameter settings, such as XMPP server name, JID for publisher, JID for subscriber and group, are showed in Figure 15.

Page 15 of 23
The XMPP server was built with OpenFire, a real-time collaboration (RTC) server.The software is licensed under the Open Source Apache License.XMPP is a widely adopted open protocol for instant messaging also called Jabber.The details are described in Reference [30].

IEC 61850-8-2/XMPP Communication Drivers
Communication drivers were implemented in Elipse Power Studio by Elipse Software [31].The server driver used an account created on the XMPP server and only accepted connection to listed clients.The important parameter settings, such as XMPP server name, JID for publisher, JID for subscriber and group, are showed in Figure 15.The client driver also connected to the XMPP server using an individual Jabber ID.Due to license limitations, it establishes a connection to a maximum of 25 servers (Figure 16).They are listed in the settings with their respective XMPP JID (Figure 17).The client driver also connected to the XMPP server using an individual Jabber ID.Due to license limitations, it establishes a connection to a maximum of 25 servers (Figure 16).They are listed in the settings with their respective XMPP JID (Figure 17).

Page 15 of 23
The XMPP server was built with OpenFire, a real-time collaboration (RTC) server.The software is licensed under the Open Source Apache License.XMPP is a widely adopted open protocol for instant messaging also called Jabber.The details are described in Reference [30].

IEC 61850-8-2/XMPP Communication Drivers
Communication drivers were implemented in Elipse Power Studio by Elipse Software [31].The server driver used an account created on the XMPP server and only accepted connection to listed clients.The important parameter settings, such as XMPP server name, JID for publisher, JID for subscriber and group, are showed in Figure 15.The client driver also connected to the XMPP server using an individual Jabber ID.Due to license limitations, it establishes a connection to a maximum of 25 servers (Figure 16).They are listed in the settings with their respective XMPP JID (Figure 17).

Graphic User Interface
The application to calculate the latency was developed in Elipse Studio, advanced SCADA software provided by Elipse Software.The application was divided into two functions for each test: 'report' and 'command.'In each test, a 'start' button allowed the user to trigger a new test and calculate the latency time automatically.
When the latency report test started 500 tags were polled from the Modbus master driver and the read values were copied to the IEC 61850 server driver.These values were then published to the connected XMPP server and subscribed to by the IEC 61850 client driver.The operation was repeated 500 times and the latency average was updated each time.A progress bar and a counter showed the current test progress along with the XMPP presence status.
When the latency command test started the interface sent, alternatively, a command open or close from the IEC 61850 client driver to the IEC 61850 server driver, which responded to the command by a feedback code.When the feedback code was 5 (operation accepted), the latency was calculated.

IEC 61850-8-2 XMPP Latency Report Test Calculation
On the read event by the client driver, the values were copied to the internal tag.The timestamp was then created by the time the values were copied.This timestamp allowed the calculation of the latency (Figure 18).

Graphic User Interface
The application to calculate the latency was developed in Elipse Studio, advanced SCADA software provided by Elipse Software.The application was divided into two functions for each test: 'report' and 'command.'In each test, a 'start' button allowed the user to trigger a new test and calculate the latency time automatically.
When the latency report test started 500 tags were polled from the Modbus master driver and the read values were copied to the IEC 61850 server driver.These values were then published to the connected XMPP server and subscribed to by the IEC 61850 client driver.The operation was repeated 500 times and the latency average was updated each time.A progress bar and a counter showed the current test progress along with the XMPP presence status.
When the latency command test started the interface sent, alternatively, a command open or close from the IEC 61850 client driver to the IEC 61850 server driver, which responded to the command by a feedback code.When the feedback code was 5 (operation accepted), the latency was calculated.

IEC 61850-8-2 XMPP Latency Report Test Calculation
On the read event by the client driver, the values were copied to the internal tag.The timestamp was then created by the time the values were copied.This timestamp allowed the calculation of the latency (Figure 18).

Graphic User Interface
The application to calculate the latency was developed in Elipse Studio, advanced SCADA software provided by Elipse Software.The application was divided into two functions for each test: 'report' and 'command.'In each test, a 'start' button allowed the user to trigger a new test and calculate the latency time automatically.
When the latency report test started 500 tags were polled from the Modbus master driver and the read values were copied to the IEC 61850 server driver.These values were then published to the connected XMPP server and subscribed to by the IEC 61850 client driver.The operation was repeated 500 times and the latency average was updated each time.A progress bar and a counter showed the current test progress along with the XMPP presence status.
When the latency command test started the interface sent, alternatively, a command open or close from the IEC 61850 client driver to the IEC 61850 server driver, which responded to the command by a feedback code.When the feedback code was 5 (operation accepted), the latency was calculated.

IEC 61850-8-2 XMPP Latency Report Test Calculation
On the read event by the client driver, the values were copied to the internal tag.The timestamp was then created by the time the values were copied.This timestamp allowed the calculation of the latency (Figure 18).The same operation was executed in the latency command test (Figure 19).

IEC 61850-8-2 XMPP Latency Command Calculation
The same operation was executed in the latency command test (Figure 19).

Results
Only the latency of the first 10 tags is presented.The total average time was calculated based on the latency of the 500 tags.The first test was conducted based on a wired wide area network connection between the test PC and the Cloud PC. Figure 20 shows the results with a latency between 0.6 seconds and 1.1 seconds.The smallest latency was provided by XMPP Server 3 (ejabberd) located 20 km from the test PC.The longest latency was shown by Server 1, located closest to the test PC.This was because the hardware performance in Server 1 was much lower than the others.Server 3 (ejabberd) and Server 2 (OpenFire) were located in the same place; however, this indicates that ejabberd is outperforming OpenFire as an XMPP server host.

Results
Only the latency of the first 10 tags is presented.The total average time was calculated based on the latency of the 500 tags.The first test was conducted based on a wired wide area network connection between the test PC and the Cloud PC. Figure 20 shows the results with a latency between 0.6 seconds and 1.1 seconds.The smallest latency was provided by XMPP Server 3 (ejabberd) located 20 km from the test PC.The longest latency was shown by Server 1, located closest to the test PC.This was because the hardware performance in Server 1 was much lower than the others.Server 3 (ejabberd) and Server 2 (OpenFire) were located in the same place; however, this indicates that ejabberd is outperforming OpenFire as an XMPP server host.

IEC 61850-8-2 XMPP Latency Command Calculation
The same operation was executed in the latency command test (Figure 19).

Results
Only the latency of the first 10 tags is presented.The total average time was calculated based on the latency of the 500 tags.

IEC 61850-8-2 XMPP Latency Report with 4G/LTE over Wide Area Network
The second test was based on 4G/LTE cellular communication between the test PC and the Cloud PC. Results show a smaller latency time when cellular communication was between the test PC and the XMPP server.(Figure 21).Server 3 with the ejabberd XMPP server was still performed best.The latency command test was conducted over a wired wide area network between the test PC and the XMPP server.The results show a smaller latency time when cellular communication was used between the test PC and the XMPP server (Figure 22).The latency command test was conducted over a wired wide area network between the test PC and the XMPP server.The results show a smaller latency time when cellular communication was used between the test PC and the XMPP server (Figure 22).

IEC 61850-8-2 XMPP Latency Report with 4G/LTE over Wide Area Network
The second test was based on 4G/LTE cellular communication between the test PC and the Cloud PC. Results show a smaller latency time when cellular communication was between the test PC and the XMPP server.(Figure 21).Server 3 with the ejabberd XMPP server was still performed best.The latency command test was conducted over a wired wide area network between the test PC and the XMPP server.The results show a smaller latency time when cellular communication was used between the test PC and the XMPP server (Figure 22).In this test, the XMPP Server 5, located in Bangkok, was selected, and the Test PC was in Taiwan.Figure 23 shows the average latency with the number of tags.It was expected that the latency would increase when the number of tags rose.However, it is worth noting that the average latency was less than 0.3 seconds when the number of tags was lower than 100.This indicates a promising result, that in the practical application of DER the average latency would be less than 0.3 seconds because the DER device would send only a few important tags (signals), such as the control signals, to the control center in the Cloud.Most of the tasks in DER were performed by the edge computing gateway located in the field.Figure 24 shows the packets per minute with the number of tags.No significant difference could be seen when the number of tags changed.This information can give the plant operator a reference to calculate the cost of communication.
Page 19 of 23

IEC 61850-8-2 XMPP Performance Test Based on Number of Tags
In this test, the XMPP Server 5, located in Bangkok, was selected, and the Test PC was in Taiwan.Figure 23 shows the average latency with the number of tags.It was expected that the latency would increase when the number of tags rose.However, it is worth noting that the average latency was less than 0.3 seconds when the number of tags was lower than 100.This indicates a promising result, that in the practical application of DER the average latency would be less than 0.3 seconds because the DER device would send only a few important tags (signals), such as the control signals, to the control center in the Cloud.Most of the tasks in DER were performed by the edge computing gateway located in the field.Figure 24 shows the packets per minute with the number of tags.No significant difference could be seen when the number of tags changed.This information can give the plant operator a reference to calculate the cost of communication.

Results Compared with Standards
Network latency standards over wide area networks have been introduced to IEC 61850-5:2013 (Table 5).The average latency times observed during our tests match the latency class TL1000 [32].Wired and wireless networks have similar results.However, the type of XMPP server might be one of the key factors affecting performance.The latency delay from 0.1 s to 1.1 s indicates that the network over public internet is rather unstable.In this test, the XMPP Server 5, located in Bangkok, was selected, and the Test PC was in Taiwan.Figure 23 shows the average latency with the number of tags.It was expected that the latency would increase when the number of tags rose.However, it is worth noting that the average latency was less than 0.3 seconds when the number of tags was lower than 100.This indicates a promising result, that in the practical application of DER the average latency would be less than 0.3 seconds because the DER device would send only a few important tags (signals), such as the control signals, to the control center in the Cloud.Most of the tasks in DER were performed by the edge computing gateway located in the field.Figure 24 shows the packets per minute with the number of tags.No significant difference could be seen when the number of tags changed.This information can give the plant operator a reference to calculate the cost of communication.

Results Compared with Standards
Network latency standards over wide area networks have been introduced to IEC 61850-5:2013 (Table 5).The average latency times observed during our tests match the latency class TL1000 [32].Wired and wireless networks have similar results.However, the type of XMPP server might be one of the key factors affecting performance.The latency delay from 0.1 s to 1.1 s indicates that the network over public internet is rather unstable.

Results Compared with Standards
Network latency standards over wide area networks have been introduced to IEC 61850-5:2013 (Table 5).The average latency times observed during our tests match the latency class TL1000 [32].Wired and wireless networks have similar results.However, the type of XMPP server might be one of the key factors affecting performance.The latency delay from 0.1 s to 1.1 s indicates that the network over public internet is rather unstable.
There are many factors involved in deciding latency.It is too complicated to use any mathematical formula.Therefore, in this practical application, the latency was highly affected by the network architecture, network bandwidth, data package, interval of data transmission (sampling rate) and the configuration of devices [33].The authors of References [34][35][36][37][38] presented the performance and latency tests based on different architectures between substations, the tests showed promising results with Energies 2019, 12, 1442 20 of 23 only a few milliseconds of delay for peer to peer communication.However, such architecture might only be suitable for local area networks.THIS study was even more challenging and complicated in terms of the system architecture, network configuration and the end devices because the system architecture was based on a wide area network, and most of the end devices used 3G or 4G for communication.We used several test scenarios based on different architectures to try to simulate the various cases that fit for the practical applications.The results guarantee suitability for IEC 16850-5 latency class (TT1) applications (see Table 5).

Conclusions
In this paper, the authors presented a framework with several novel concepts to integrate DERs in the device level based on the IEC 61850 standard and IoT technologies.The proposed framework has been well tested in Taiwan and Thailand to prove the concept and feasibility of DER integration.This paper gives academics and industries a reference point and guidance for research and implementation.The major contributions of this paper and test results are as follows: (1) Modeling the topology of photovoltaic stations to the IEC 61850 information model based on the IEC 61850-7-4 and IEC 61850-7-420 at the gateway level ensures interoperability between DER and DER, DER and utility and DER and the energy service operator, such as a control center (SCADA System).The results show that this method can standardize the data models of all the equipment related to DER, and, in practice, can become a strong plug and play strong when adding new DER equipment.
(2) This novel concept and the development of IEC 61850-8-2 by mapping of ASCI services as SCSM to the new XMPP protocol with XML mapping and encryption authentication provides scalability and information security.Using IEC 61850 information models over XMPP protocols was first seen in this research.The results are promising because the proposed methodology of latency testing in this paper, based on different network scenarios, shows positive results, and the overall communication performance meets the IEC 61850-90-12 standards of wide area network engineering guidelines.It is worth knowing that the latency performance can be within three seconds if the number of tags per DER side is less than 100.The latency class can therefore be applied for TT2 in Table 5.
(3) However, according to the XMPP architecture illustrated in Figure 4, XMPP clients cannot communicate directly without the XMPP server and the current standard of IEC 61850-8-2 has not yet defined direct communication mechanisms among the XMPP clients.This is a limitation of XMPP architecture if fast communication, within 30 ms (see Table 5) is required for specific applications such as fast automatic interactions, tele-protection and differential protection.A hybrid communication architecture combining XMPP and a routable generic object oriented substation event (R-GOOSE) might be considered for further research to extend the application functions.
(4) This work enables the edge computing capability for data process and analytics in the DER side for time-critical missions.The edge computing gateway deals with the various protocols and converts them to IEC 61850-8-2 standards.The concept and detailed implementation are introduced here.However, this paper does not directly address the analysis of data; the authors consider this a future research topic.

Figure 1 .
Figure 1.DER-based generation of top four countries as of 2018.

Figure 1 .
Figure 1.DER-based generation of top four countries as of 2018.

Figure 2 .
Figure 2. Architecture of edge computing gateway.

Figure 2 .
Figure 2. Architecture of edge computing gateway.

Figure 3 .
Figure 3. Example of logical nodes (LN) associated with photovoltaic systems.

Figure 3 .
Figure 3. Example of logical nodes (LN) associated with photovoltaic systems.
• <iq> (dedicated for request/response exchange-solicited service) • <message> (dedicated for push-exchange -unsolicited communication) • <presence> (dedicated for presence announcement) An IEC 61850 request is sent by the IEC 61850 client, hosted by XMPP client-1.The request is received by an IEC 61850 server, hosted by XMPP client-2.The MMS request is encapsulated in XER (XML encoding rules) message format and encoded.It is first received by the XMPP client-1.Then the current XER request is routed using its JID address to the XMPP client-2 via the XMPP server.Hosting the IEC 61850 server, the XMPP client-2 unwraps the XER message and converts it to the first IEC 61850 request and reroutes it to the IEC 61850 server.The IEC 61850 server answers the IEC 61850 response via its XMPP client-2.The response message is wrapped again in the XER message format and rerouted again the XMPP server by the XMPP client-2.Finally, the XER response is sent to the XMPP client-1 that initiated the communication via the XMPP server.The IEC61850 client, hosted by the XMPP client-1, unwraps the XER response and converts it to an IEC 61850 response before delivering it to the IEC 61850 client.The communication process is then finalized.

Figure 7 .
Figure 7. Editing ICD file for a DER in 61850 ICD editor.

Figure 7 .
Figure 7. Editing ICD file for a DER in 61850 ICD editor.

Figure 7 .
Figure 7. Editing ICD file for a DER in 61850 ICD editor.

Figure 7 .
Figure 7. Editing ICD file for a DER in 61850 ICD editor.

Figure 9 .
Figure 9. Architecture of test environment.

Figure 10 .
Figure 10.Test environment for latency report test.

Figure 9 .
Figure 9. Architecture of test environment.

Figure 9 .
Figure 9. Architecture of test environment.

Figure 10 .
Figure 10.Test environment for latency report test.

Figure 10 .
Figure 10.Test environment for latency report test.

Figure 11 .
Figure 11.Test environment for latency command test.

Figure 11 .
Figure 11.Test environment for latency command test.

4. 3 . 1 .
IEC 61850-8-2 XMPP Latency Report Wired over Wide Area NetworkThe first test was conducted based on a wired wide area network connection between the test PC and the Cloud PC.Figure20shows the results with a latency between 0.6 seconds and 1.1 seconds.The smallest latency was provided by XMPP Server 3 (ejabberd) located 20 km from the test PC.The longest latency was shown by Server 1, located closest to the test PC.This was because the hardware performance in Server 1 was much lower than the others.Server 3 (ejabberd) and Server 2 (OpenFire) were located in the same place; however, this indicates that ejabberd is outperforming OpenFire as an XMPP server host.Latency (second) 20.Latency average of five different servers using ADSL communication; latency time in seconds on Y axis, test number on X axis.

4. 3 . 2 .
IEC 61850-8-2 XMPP Latency Report with 4G/LTE over Wide Area NetworkThe second test was based on 4G/LTE cellular communication between the test PC and the Cloud PC. Results show a smaller latency time when cellular communication was between the test PC and the XMPP server.(Figure21).Server 3 with the ejabberd XMPP server was still performed best.Page 18 of 23

Figure 20 .
Figure 20.Latency average of five different servers using ADSL communication; latency time in seconds on Y axis, test number on X axis.

Figure 21 .
Figure 21.Latency average of five different servers using 4G cellular communication; latency time in seconds on Y axis, test number on X axis.

Figure 22 .Figure 21 .
Figure 22.Latency test for command using ADSL communication; latency time in seconds on Y axis, test number on X axis.

Figure 20 .
Figure 20.Latency average of five different servers using ADSL communication; latency time in seconds on Y axis, test number on X axis.

Figure 21 .
Figure 21.Latency average of five different servers using 4G cellular communication; latency time in seconds on Y axis, test number on X axis.

Figure 22 .Figure 22 .
Figure 22.Latency test for command using ADSL communication; latency time in seconds on Y axis, test number on X axis.

Figure 23 .
Figure 23.Average latency vs. number of tags.

Figure 24 .
Figure 24.Packets per minute vs. number of tags.

Figure 23 .
Figure 23.Average latency vs. number of tags.

Figure 24 .
Figure 24.Packets per minute vs. number of tags.

Figure 24 .
Figure 24.Packets per minute vs. number of tags.

Table 1 .
Abbreviations for logical nodes.

Table 2 .
Comparison of different middleware solution characteristics.

Table 4 .
IEC 61850 sequence of event transport values, quality and timestamps of SCADA tags.

Table 4 .
IEC 61850 sequence of event transport values, quality and timestamps of SCADA tags.

Table 5 .
Latency classes for WANs (wide area networks).