IEC 61850-80-5-Based Data Mapping for Communication Modeling of Smart Inverters with IEC 61850 and Modbus Integration

Abstract

In modern industrial systems, including power system automation, it is important to ensure that new standards are able to communicate with the older ones. IEC 61850 standard has been gaining significant ground in power system automation due to it is object-oriented design. In line with its exponential growth, it is imperative to integrate IEC 61850 with other information exchange approaches. Modbus is a very robust communication protocol that uses registers. Since it can be deployed in a cost-effective way, it is widely used in older or lower-cost devices. Unlike IEC 61850, which supports real-time communication, Modbus envisions a trigger-based communication style. All of these fundamental differences make direct communication between these two protocols nontrivial. In order to address this need, IEC TR 61850-80-5 is developed to give a structured approach for mapping Modbus data into the IEC 61850 data model. This is conducted using a gateway and includes identifying relevant Modbus registers, converting the data format and embedding them into IEC 61850 logical nodes and data attributes. If completed, this allows legacy devices such as meters or sensors running on Modbus to be seamlessly integrated into modern smart-grid systems using IEC 61850. This paper shows how such integration can be performed between smart inverters and the sensors feeding information to them. Firstly, both protocols are introduced. Then, the IEC 618150 modeling of smart inverters is presented. Finally, data mapping is performed between Modbus registers of current- and voltage sensors and the said smart inverter model. A gateway is developed based on this mapping as well. By bridging two widely used protocols, this work supports interoperability, extends the life of existing assets and ensures a smooth transition towards digital power systems.

1. Introduction

Power systems are revolutionized with digital technologies and edge devices. The envisioned smart-grid concept requires extensive communication between different devices. This makes it possible to monitor larger parts of the power networks, collect more data and optimize operation by processing the collected data and making informed decisions [1]. In parallel with deployment of new devices such as electric vehicles (EVs), distributed generators and smart inverters, there is more information exchange between heterogenous devices. With the integration of sensors, smart meters and other edge devices, the energy sector is on a path towards Internet of Things (IoT). Its successful implementation relies on standard communication protocols that support interoperability and scalability [2].

To address this need, the IEC 61850 standard has been developed. It provides object-oriented data modeling and allows for interoperable data exchange between different devices regardless of their vendor or model. Its technology agnostic structure lends itself to applications across different fields such as wired or wireless networks [3]. While the IEC 61850 standard was initially developed for substation automation, its versatility and modeling strength made it very popular. It has been extended to include different devices such as renewable energy resources (RES), EVs, smart inverters and solar home systems [4]. In addition to the data modeling, IEC 61850 provides three messaging services that can be used to meet various needs in power systems. Due to these advantages, IEC 61850 has become the de facto smart-grid communication standard [5].

An important part of smart-grid revolution is the integration of new technologies with the legacy systems that are unfeasible or cost-prohibitive to replace altogether. For a long time, Modbus has been dominant as a communication protocol in automation systems due to its reliability and simplicity [6]. This has been translated into a large footprint across a wide range of applications such as meters, controllers and smart inverters [7]. However, as the number of devices that communicate with each other and the amount of information that is exchanged increase exponentially, Modbus’s limitations started to appear. For a successful digital transformation, smart grids require standardized data models and real-time communication that can be performed in a much more plug-and-play fashion [8].

The widespread presence of Modbus-based devices creates a practical integration challenge in power systems. While replacing all of these devices is not possible for a myriad of reasons, there needs to be a solution that ensures these old devices can seamlessly communicate with newer devices that operate on IEC 61850. In order to meet this pressing need to bridge Modbus and IEC 61850 systems, IEC TR 61850-80-5 is developed [9]. It provides a structured guideline for mapping Modbus data into the IEC 61850 information model. In this fashion, existing Modbus devices can be represented as IEC 61850 compliant nodes, and seamless integration can be achieved.

This paper investigates the application of IEC TR 61850-80-5 for smart inverters. It presents the guidelines that are put forth in that document and develops a gateway that maps the Modbus data of an existing device, e.g., sensor, into corresponding IEC 61850 data attributes and logical nodes. A fully developed smart inverter control scenario is developed and presented to demonstrate how interoperability can be achieved without replacing legacy systems. This work not only explains Modbus and the IEC 61850 standard in the context of power networks but also elaborates on the challenges that are present in their integration. It studies the guidelines that are provided in IEC TR 61850-80-5 and shows how they can be utilized by developing a new Modbus-IEC61850 gateway. This work contributes to the current body of knowledge by showing how IEC TR 61850-80-5 guidelines can be interpreted and implemented for the successful integration of IEC61850 and Modbus communication protocols. The contributions of this paper can be listed as follows:

• Investigation of IEC TR 61850-80-5: This paper presents a thorough examination of the application of IEC TR 61850-80-5 specifically for smart inverters, offering insights into effective utilization of the guidelines therein.
• Development of a Modbus-IEC61850 Gateway: A novel gateway is developed that translates Modbus data from existing devices, such as sensors, into corresponding IEC 61850 data attributes and logical nodes, thereby facilitating seamless communication between protocols.
• Demonstration of Interoperability: A fully developed smart inverter control scenario is presented to showcase how interoperability can be achieved without necessitating the replacement of legacy systems, offering practical solutions for industry applications.
• Explanation of Standards: This research elucidates the Modbus and IEC 61850 standards within the context of power networks and elaborates on the challenges inherent to their integration, thereby enhancing comprehension within the field.
• Interpretation and Implementation of Guidelines: The study interprets the guidelines set forth in IEC TR 61850-80-5 and demonstrates their implementation, contributing significantly to the existing body of knowledge regarding the integration of IEC 61850 and Modbus communication protocols.

The rest of the paper is organized as follows: Section 2 gives an overview of Modbus and IEC 61850 protocols. Section 3 discusses how IEC 61850-80-5 achieves mapping between Modbus and IEC 61850. Section 4 presents a case study where a smart inverter using the IEC 61850 communication protocol and several measurement devices running on Modbus protocol are connected over a gateway. Finally, Section 5 draws the conclusions and provides future research directions.

2. Overview of Modbus and IEC 61850

A thorough understanding of operational modes and underlying structures of different protocols is required for any protocol integration effort. This helps clarify the ideas behind the design of each protocol and their characteristics [10]. This section gives an overview of Modbus TCP with a focus on the application layer and IEC 61850 Logical Node (LN) model. The approach to modeling and information exchange is very different as these protocols are initially developed for different purposes. These details and foundational elements are presented in the following subsections to lay the foundation for the data mapping presented later in the paper.

2.1. Modbus TCP

Modbus is initially developed in 1979 for industrial control purposes [11]. It is a protocol that is specifically designed to ensure communication between industrial control devices. The details of physical networking is not specified in the Modbus standard. Therefore, it can be deployed at different levels of physical networks [12].

Modbus TCP is a protocol widely used in field devices [13]. It envisions communication between a slave and master, in more up-to-date terminology a server and a client, over the TCP/IP network [14]. It is possible to use a route or gateway to Modbus serial end devices. Figure 1 shows Modbus Communication architecture that includes serial communication as well as TCP/IP communication. By means of serial-TCP/IP gateways, clients and servers can also be connected to TCP/IP communication architecture and communicate with other devices. The focus of this paper is to achieve a similar harmonization between devices that communicate using Modbus and IEC 61850 standards.

Irrespective of the communication layers utilized, Modbus protocol defines a Protocol Data Unit (PDU). When combined with headers and footers, an Application Data Unit (ADU) is generated, as shown in Figure 2. The Additional address field can be used to route the message while the Error check field can be used to ensure the integrity of the message after transmission. In Modbus TCP/IP ADU, no Error check field is used and MBAP Header is used instead of Additional address. When implemented for TCP/IP, ADU has as dedicated header which makes the Modbus request/response over TCP/IP, as show in Figure 3. Modbus Application Protocol (MBAP) header is explained in detail in

Table 1. MBAP header fields.

Fields	Length	Description	Client	Server
Transaction Identifier	2 bytes	Identification of the transaction	Initialized by the client	Copied from the request
Protocol Identifier	2 bytes	0 = Modbus protocol	Initialized by the client	Copied from the request
Length	2 bytes	Number of bytes that follow	Initialized by the client	Initialized by the server
Unit Identifier	1 byte	Identification of a slave	Initialized by the client	Copied from the request

. Function code is the field which defines the type of action to be performed and Data field contains the data.

A transaction identifier is used for transaction pairing. A protocol identifier is used for intra-system multiplexing where a value of 0 indicated Modbus protocol. Length is the number of bytes that follow including the unit identifier. The purpose of the unit identifier is to support routing within a system. It is commonly employed when accessing a Modbus+ device or a slave on a Modbus line via a gateway that bridges an Ethernet TCP/IP network and a Modbus interface. The Modbus client includes this field in its request, and the server is required to echo the exact value in its response.

Function codes are utilized by the client to indicate what kind of specific operation is requested from the server. A summary of function codes defined in Modbus Application Protocol [15] is given in Figure 4. They include data access and some diagnostic functions.

There are four data models in Modbus, as shown in

Table 2. Modbus data models.

Type	Reference Range	Data Type	Access
Coils	00001–09999	1-bit (Boolean)	Read/Write
Discrete Inputs	10001–19999	1-bit	Read-only
Input Registers	30001–39999	16-bit (analog)	Read-only
Holding Registers	40001–49999	16-bit (analog/digital)	Read/Write

. Discrete Input and Coils are single bit memory locations. The former is read-only while the latter can be read and written. Input and Holding Registers are 16-bit memory locations (word) where, again, the former is read-only while it is possible to write into the latter. Application examples can be as follows: Coils can be used to represent an instruction to a relay, i.e., close or open. Discrete input, on the other hand, can represent the status of the relay or an alarm signal. Similarly, Input registers can be utilized to hold values from sensors that are only read. Operational parameters or configuration details can be housed in holding registers. Each type has its own memory reference range.

Communication in Modbus is always triggered by a client by sending a request message, read or write, to the server. As shown in Figure 5, Modbus requires that all servers keep a listening socket on Port 502. When a client wants to establish a connection with a remote server, it opens a new client connection with a remote 502 port. Local port needs to be unique for each server and higher than 1024. Once a connection is established, the Modbus request can be sent over TCP to transfer data. Once the communications are over, the client has to initiate a connection closing to end the connection between the sockets.

Client design is very straightforward in Modbus; it sends requests and handle the responses. Upon receiving a new demand from a user application, the client encodes a request and sends it to the server. For example, if user application needs the client to read holding register 10 at a remote server 2, following Modbus TCP request will be generated.

Special attention needs to be paid to addressing the model used in Modbus. The reference ranges given in Table 2 are only logical addresses used for user convenience. A Modbus packet only includes the offset value starting from the first register. To elaborate, in

Table 3. A sample Modbus TCP request message.

Byte(s)	Meaning
00 01	Transaction ID (used for tracking)
00 00	Protocol ID (always 0 for Modbus TCP)
00 06	Length of remaining bytes including Unit ID (6 bytes)
02	Unit ID (Slave ID = 2)
03	Function code (read holding registers)
00 09	Start address = 9 (i.e., 40010)
00 01	Number of registers to read = 1

, Function Code is 03. This indicates that a read action on holding registers (40001–49999) is to be performed. Start Address is 0009, which means the tenth register (40010) is the target address. Number of registers to read shows how many consecutive registers are to be read. In this case, only holding register 10 read. It is also possible to read several registers at once.

The response message generated by server 2 is shown in

Table 4. Modbus TCP response message to request in Table 3.

Byte(s)	Meaning
00 01	Transaction ID (copied from the client request)
00 00	Protocol ID (copied from the client request)
00 05	Length of remaining bytes including Unit ID (5 bytes)
02	Unit ID (copied from the client request)
03	Function code (copied from the client request)
02	Byte Count (indicates how many bytes follow)
00 2F	Value of register 40010 (47 in decimal)

. Some fields such as Transaction ID, Protocol ID Unit ID and Function Code are copied from the request for matching. Byte Count shows how many bytes are appended to the message. The value of the registers that are read, in this example value 0x002F in memory location 40010, are included in the response message.

2.2. IEC 61850

IEC 61850 differs fundamentally from Modbus by providing a more comprehensive and semantically rich approach to data modeling and communication in electrical systems. It supports information exchange between Intelligent Electronics Devices (IEDs) with semantic clarity that is not dependent on the model or the vendor of the said device [16]. The communication services are separated from the abstract models, making it a very versatile foundational technology in modern substations and smart grids.

Modeling of a device is much more complicated in IEC 61850. It is based on two key modeling elements: Logical Devices (LDs) and Logical Nodes (LNs) [17]. LNs are modular blocks that are used to model a specific function such as measurement or control of a circuit breaker. Inside LNs are Data Objects (DO) and their corresponding Data Attributes (DA) which are standard and well-structured. In this fashion, any LN built with these sets is interoperable and legible to machines. A group of related LNs that are grouped together make up an LD. LDs are mostly physical devices or a meaningful part thereof such as protection relay or breaker control. The hierarchical modeling approach utilized in IEC 61850 is depicted in Figure 6.

An object-oriented model is developed through DAs and DOs that are placed inside LNs. DO represents a measured value or a status of a device while DA defines its detailed characteristics. A DO may be used to show a breaker’s position or a measured value while DA may hold details such as its value, quality and timestamp. The interoperability lies in the fact that these are written with predefined Common Data Classes (CDC) to ensure consistency in semantics and data format across devices. Functional constraints are also utilized to clarify how each data can be accessed. This detailed modeling makes it possible that every piece of data has a clear role, meaning and access method. Thanks to this clarity and well-structured model, devices from different vendors can exchange information seamlessly. Furthermore, the exchange information is more granular and detailed than traditional registered-based protocol. While Modbus may provide a voltage reading value in a holding register, IEC 61850 includes the quality and the timestamp of that particular reading.

Information exchange services are also more developed in IEC 61850 standard [18]. There are three message types: Manufacturing Message Specification (MMS), Generic Object-Oriented Substation Event (GOOSE) and Sampled Value (SV). MMS protocol employs a client server communication model. A client such as a central unit can gain access to or modify data in an IED that acts as a server. Through MMS messages, DOs modeled in LNs inside an IED can be accessed. Clients can read these values in real-time but also issue commands to change their values or ask for reports. While the messaging structure is similar to what is used in Modbus, the exchanged data is significantly different. As mentioned before, DOs in LNs hold semantically meaningful data which is standardized and is legible to different devices regardless of their type, model or vendor. GOOSE and SV protocols support a publisher–subscriber messaging model. An IED publishes periodic event-based or measurement messages, GOOSE in the former case and SV in the latter. Any interested client can subscribe to these messages and receive constant updates.

3. Mapping Information Between IEC 61850 and Modbus

IEC TR 61850-80-5 is a technical report aimed at providing a consistent and unified information exchange between IEC 61850 and Modbus, or IEC 61158-6 [19] as it is mentioned in the said technical report. Mapping rules for configuring a network using a gateway are developed by using gateways between these two protocols. The main objective of this document is to facilitate real-time data exchange among IEDs and subsystems, while automating the gateway configuration process to the greatest extent possible.

The document acknowledges that there are two gateway architectures that need to be considered. The first one is a gateway linking an IEC 61850-based server IED to a Modbus-based client IED, typically used when an IEC 61850 substation communicates with a control center operating over Modbus. The second one is a gateway connecting a Modbus server IED to an IEC 61850 client IED, used when a device that communicates via Modbus needs to interface with a substation using the IEC 61850 standard. The current version of IEC 61850-80-5 only focuses on the second option while it mentions that the first option might be studied in future versions.

Figure 7 shows the architecture of a gateway that is developed for this purpose. At the top, there is a substation or DERMS to operate in IEC 61850. At the bottom, there are different IEDs, such as smart inverters or relays, that operate on Modbus and need to communicate with the entity at the top. Gateway IED is inserted in between to enable this. As shown, the gateway IED acts as a Modbus client to a Modbus server and an IEC 61850 server/publisher to an IEC 61850 IED. The orange box in the middle represents the gateway functions that need to be performed so that the input received by the Modbus client can be successfully mapped on the IEC 61850 data structures and sent to IEC 61850 clients.

Figure 8 shows the architecture of a Modbus-IEC 61850 gateway as envisioned in IEC 61850-80-5. Services such as instructions sent to an IED for control model interaction are converted and directed by the gateway function. Similarly, when data model information, such as configurations or parameters, needs to be accessed in real-time, the gateway converts and forwards such requests to Modbus IED. IEC 61850-80-5 defines the mapping of data structures only and not the services. That is because there are different implementations of Modbus services in the field. Therefore, in this paper, the implementation example that follows only has data mapping demonstrations.

The workflow to engineer a Modbus to IEC 61850 gateway has several steps that can be grouped into two main tasks. The first one is to develop a semantically defined IEC 61850 data object model using the Modbus Configuration Tool (MCT). This will create a Modbus configuration description (.mcd) file for each device. Creating this .mcd file is not straightforward and requires meticulous effort, such as finding semantically matching IEC 61850 data objects for the Modbus information, identifying necessary data attributes of the CDC for the selected IEC 61850 information, and defining links between these attributes and the respective Modbus information as well as identifying required conversion functions for the successful conversion of Modbus information to IEC 61850 data attributes.

Once IEC 61850 data models of all Modbus devices are created, the second task is to configure the Modbus to IEC 61850 gateway using IED configuration description (.icd) file format. This task has two main steps that create the IEC 61850 server’s object model for Modbus devices and define the supported IEC 61850 communication services and parameters of the said server. All of these steps, and the final SCD file creation step, i.e., SCL engineering, are shown in Figure 9 [20].

A dedicated name space is created and needs to be referred into the SCL file as shown below.

<SCL xmlns=“http://www.iec.ch/61850/2003/SCL” xmlns:eIEC61850-80-5SCL=“http://www.iec.ch/61850/2020/SCL/80-5” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=“http://www.iec.ch/61850/2003/SCL SCL.xsd http://www.iec.ch/61850/2020/SCL/80-5 IEC61850-80-5.xsd” version=“2007” revision=“B” release=“4” eIEC61850-80-5:version=“2020” eIEC61850-80-5:revision=“A” eIEC61850-80-5:release=“4”>

Once this is completed, IEC 61850-80-5 Modbus extension needs to be added with type “eIEC61850-80-5” under dedicated private elements as

<Private type=“eIEC61850-80-5”> <eIEC61850-80-5:RegisterRef addr=“1021” type=“DiscreteInput”/> </Private>

Modbus mapping information has four components: RegisterRef indicates a mapping address, ConvFunctRef indicates transformation rules between IEC 61850 and Modbus data, Literal defines a literal value for use in conversion functions, and Configuration configures the handling of special cases when mapping data. Each Modbus address is modeled as a separate IED, and therefore, RegisterRef does not include the address of the Modbus server. Each Modbus address will be modeled as an individual IED. Several conversion functions might be utilized to convert data between IEC 61850 and Modbus representations.

<IED name=“TEMPLATE” manufacturer=“IEC” configVersion=“1.0” originalSclRelease=“4” originalSclRevision=“B” originalSclVersion=“2007”> <Private type=“eIEC61850-80-5”> <eIEC61850-80-5:Configuration   overflowValue=“true”/> </Private> </IED>

Once these steps are taken, Modbus devices, IP or Serial can be added as instances:

<SubNetwork type=“MODBUS-IP” name=“W1” desc=“”> <ConnectedAP iedName=“B1” apName=“AP1”> <Address> <P type=“IP” xsi:type=“eIEC61850-80-   5:tP_IPModbus”>192.168.0.1</P> <P type=“ADDRESS” xsi:type=“eIEC61850-80-   5:tP_ADDR”>1</P> <P type=“PORT” xsi:type=“eIEC61850-80-     5:tP_PORT”>502</P> </Address> </ConnectedAP> </SubNetwork>

These preliminary steps ensure that the devices are modeled according to IEC 61850 and they are added to the SCL configuration file. The final step is to perform a full mapping of the data objects.

Modbus to IEC 61850 Mapping Details

Modbus devices will be mapped onto only one root LD inside the gateway. The data of this device can be mapped onto several nested LDs. Consequently, multiple Modbus IEDs will be represented by multiple root LDs in the IEC 61850 server. Figure 10 shows how Modbus devices are mapped onto the gateway physical device “GTW” along with their relevant LNs. GTW_LD1 represents the information related to the gateway. LLN0 and LPHD LNs represent information about the gateway, such as its health.

Figure 10 shows how Modbus physical devices are mapped into the gateway as LDs. LD_MB1 models Modbus physical device “MB1”. The data provided by this device is mapped into different LNs inside LD_MB1. The data is represented as nested LNs inside the same LD while different devices, e.g., MB2, are mapped onto different LDs.

Figure 11 shows the contents of an LD that represents a physical Modbus device in an IEC 61850 gateway. There are different LNs and different DOs that are local or proxy. For devices that are modeled inside the gateway to model another device, LPHD.Proxy.stVal is set to true. The name of the non-IEC 61850 device is stored in LPHD.PhyNam.name, which is IED3 in this case. LPHD.PhyHealth.stVal is utilized to give information about the health of the device. This entry is required by IEC 61850. If this is not provided by the device, it is always set to ok. Similarly, all LNs have to have Mod, Beh and Health DOs inside. These are implemented as local objects in LNs.

The information that is provided by the Modbus device, for example a temperature reading and its rate of change, is embedded as a proxy object: LN_STMP.Tmp and LN_STMP_TmpRte. There can be additional DOs that may be required for the implementation. In this example, LN_STMP implements Alm and AlmSet DOs to trigger an alarm based on the temperature readings.

Mapping the Modbus read to the IEC 61850 data model is performed as shown in Figure 12. Here, it is important to ensure that the data, its type and its properties are compatible with the DO it is mapped onto in the IEC 61850 model. For instance, DI is a read-only, binary signal in Modbus. It is mapped on to Feeder_5.XCBR.Pos.stVal, a data attribute that is commonly used to hold the value of a switch’s status. CO is a discrete output that is read/write, which is in this case is read and saved in Feeder_5.XCBR.Pos.blkEna. IR is a read-only variable and can be mapped onto a data attribute similar to stVal. HR is a general-purpose register that is read/write. In this particular case, it is mapped to Feeder_5.XCBR.Pos.operTimeout. This is an integer value that specifies the timeout duration. In other words, it tells the control client how long it should wait before returning a timeout error.

Modbus write mapping can be performed as shown in Figure 13. ATCC.VolSpt.Oper.ctlVal.f represents voltage control setpoint operation for automatic tap changers. This has a float32 or real variable type and may require more than one HR in Modbus modeling.

It is important to note here that variable types may not be compatible for variables representing the same attribute in IEC 61850 and Modbus domains. For this reason, a comprehensive list of data conversion functions are given in IEC 61850-80-5, Section 7. For example, the ConverToInteger function converts a value to a signed integer while CombineRegisters combines registers into larger values.

4. Data Mapping Between IEC 61850 and Modbus Models of Smart Inverters

The mapping concept and its details are explained in this section with a case study. An Energy Management System (EMS) coordinates the operation of several smart inverters in a power network. In such scenarios, EMS may instruct smart inverters to provide a certain amount of real and reactive power. It may also poll for some information such as the local voltage measured at inverter terminals and the inverter status. All of this information exchange takes place over smart-grid communication solutions. As shown in Figure 14, this power network has smart inverters that operate on Modbus (green) and IEC 61850 (blue) protocols. Due to the variety and complexity of the date it handles, EMS also operates on IEC 61850. There is a Modbus to IEC 61850 gateway developed as per IEC 61850-90-5 located on the right bottom corner. It ensures mutual understanding between the EMS and smart inverter operating on Modbus.

Table 5. Modbus and IEC 61850 mapping of data for smart inverters.

	Instructions to the Smart Inverter
Function	Active Power Setpoint	Enable Reactive Power Control
Description	Set target power output in watts	Reactive power output status
Data Type (Modbus)	FLOAT32	BOOL
Modbus Register	40001 and 40002 (HR)	00001 (Coil)
IEC 61850 Modeling	ActPowSet.Oper.ctlVal.f	ReacCtrl.Enb.Oper.stVal
CDC Type	APC	SPS
	Messages Sent by the Smart Inverter
Function	Voltage Measurement	Inverter Status Report
Description	Actual measured voltage (e.g., VAC)	Binary status: ON/OFF
Data Type (Modbus)	FLOAT32	BOOL
Modbus Register	30001 and 30002 (IR)	10001 (DI)
IEC 61850 Modeling	MMCUU.PhV.phsA.mag.f	DGEN.Sta.stVal
CDC Type	MV	SPS

shows the data exchanges to and from the smart inverters. EMS sends two inputs to smart inverters, active power setpoint and an instruction to enable reactive power control. The former is a setpoint in kWs that EMS may assign to individual inverters. It is represented by FLOAT32 variable type in Modbus, and registers 40001 and 40002 are utilized to hold it [21]. In IEC 61850 modeling, the same data is held in ActPowSet.Oper.ctlVal.f with a data type of APC (controllable analog process value) [22].

The latter, on the other hand, is an enable signal which toggles the reactive power output on and off. This may be required to provide auxiliary support for the grid, a hallmark of smart inverters. It is a Boolean data and held in a 00001 coil in Modbus domain. It is held in ReacCtrl.Enb.Oper.stVal with a data type of SPS (single point status).

Similarly, two outputs from smart inverters are also listed. The first one is the local voltage measurement at the inverter terminals while the second one is a binary variable that reports the status of the inverter as on or off. The former is a FLOAT32 type of data held in 30001 and 30002 registers in the Modbus domain while it is held in MMCUU.PhV.phsA.mag.f with a data type of MV (measured value). The latter is a Boolean data type held in the 10001 register for Modbus, whereas in IEC 61850 world, it can be located in DGEN.Sta.stVal as an SPS (single point status) data.

These inputs and outputs are modeled for both Modbus and IEC 61850 domains. For instance, if EMS wants to send an active power setpoint of 300 kW to a smart inverter in the Modbus domain, this will be performed by writing this value into the register 40001 in the smart inverter model. This will require the following steps:

1.

Convert decimal 300 to 32 float hexadecimal, using IEEE 754 representation is standard practice [23]:

300 = 0x43960000

2.

Write the high word (0x4396) in low word (0x0000) in Modbus holding registers 40001 and 40002, respectively.

3.

Send the relevant Modbus message as below, detailed explanation of the messages is given in Table 6.

00 01 00 00 00 0B 01 10 00 00 00 02 04 43 96 00 00

Table 6. Modbus message for active power setpoint = 300 kW.

Field	Hex Bytes	Description/Notes
Transaction ID	00 01	Unique ID for this request
Protocol ID	00 00	Always zero for Modbus TCP
Length	00 0B	Number of bytes after (Unit ID + PDU), 11 bytes
Unit ID	01	Modbus slave address (target device ID)
Function Code	10	Write Multiple Registers command (0x10)
Starting Address	00 00	Starting register address (40001 is 0x0000)
Quantity of Regs	00 02	Number of registers to write (2 registers for FLOAT32)
Byte Count	04	Number of data bytes to follow (2 registers × 2 bytes)
Register Values	43 96 00 00	FLOAT32 value 300.0 split into two 16-bit registers

Table 6. Modbus message for active power setpoint = 300 kW.

Field	Hex Bytes	Description/Notes
Transaction ID	00 01	Unique ID for this request
Protocol ID	00 00	Always zero for Modbus TCP
Length	00 0B	Number of bytes after (Unit ID + PDU), 11 bytes
Unit ID	01	Modbus slave address (target device ID)
Function Code	10	Write Multiple Registers command (0x10)
Starting Address	00 00	Starting register address (40001 is 0x0000)
Quantity of Regs	00 02	Number of registers to write (2 registers for FLOAT32)
Byte Count	04	Number of data bytes to follow (2 registers × 2 bytes)
Register Values	43 96 00 00	FLOAT32 value 300.0 split into two 16-bit registers

On the other hand, if the same command is sent to a smart inverter in the IEC 61850 domain, it will be performed via an MMS message to reach the DO given in Table 5 and write a float32 value of 300. Assuming that the LD is named SI1 and LN is DERC1, the data access will be as follows:

EMS -> (write) -> SI1/DERC1.ActPowSet.Oper.ctlVal.f

The ease of modeling and semantic superiority of IEC 61850 become apparent with this example. The desired data can be inputted into relevant variables in a logical object reference instead of generic registers. Following up from Table 5, reverse communication will be required to, say, report local voltage levels to the EMS. For a smart inverter operating on Modbus, this will be performed by requesting this information by accessing the relevant register:

1.

Send a read command for register 30001: Detailed explanation of each field is given in Table 7.

Table 7. Modbus read message for inverter voltage (request).

Field	Bytes	Description
Transaction ID	00 05	Unique per request
Protocol ID	00 00	Always zero
Length	00 06	6 bytes to follow (Unit ID + PDU)
Unit ID	01	Slave address
Function Code	04	Read Input Registers
Starting Address	00 00	Register 30001 (zero-based)
Quantity	00 02	Read 2 registers (FLOAT32)

Table 7. Modbus read message for inverter voltage (request).

Field	Bytes	Description
Transaction ID	00 05	Unique per request
Protocol ID	00 00	Always zero
Length	00 06	6 bytes to follow (Unit ID + PDU)
Unit ID	01	Slave address
Function Code	04	Read Input Registers
Starting Address	00 00	Register 30001 (zero-based)
Quantity	00 02	Read 2 registers (FLOAT32)

2.

Receive Inverter Response: Detailed explanation of each field is given in Table 8.

00 05 00 00 00 07 01 04 04 43 66 00 00

Table 8. Modbus read message for inverter voltage (response).

Field	Bytes	Description
Transaction ID	00 01	Same as request
Protocol ID	00 00	Modbus TCP
Length	00 07	7 bytes after this field
Unit ID	01	Inverter ID
Function Code	04	Read Input Registers
Byte Count	04	4 bytes (2 × 16-bit registers)
Register Data	43 66 00 00	FLOAT32 representation of 230.0 V

Table 8. Modbus read message for inverter voltage (response).

Field	Bytes	Description
Transaction ID	00 01	Same as request
Protocol ID	00 00	Modbus TCP
Length	00 07	7 bytes after this field
Unit ID	01	Inverter ID
Function Code	04	Read Input Registers
Byte Count	04	4 bytes (2 × 16-bit registers)
Register Data	43 66 00 00	FLOAT32 representation of 230.0 V

3.

Convert 32 float hexadecimal 0x43660000 to decimal 230.0 volts

On the other hand, this process is much more streamlined and semantically comprehensible in IEC 61850 domain. Assuming LN is named MMXU1, to read this information EMS simply sends a read request with an MMS message to the following DO:

EMS -> (read) -> SI1/MMXU1.ActPowSet.Oper.ctlVal.f

It is also possible to transmit similar information via Sampled Value (SV) messages, a service dedicated to transmitting high-resolution samples in IEC 61850. In this case, the smart inverter would act as a host and constantly publish these measurements, and EMS will subscribe to these messages and receive constant updates. The IEC 61850-80-5 document only focuses on data mapping, and service mapping is left out of its scope.

Modbus-to-IEC61850 Gateway Design

For the variables and messages discussed in the example above, EMS can successfully communicate with smart inverters in the IEC 61850 domain (blue components in Figure 14). Since EMS cannot directly communicate with the smart inverters in the Modbus domain, a gateway is required to act as an interpreter. It receives IEC 61850 requests from the EMS, converts them to Modbus messages and contacts relevant smart inverters. Responses that are received from Modbus smart inverters are held in proxy models housed in the gateway.

The modeling of the gateway in this example is given in Figure 15. Gateway1 LD represents the gateway device and holds information related to it. This is a physical device modeling and not a proxy one, hence the yellow shading which is consistent with Figure 10. Below this LN, there are proxy modeling entries for the smart inverter in the Modbus domain. Proxy.stVal is set as True to indicate that this modeling is a logical modeling to map Modbus smart inverter to IEC 61850 domain. The first LD hosts DERC LN, which is required to have access to the ActPowSet.Oper.ctlVal.f variable. According to IEC 61850-80-5 guidelines, one Modbus device is mapped onto one root LD and its data can be mapped onto nested LDs. As shown, the second variable needed for EMS operation, i.e., MMXU.PhV.phsA.mag.f, is mapped onto a nested LD Smartinverter21. In this fashion, the gateway acts as the IEC 61850 interpreter between the EMS and the Modbus smart inverter.

With this gateway, the communication between the EMS and Modbus smart inverter becomes a combination of what is presented in the previous subsection. When EMS wants to set the active power setting of the Modbus smart inverter to 300 kW, the following steps are taken:

1.

EMS sends a write MMS message to SmartInverter2 LD hosted in the gateway

EMS -> (write) -> SmartInverter2/DERC1.ActPowSet.Oper.ctlVal.f

2.

Gateway detects that active power setpoint is updated for SmartInverter 2 LD. It triggers necessary steps to update this in Modbus domain.

2.1.

Firstly, the gateway converts the data to Modbus-compliant format. In this case, decimal to float32.

300 = 0x43960000

2.2.

Sends the relevant Modbus message as below, detailed explanation of the messages is given in Table 6.

00 01 00 00 00 0B 01 10 00 00 00 02 04 43 96 00 00

This ensures that the EMS talks to the gateway in the IEC 61850 domain; after receiving the message and its contents, the gateway talks to the Modbus smart inverter in the Modbus domain. The same approach can be assumed for the measurement data sent by the Modbus smart inverter. In this case, the process will be as follows:

1.

Send a read command for register 30001: Detailed explanation of each field is given in Table 7.

00 05 00 00 00 06 01 04 00 00 00 02

2.

Receive Inverter Response: Detailed explanation of each field is given in Table 7.

3.

If MMS messaging is activated, the received data can be transmitted in MMS read response message as follows:

EMS -> (read) -> SmartInverter2/MMXU1.ActPowSet.Oper.ctlVal.f

Alternatively, if SV messaging is enable, the gateway generates SV messages with the measured voltage, e.g., with TVTR.instMag.i DO. The EMS subscribes to this SV stream and receives constant updates.

5. Conclusions

The IEC 61850 standard is rapidly growing thanks to its versatile and semantically meaningful data modeling. While it is very likely that new smart-grid implementations and devices will be modeled in the IEC 61850 domain, there are legacy systems that run on different standards. Modbus has been very popular in the industry due to its straightforward and simple implementation. For successful integration of these two applications, it is important to have a standard mapping. IEC 61850-80-5 TR is aimed at filling this gap. It is developed to provide a data mapping solution so that clients such as EMS or SCADA systems running in IEC 61850 domain can exchange information with devices running in Modbus domain, such as smart inverter.

IEC 61850-80-5 is a set of guidelines that need to be fully understood and interpreted before being implemented in a real-life scenario. This paper fills this very important knowledge gap by providing a case study. An EMS that runs in IEC 61850 domain controls two smart inverters that run in IEC 61850 and Modbus domains each. The differences in these modeling approaches and how they affect the messages used for data exchange are discussed. Then, the guidelines provided by IEC 61850-80-5 are explained. In the case study, a Modbus-IEC61850 gateway is fully developed. Its contents, e.g., LDs and LNs, are discussed in detail. Finally, the message exchange scheme including this gateway is discussed to show the intricacies of IEC 61850-80-5 implementation in a smart-grid context.

Researchers and industry professionals active in smart-grid communication can benefit from this work towards better understanding IEC 61850 and Modbus communication protocols, how they differ from each other and the steps required to design and develop a gateway that ensures integration between them. Future work may focus on hardware implementation and validation of the developed gateway model. Another work item can be full-mapping details of services such as GOOSE or SV, which are not discussed in IEC 61850-80-5.