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

Abstract

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.

1. 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 mixes are expected to change tremendously. Solar PV and wind power are growing in 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 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.

2. Modeling PV Station to IEC 61850 Information Model

2.1. 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].

2.2. 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].

2.3. 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. Abbreviations for logical nodes.

Logical Node	Name	Logical Node	Name
XCBR	Circuit breaker	CSWI	Switch controller
XSWI	Circuit switch	PTOC	Time overcurrent
PHIZ	Ground detector	PTTR	Thermal overload
PTOV	Overvoltage	MMDC	DC (Direct Current) measurement
MMXU	Measurement	MMTR	Metering
ZRCT	Rectifier	ZINV	Inverter
DPVC	Photovoltaic array controller	DVPM	Photovoltaic module characteristics
DTRC	Tracking controller	DPVA	Photovoltaic array characteristics
DRCT	DER controller characteristics	STMP	Temperature measurements
RSYN	Synchronism-check	DRCS	DER controller status
DRCC	DER unit control actions	FSEQ	Sequencer
ZBAT	Battery systems	ZBTC	Battery charger
MMET	Meteorological conditions	MHET	Heat measured values Name

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:

• 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.
• Metering and measuring functions to acquire electrical measurements. AC (Alternating Current) measurements are included in the logical node MMXU while DC (Direct Current) measurements are included in the logical node MMDC. Logical nodes are defined in IEC 61850-7-4.
• DC to AC conversion functions to control and monitor inverters. Logical nodes are included in the specific IEC 61850-7-420 standard ZRCT, ZINV.
• 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].

2.4. IEC 61850-8-2 for Distributed Energy Resources

2.4.1. IEC 61850 Adapted to Smart Grid Communication

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. Comparison of different middleware solution characteristics.

Features\Protocols	XMPP	MQTT	AMQP	OPC UA	YAMI4	ZeroMQ
Cyber security	Very high	Medium	Medium	Very high	Very high	Medium
Scalability	Very high	High	High	Very high	Very low	High
Commercially driven	No	No	No	Yes	No	Yes
Message types supported	P-S, P-P	P-S, P-P	P-S, P-P	P-S, P-P	P-S, P-P	P-S, P-P
Development effort	High	Low	Low	High	Very low	Low
Recommended by standards	Yes	No	No	No	No	No
P–S: publish–subscribe message, P–P: push–pull message
XMPP: extensible messaging and presence protocol
MQTT: message queuing telemetry transport
AMQP: advanced message queuing protocol
OPC UA: OPC unified architecture
YAMI4: messaging solution for distributed systems
ZeroMQ: high-performance asynchronous messaging library

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].

2.4.2. IEC 61850-8-2: XMPP and IEC 61850 Encapsulation

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 “[email protected]” 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.

2.4.3. 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].

3. Photovoltaic Model for Performance Evaluation

3.1. 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.

3.2. 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.

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. Editing IED capability description files (ICD).

		Logical Device “Inverter”
		Logical Device “Battery”
		Logical Device “PVArray”
		Logical Device “WeatherStation”

.

3.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 latency calculation and results are shown in

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

	IEC 61850 Server		IEC 61850 Client		Internal Tag		Results (Sec)
	Value	Timestamp	Value	Timestamp	Value	Timestamp	Latency
#1	50275	15:59:54.171	50275	15:59:54.171	50275	15:59:55.097	0.873
#2	14366	15:59:54.171	14366	15:59:54.171	14366	15:59.55.097	0.866
#3	25607	15:59:54.171	25607	15:59:54.171	25607	15:59:55.098	0.870
#4	12381	15:59:54.171	12381	15:59:54.171	12381	15:59:55.098	0.858
#5	11101	15:59:54.171	11101	15:59:54.171	11101	15:59:55.098	0.858
#6	3796	15:59:56.231	3796	15:59:56.231	3796	15:59:57.014	0.863
#7	13200	16:00:01.211	13200	16:00:01.211	13200	16:00:02.464	0.866
#8	56938	15:59:56.231	56938	15:59:56.231	56938	15:59:57.014	0.860
#9	7553	15:59:54.171	7553	15:59:54.171	7553	15:59:55.099	0.853
#10	53648	15:59:54.171	53648	15:59:54.171	53648	15:59:55.099	0.853

. 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.

4. 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.

4.1. 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).

4.1.1. 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.

4.1.2. 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.

4.2. Implementation

4.2.1. List of XMPP Servers Used for Evaluation

The five different XMPP servers were tested at the following three locations:

• Server 1, located in Kaohsiung, XMPP server: OpenFire, Taiwan (Distance to server: 0 km);
• Server 2, located in Kaohsiung, XMPP server: OpenFire, Taiwan (Distance 20 km);
• Server 3, located in Kaohsiung, XMPP server: ejabberd, Taiwan (Distance 20 km);
• Server 4, located in Taipei, XMPP server: ejabberd, Taiwan (Distance to server: 370 km);
• Server 5, located in Bangkok, XMPP server: OpenFire, Thailand (Distance to server 2310 km).

4.2.2. 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 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.

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].

4.2.3. 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).

4.2.4. 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.

4.2.5. 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).

4.2.6. IEC 61850-8-2 XMPP Latency Command Calculation

The same operation was executed in the latency command test (Figure 19).

4.3. 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.

4.3.1. IEC 61850-8-2 XMPP Latency Report Wired over Wide Area Network

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.

4.3.2. 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.

4.3.3. IEC 61850-8-2 XMPP Latency Command Test over a Wired Wide Area Network

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).

4.3.4. 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.

4.4. Results Compared with Standards

Network latency standards over wide area networks have been introduced to IEC 61850-5:2013 (

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

WAN Latency Class	IEC 61850-5 Latency Class	Latency	Use
TL 1000	TT1	≤1000 ms	All other messages
TL 300	(TT2)	≤300 ms	Operator commands
TL 100	TT3	≤100 ms	Slow automatic interactions
TL 30	(TT4)	≤30 ms	Fast automatic interactions
TL 10	TT5	≤10 ms	Teleprotection
TL 3	TT6	≤3 ms	Differential protection

). 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 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).

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.