International Electronical Committee (IEC) 61850 Mapping with Constrained Application Protocol (CoAP) in Smart Grids Based European Telecommunications Standard Institute Machine-to-Machine (M2M) Environment

Abstract

As power systems develop rapidly into smarter and more flexible configurations, so too must the communication technologies that support them. Machine-to-machine (M2M) communication in power systems enables information collection by combining sensors and communication protocols. In doing so, M2M technology supports communication between machines to improve power quality and protection coordination. When functioning in a “smart grid” environment, M2M has been labelled by the European Telecommunications Standard Institute (ETSI). International Electronical Committee (IEC) 61850 as the most important standard in power network systems. As evidence, this communication platform has been used for device data collection/control in substation automation systems and distribution automation systems. If the IEC 61850 information model were to be combined with a set of contemporary web protocols, the potential benefits would be enormous. Therefore, a constrained application protocol (CoAP) has been adopted to create an ETSI M2M communication architecture. CoAP is compared with other protocols (MQTT, SOAP) to demonstrate the validity of using it. This M2M communication technology is applied in an IEC61850, and use the OPNET Modeler 17.1 to demonstrate intercompatibility of CoAP Gateway. The proposed IEC 61850 and CoAP mapping scheme reduces the mapping time and improves throughput. CoAP is useful in the ETSI M2M environment where device capability is able to be limited.

1. Introduction

The smart grid is included in energy policies to improve power network reliability, stability, and efficiency. These developments aim to optimize energy efficiency by circulating bidirectional information on the generation and consumption of power. Thus, distributed power systems, distribution automation systems, and digital substation systems require power service technology refinements rather urgently, given that utilizing a smart grid involves extensive work to integrate state-of-the-art technology into current power systems. IEC 61850 is the most widely used standard in substation automation systems because it is necessary for integrating methods in a smart grid environment [1,2].

Recently, machine-to-machine (M2M) communication has been developed for a variety of services. The Internet of Things (IoT) is the resulting global interconnection of smart objects using extended Internet technologies [2]. Because power systems are built across geographically large areas, they need to be connected to such an Internet network using a smart grid. The ETSI TS 102 690 recommends M2M functional architecture, made possible by a web service [3].

Figure 1 shows a scenario in which the ETSI M2M standards are applied to a smart grid system deployment [4]. The control centers can be viewed as domains of a M2M core. The energy generation system, transmission system, and distribution system can be viewed as corresponding M2M device domains. The dotted red line represents the communication stream for the distribution automation system. Constrained application protocol (CoAP) is used to communicate with the upper layer (Control center) of the transmission system, distribution system and customer. IEC 61850 and Distributed Network Protocol 3.0 (DNP 3.0) have been used transmission system, distribution system and metering [5]. The CoAP-based M2M Gateway for DNP 3.0 was designed Shin et al. [6]. Mapping the IEC 61850 to RESTful Ref was achieved by Pederson et al. [7]. The CoAP-based M2M Gateway for the IEC 61850 requires improvements for use in substation system.

A CoAP is a message transfer protocol based on representational state transfer (REST). CoAP messaging relies on the exchange of messages over a user datagram protocol (UDP), between endpoints. More specifically, a CoAP is a specialized web transfer protocol for use with constrained nodes and restricted network. It has been standardized by CoRE, an Internet Engineering TaskForce (IETF) working group [8]. A CoAP can increase interoperability and simplicity, so combining the data model of the IEC 61850 with a set of contemporary web protocols can result in significant benefits.

We propose a CoAP mapping method for IEC 61850-based substation automation systems in a smart grid environment. In particular, our prototypical method utilizes a CoAP protocol as a M2M core protocol, wherein a CoAP-based gateway for a distribution automation system utilizes the IEC 61850 in a smart grid environment [7]. If a M2M device acts as an IEC 61850 server, power information packets will be passed through an M2M gateway. If a M2M device acts as a CoAP server, power information packets will be passed directly to a M2M core server. IEC 61850 uses Manufacturing Message Specification (MMS ISO/IEC 9506) as the transport layer. This mapping can be easily extended to IEC 61870 (ICCP: Inter Control Center Communication Protocol) using the same transport layer with a reduction in mapping time. Functional constraints (FCs) information are added to enhance interoperability with the IEC 61850 model. CoAP is compared with SOAP (Simple Object Access Protocol), and MQTT (Message Queue Telemetry Transport) to demonstrate the advantages of CoAP. OPNET Modeler 17.1 is used to demonstrate the intercompatibility between CoAP protocol and IEC 61850 in M2M communication. Since sensitive facilities require fast response time, the delay of the packet is calculated from the device to the system. The total packet delay is calculated to be 0.006 seconds. Given that the IEC 61850 has been expanded to cover the monitoring and control of distributed energy resources (DERs), a CoAP gateway can be useful in an aggregated group of DERs by providing a variety of electrical services using this method on small devices. The proposed mapping benefits from improved throughput and reduced latency.

This paper is organized as follows. Section 2 outlines the background of the IEC 61850 (IEEE 1815) and a CoAP based on REST. In Section 3 describes a prototypical CoAP-based M2M gateway for a distribution automation system using the IEC 61850 in a smart grid environment. Section 4 contains the results of the experimental analysis, and Section 5 concludes the paper and mentions planned future work.

2. Power IT Protocols

2.1. IEC 61850

The IEC 61850 is a communication standard for electrical substation automation systems. It is the standard protocol used in digital substation systems and smart distribution systems. The IEC 61850-3 provides common information lists for electrical substation automation systems. The data model for substation automation systems is defined in the IEC 61850-7. The IEC 61850 features include [10]:

-

Data Modeling: Primary process objects as well as protection and control functionality in the substation are modeled into different standard logical nodes, which can be grouped under different logical devices. There are logical nodes for data/functions related to the logical node zero (LLN0) and logical node for physical device (LPHD).

-

Reporting Schemes: There are various reporting schemes buffered report control block and unbuffered report control block (BRCB & URCB) for reporting data from the server through a server-client relationship, which can be triggered based on pre-defined trigger conditions.

-

Fast Transfer of events: Generic substation events (GSEs) facilitate fast transfer of event data within a peer-to-peer communication mode. These substation events are again subdivided into GOOSE and GSSE.

-

Setting Groups: The setting group control blocks (SGCBs) handle the setting groups so that the user can switch to any active group according to his or her requirements.

-

Sampled Data Transfer: Schemes are also defined to handle transfer of sampled values using sampled value control blocks (SVCBs).

-

Commands: Various command types are also supported by the IEC 61850. These include direct and select before operate (SBO) commands with normal and enhanced securities.

-

Data Storage: A substation configuration language (SCL) is defined for complete storage of a substation’s configured data in a specific format.

The IEC 61850 information model is shown in Figure 2. The information model is an abstract representation of the devices inside the substation. The logical devices (LDs) comprise a virtual representation of physical devices, such as relays or bays, in the substation. A LD includes many logical nodes (LNs). LNs are virtual representations of device components such as switches, circuit breakers, and voltage meters. A data object (DO) is a representation of the common information in various nodes. All devices follow a common naming scheme, so that devices from different manufacturers may be permitted to access the same device [9,10,11,12].

FCs play a crucial role in the definition and services through which to access various parts of information models. FCs are not shown in the object reference; however, the FC information may be mapped onto the object reference in a specific communication service mapping. IEC 61850-8-1 maps the FC between the logical node name and the data name (Relay1:MMXU1$CF$PhV). FCs are defined as follows: MX—measurements; ST—status; CF—configuration; RP—unbuffered report control blocks; LG—log control blocks; BR—buffered report control blocks; GO—Generic Oriented Object System Event (GOOSE) control blocks; GS—Generic Substation Status Event (GSSE) control blocks; SV—substituted values; and SE—setting group editing [13].

2.2. CoAP-Based on REST

REST is a software architecture consisting of a coordinated set of architectural constraints applied to components, connectors, and data elements within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in favor of focusing on the roles of components, constraints on interactions with other components, and interpretation of significant data elements [14,15].

The term “representational state transfer” was introduced and defined in Roy Fielding’s doctoral dissertation at UC Irvine [14]. The REST service is based on the concept of SOA, and it has evolved into a lightweight alternative to a SOAP service [8,15]. REST has been deployed to describe desired web architectures, identify existing problems, compare alternative solutions, and ensure that protocol extensions do not violate the core constraints which make the web successful. Fielding used REST to design HTTP 1.1 and uniform resource identifiers (URI). The REST architecture can also be applied to developing web services as an alternative to other distributed computing specifications, such as SOAP [16,17].

Based on REST, CoAP is a specialized web transmission protocol for use with constrained nodes and constrained networks. This message transfer protocol has characteristics that can be useful for small, low-cost devices. CoAP messaging is based on the exchange of messages over a UDP between endpoints. The message types are confirmable, non-confirmable, acknowledgment, and reset [8]. CoAP connects easily to HTTP because it follows the REST service and has the same status code as HTTP. Additionally, it includes a concise expression of all requisite information in its URI.

CoAP message format is shown in Figure 3. A CoAP message is encoded in a simple binary format, which includes a four-byte fixed header. It then comprises token length, code, message ID, token, option, and payload. The code includes message types and methods (GET, POST, PUT, DELETE), which can replace the services of the current system. The GET method retrieves a representation of information that corresponds to the resources identified by the request URI. The POST method requires that the enclosed representation to be created, processed, or changed in the request. The PUT method requests that the resource identified by the request-URI be updated. The DELETE method requests that the resource identified by the request URI is deleted. The token is represented by the URI information [8].

3. CoAP-Based M2M Gateway

3.1. CoAP Mapping Method for IEC 61850

Figure 4 shows the protocol flow between the M2M core server and M2M device using the IEC 61850 within the M2M environment. The M2M core server and CoAP-based M2M gateway map the IEC 61850 and CoAP. CoAP messages contain data from the IEC 61850 application layer information (LD, LN, FC, data object, and data attribute).

The protocol structure for application layer mapping between the IEC 61850 and CoAP is shown in Figure 5. The IEC 61850 and CoAP reference the OSI 7 layer communication standard. The IEC 61850 uses a TCP in the transport layer, as well as a manufacturing message specification (MMS) and abstract communication service interface (ACSI), in the application layer. MMS is an international standard (ISO 9506) that has been developed and maintained by the ISO TC184. ACSI defines common utility services for substation devices. However, CoAP uses UDP in the transport layer, and is based on CoAP in its application layer. Therefore, a CoAP cross-mapping layer is needed because the IEC 61850 and CoAP have different transmission and application layers. CoAP cross-mapping layer maps the FCs from the IEC 61850 data model and CoAP method, in addition to the IEC 61850 data model and CoAP URI. FC information makes it possible to access various parts of the information model.

MMS expresses object using basic encoding rules of ASN.1 (Abstract Syntax Notation One). ASN.1 is quite heavy for simple variable transport (24 bits for one Boolean value). On the other hand, CoAP expresses object using URI. CoAP needs 8 bits for one Boolean value.

A map of the IEC 61850 data and CoAP URI is shown in Figure 6. The IEC 61850 data model is composed of an object group, variation, and qualifier. These components simplify the task of creating a CoAP interface for the IEC 61850 data model. CoAP URI can be represented in the following order:

• coap://(CoAPServerAddr)/ACSIService/LogicalDevice/LogicalNode/FunctionalConstrint/
• DataObejct/DataAttribute

For example, the data attributes belonging to ACSI “GetDataValues”, LogicalDevice “General Device (GEDevice)”, LogicalNode “Circuit breaker (XCBR1)”, FunctionalConstrint “ST”, DataObejct “Pos”, and DataAttribute “stVal” can be read out using:

• coap://((CoAPServerAddr)/01/GEDevice/XCBR1/ST/Pos/stVal

A GET method is used for reading data. For writing data, however, the same URL would be used, but with a PUT method in place of the GET method. The response information only transmits reply data.

Table 1. FC Services of the IEC61850-to-CoAP Method Mapping.

Method	ACSI Service	ACSI Mapping Code
GET	GetDataValues	01
GET	GetAllDataValues	02
GET	GetDataList	03
GET	GetDataDefinition	04
GET	GetBRCBValues	05
GET	GetURCBValues	06
PUT	SetDataValues	10

shows the FC services of the IEC61850-to-CoAP method mapping [4,8,11]. The GET method is mapped to GetDataValues, GetAllDataValues, GetDataList, GetDataDefinition, GetBRCBValues, GetURCBValues ACSI service. These ACSI services request information from remote facilities. Buffered report control block (BRCB) comprises internal events (caused by trigger options data-change, quality-change, and data-update) and issues the immediate sending of reports or buffers the events (to some practical limit) for transmission. Unbuffered report control block (URCB) comprises internal events (caused by trigger options data-change, quality-change, and data-update) and issues the immediate sending of reports on a “best effort” basis. The BRCB and URCB are used in conjunction with the observation service of CoAP. The PUT method is then assigned to SetDataValues, which sends data to remote services. Since the GET method is mapped to two or more ACSI services, Codes are added to distinguish services.

3.2. CoAP-Based M2M Gateway Implementation

CoAP and IEC 61850 were implemented in the Ubuntu 10.4 Linux OS. CoAP library was generated with libcoap 4.1.1 (https://www.libcoap.net/doc/reference/4.1.1/index.html), which was developed in the IETF group, CORE. The IEC 61850 was implemented using Sisco’s MMS EASY Lite Source Code Library [10].

Table 2. Example of a SCL IEC 61850 Model to CoAP URI Source Code.

SCL (Substation Configuration Language) Example of IEC 61850 Model		CoAP URI Registration Example of Source Code
<FCDA   ldInst = “MEAS”   lnClass = “MMXU”   prefix = “SAG”   lnInst = “1”   doName = “PhV.phsA”   fc = “MX” />	1	register = coap_resource_init((unsigned char *) “01/MEAS/MMXU1/MX/Phv/phsA”, 22, 0);
	2	coap_register_handler(register,COAP_REQUEST_GET, hnd_get_service);

* Unsigned char.

shows an example of the substation configuration language (SCL) IEC 61850 model to CoAP URI source code. The IEC 68150 SCL is a descriptive language for the configuration of electrical substation IEDs. The SCL describes in detail the real IEC 61850 model of IEDs. The FCDA element defines the name of a functionally constrained datum or functionally constrained data attribute, according to the IEC 61850-7-2 of the IED to be contained in the dataset.

IdInst is an IEC 61850 logical device. InClass represents an IEC 61850 logical node. The function, doName, signifies a data object and data attribute. An example of this IEC 61850 model is represented by the IEC 61850 path “MEAS: MMXU1$MX$PhV$phsA”. This path is then converted into the following COAP URI: “01/MEAS/MMXU1/MX/Phv/phsA”.

The register instance defines the resources of CoAP server. CoAP_register_handler calls the hnd_get_service function. The hnd_get_service function then defines a CoAP for the IEC 61850 mapping process. Doing so enables only the CoAP GET method. CoAP_add_attr defines attributes of a CoAP resource.

CoAP-to-IEC 61850 mapping process within a CoAP cross-mapping layer is shown in Figure 7. CoAP_to_IEC 61850 stream receives and validates request messages from CoAP. If a request is determined to be invalid, the IEC 61850 should send an error message to the M2M core. If the request is deemed valid, the IEC 61850 should analyze the received message and extract CoAP and URI path information.

To do so, the IEC 61850 first maps CoAP to the IEC 61850 request type (refer to Table 1). Second, it maps the CoAP URI LD path to the IEC 61850 LD. Third, it maps the CoAP URI FC path to the IEC 61850 FC. Fourth, it assigns the CoAP URI LN path to the IEC 61850 LN. Fifth, it maps the CoAP URI DO path to the IEC 61850 DO. Sixth, it maps CoAP URI DA path to the IEC 61850 DA. Finally, it validates the IEC 61850 message and sends it to the IEC 61850 Server.

Figure 8 shows a sample message sequence chart between the IEC 61850 and CoAP. Here, CoAP client sends a CoAP message to the IEC 61850 slave via a CoAP-based M2M gateway in the following manner:

• CoAP Method: GET
• CoAP URI: 01/LD/XCBR1/ST/Pos/stVal

CoAP-based M2M then extracts the IEC 61850 request type, object, variation, and qualifier information by analyzing the received message. Subsequently, it maps the request type from the IEC 61850 data model and CoAP method. In addition, the M2M maps the IEC 61850 information and CoAP URI, and sends an IEC 61850 message to the IEC 61850 slave using the following parameters:

-

ACSI Service: GetDataValues

-

Logical Device: LD

-

Logical Node: XCBR1

-

Functional Constraint: ST

-

Data Object: Pos

-

Data Attribute: stVal

The IEC 61850 slave receives the message and replies with a message containing the response values for the CoAP-based M2M gateway. It then maps the CoAP method and request type of the IEC 61850 data model. In addition, it maps the CoAP URI and IEC 61850 information and responds to the CoAP client with a response message that contains the object group number, object index number, and object data.

4. Experimental Analysis

4.1. Performance Evaluation

CoAP compared with other protocol to demonstrate the advantages of CoAP. The comparison targets are SOAP and MQTT. SOAP is a protocol specification for exchanging structured information in the implementation of web services in computer networks. MQTT is an ISO standard (ISO/IEC PRF 20922) publish-subscribe-based “lightweight” messaging protocol for use on top of the TCP/IP protocol. The SOAP application was developed using gSOAP 2.8.16 (Genivia Inc.,Tallahassee, FL, USA). The CoAP application was developed using libcoap 4.1.1. The MQTT application was developed using MQTT v3.1 (OASIS, Minneapolis, MN, USA).

The protocols requested the same data for the same period, as shown in Figure 9. SOAP delivered an average 140 packets per second. MQTT delivered an average 80 packets per second. CoAP delivered an average 57 packets per second. CoAP is more efficient than SOAP or MQTT when transmitting the same data. There is also a difference in data sizes between the CoAP (average 67 bytes), the SOAP (average 400 bytes), and the MQTT (average 166 bytes). The CoAP data size is more than smaller than that of SOAP or MQTT when transmitting the same information. Thus, CoAP gateway was useful in the ETSI M2M environment because device capability was able to be limited.

4.2. OPNET Simulator

The CoAP gateway network performance diagnostic was described using the OPNET Modeler 17.1 running in an Ethernet environment (line model Ethernet 10BaseT). Here, packets arriving to the buffer follow a Poisson distribution. A node was created which operated as a buffer, specifically as an infinite queue, wherein the first to come was the first served (FIFO), a process also known as a M/M/1 queue. The area of performance tests were classified into IEC 61850 and CoAP. CoAP returned a result from interactions between a CoAP_client and a CoAP_gateway. The IEC 61850 returned a result from interactions between a CoAP_gateway and an IEC 61850_server. OPNET Simulator used the test parameters [ACSI: GetdataValues and SetdataValues, Logical Device: LD, Logical Node: XCBR1, Functional Constraint: ST, Data Object: Pos, Data Attribute: stVal]. Figure 10 shows the network topology in OPNET Modeler 17.1. This experiment was performed to demonstrate why CoAP is used as the external interface of the substation using the IEC 61850. The efficient compatibility of CoAP communication using the IEC 61850 model was also demonstrated.

Figure 11 shows the average traffic received (bytes/s) for CoAP and IEC 61850 applications. The IEC 61850 contained TCP information, MMS information, and IEC 61850 model information; whereas, CoAP contained a CoAP URI and UDP information. The IEC 61850 traffic received (approximately 12,000 bytes/s) was higher than CoAP traffic Received (approximately 4000 bytes/s). When a number of IEDs were connected to a M2M core server, it was more efficient to transfer information converted to a CoAP, since CoAP facilitated more efficient network traffic.

Figure 12 shows the packet network delay for CoAP and IEC 61850 applications. The packet network delay was negatively affected by the traffic. The IEC 61850 was based on the TCP transport protocol, which is a connection-oriented protocol. As such, it sent an additional ACK message. Doing so also had an impact on the network delay. Thus, the IEC 61850 packet network delay (approximately 0.0037 s) was higher than CoAP packet network delay (approximately 0.002 s). The total packet network delay was less than 0.006 s, on average.

The packet lengths of CoAP and IEC 61850 containing the same information is shown in

Table 3. Packet length.

Area	Packet Length (Min.–Max.)	Packet Length Average	Percent
CoAP	62–74	67	100%
IEC61850	40–79	68	0.56%
	80–129	114	99.44%

. The IEC 61850 information consisted of [ACSI Service: GetDataValues, Logical Device: LD, Logical Node: XCBR1, Functional Constraint: ST, Data Object: Pos, Data Attribute: stVal]. The IEC 61850 packet included the ACSI and MMS, among other information, including information that was unnecessary. The CoAP packet contained a method and URI. The CoAP packet length (approximately 67 bytes) was approximately half the size of the IEC 61850 packet length (approximately 114 bytes). IEC 61850 uses MMS as transport layer. It is a connection-oriented protocol. The information contained in the TCP header is more than the UDP header. MMS contains more information than CoAP URI because it uses ASN.1. The efficient compatibility of CoAP communication using the IEC 61850 model in OPNET Simulator was demonstrated.

5. Conclusions

The main goal of this paper was to demonstrate how a CoAP, based on REST services, could function in conjunction with data information from an IEC 61850 in a smart grid environment. A power network requires interoperability and the latest communications technologies, packaged into a simple format. CoAP is the most promising standard-based solution which could be applied to integrate heterogeneous M2M objects. CoAP-based M2M gateway was selected to perform this function. Thus, CoAP-based M2M gateway for a distribution automation system using the IEC 61850 in a smart grid environment was configured. Further, M2M core server and CoAP-based M2M gateway to enable a IEC 61850 to manage power IT systems in a M2M environment were implemented. Our results have shown that the object reference path of the IEC 61850 data could easily be mapped to the URI format in the resource-oriented approach used by CoAP. We were able to verify that conversion of the IEC 61850 information model to a CoAP URI could be achieved. To do so, a network performance diagnostic was performed a in which CoAP-based gateway, using an OPNET Modeler 17.1, was analyzed. The advantage of CoAP was demonstrated by comparing it with other protocols. This paper contributes to efforts toward identifying ICTs capable of satisfying the potential communication requirements of future power systems.