International Journal of Advanced Research in Electrical, Electronics and Instrumentation Engineering
MenuISSN ONLINE(2278-8875) PRINT (2320-3765)
ISSN ONLINE(2278-8875) PRINT (2320-3765)
| Mini S. Thomas, Senior Member, IEEE, Ikbal Ali, Senior Member, IEEE and Nitin Gupta Department of Electrical Engineering, Jamia Millia Islamia, New Delhi, India |
| Related article at Pubmed, Scholar Google |
Visit for more related articles at International Journal of Advanced Research in Electrical, Electronics and Instrumentation Engineering
Substations are opting IEC 61850 (International Electrotechnical Commission) interoperable protocol as the protocol helps in resolving most of the challenges related to IED (Intelligent Electronic Device) integration for providing an interoperable communication at bay level. However, it is still challenging for client applications to acquire data from IEC 61850 compliant IEDs and do further processing. The aim of this paper is to demonstrate how an IEC 61850 source code application running at station level can be configured to acquire data from the IEDs installed at bay level. The paper also describes the role of Manufacturing Message Specification (MMS) in establishing a communication between the client and the server (IED).
Keywords |
| IEC 61850, IED, Interoperability, MMS, Substation Automation |
INTRODUCTION |
| Due to the advancements in communication technology and interoperable protocols, legacy substations are moving towards automated substation to meet the objectives of smart grid [1, 2]. To provide better customer services, substations are encompassing plurality of product/engineering solutions to incorporate latest devices as per their needs. As a result, substations are equipped with multi-vendor devices and face the problem of interoperability [3-5] and to overcome this problem, IEC 61850 compliant devices/IEDs have been developed, as IEC 61850 protocol provides interoperable data structure and communication services for the devices integrated at the bay level [6]. IEC 61850 provides an innovative mechanism that leverages communication and networking technologies to provide better performance with lesser commissioning costs. |
| A five level architecture, as shown in Fig. 1, of substation automation is presented in [7] where the first level belongs to the devices installed in the field such as circuit breakers and current/voltage transformers. Second level depicts the installation of IEDs for receiving/sending data and other information from/to the field devices. For providing operational/non-operational data and other information to the higher levels, the third level focuses on the integration task of IEDs to support reliable, fast and two way communications. Fourth level comprises of various substation automation application functions whose purpose is to monitor and control the IEDs/field devices, process the data in a consumable form, and push/pull the non-operational data to/from fifth level supporting data warehouse applications. |
| Research has been ongoing for achieving the compatibility and interoperability of IEDs at the third level to build a robust substation automation system. [2,7-9] Using client applications, accessing data from these integrated multivendor IEDs is also equally important and is a need of higher levels for further processing [7]. |
| This paper explores the IEC 61850 source code for accessing the data from IED using MMS protocol. The paper is organized as follows. Section II describes the importance of IEC 61850 and its communication stack used in substation automation. Section III demonstrates the usage of various tools used in laboratory test setup for client/IED communication. Section IV describes the steps required for establishing the communication between a client program and the IED for reading the IED parameters. Conclusion is given in section V. |
 |
IEC 61850 IN SUBSTATION AUTOMATION |
| Substation automation performs various operations like protection, monitoring, and control and each of these operations are well supported by IEC 61850 IEDs. All of these operation functionalities inside the IEDs are represented by logical nodes (LNs) that help in exchanging data with external world. Based on the functional characteristics, all the logical nodes of IEC 61850 IEDs have been classified into 13 groups [10] as shown in table 1. Therefore, the table 1 helps in knowing the functional characteristics of a logical node e.g. XCBR represents the circuit breaker wherein “X” indicates that XCBR belongs to the switch gear group. |
 |
| Fig. 2 shows a communication stack of IEC 61850 along with an OSI model. The communication stack supports three modes of communication called Generic Object Oriented Substation Event (GOOSE), Sampled Values, and MMS for exchanging data between a client and server device in substation automation. Using IEC 61850 protocol, the devices/IEDs can exchange the information in the following ways [11]: |
| 1) Publisher/Subscriber scheme is used in GOOSE communication and more particularly for those applications which are time critical. For providing a real-time communication, GOOSE is a connection-less protocol to deliver the time critical information because the messages are sent directly to the Ethernet layer of the communication stack. GOOSE messages are used to trip the relays in real-time in response to a generated fault. |
| 2) Communication mode of Sampled values (SVs) is similar to GOOSE in a way that SVs are sent directly on Ethernet layer i.e. bypass the middle layers of the stack for time critical operations. SVs are based on IEEE 802.3 supporting virtual LAN (VLAN) tagging for prioritizing the messages to be sent on Ethernet layer. |
| 3) Client/Server scheme is used in MMS for non-time critical applications and is a connection-oriented protocol where messages travels through several layers of communication stack like ASN.1→Session →TCP →IP →Ethernet. With Client/Server scheme, a first device can perform read/write operations with a second device only after establishing a connection with the second device. Therefore, connection oriented nature of MMS provides an acknowledgement receipt of successful or failure communication to make data exchange more reliable. |
 |
| In the communication stack, here in this paper, we are focusing on MMS layer which is used for establishing the communication between server devices (IED) and a client application (source code). |
| A. MMS |
| Manufacturing Message Specification (MMS) is an international application-layer protocol for exchanging or transferring information among real devices like IED’s and the computer applications like SCADA. MMS was invented in 1990s for manufacturing and industrial processes developed and maintained by International Standards Organization (ISO) Technical Committee Number 184 (TC184) as a part of ISO 9506 [12]. Virtual Manufacturing Device (VMD) model is the main attraction of MMS because it helps in specifying how multi-vendor physical devices (IEDs) shall operate when the data is received by them to make the communication vendor independent. The VMD specifies the following three things [11]: |
| • Objects aka variables defined in the IED server whose value need to be extracted/manipulated by a client application, |
| • A set of services like read/write etc. that the client application can use to access/control these variable, and |
| • Response/behavior of the IED upon receiving the client’s request for reading/manipulating the variables defined in the IED. The response may include application errors when the IED is unable to execute the client’s request and sends a negative response. |
| The VMD model provides an abstraction layer to the external environment that hides the internal detail of how the physical IED implement the operations related to physical objects. VMD model translates the physical objects of IED into virtual objects which are accessed by the client program or client device. Therefore, the model enables the client to make communication with multi-vendor IEDs installed in the substation because the physical implementation details of the IEDs are hidden to the external world and makes MMS interoperable. An interaction of a client and an IED (server) is shown in Fig. 3. |
 |
| MMS provides the following advantages: |
| • Interoperability: MMS supports complex named objects and flexible services that provide a straightforward mapping to IEC 61850 for making communication interoperable. |
| • Independence: Because of interoperability, MMS provides a universal communication that is not dependent upon the functions performed by the IED. It was possible because of an abstraction layer that isolates the external environment from the functionalities implemented in the IEDs. |
| • Data Access: MMS enables the applications running at station level to obtain the information required by them to provide supervisory control functions across a network in a client/server environment. |
EXPERIMENTAL TEST SETUP |
| Fig. 4 shows a laboratory test setup for fetching the data from an IEC 61850 relay IED using a client source code running on a laptop. The setup uses the following tools for fetching the data from IED: |
 |
| Fig. 4 Laboratory test setup |
| A. MMS-EASE lite client source code |
| SISCO’s MMS-EASE Lite 5.10 is a Windows based software package containing a library of C functions that helps in implementing real-time application interface of MMS, GOOSE etc. as per the requirements [13]. The source code embeds the IEC 61850 protocol in IEDs, energy meters, PLCs, and other smart devices. The source code contains various modules, libraries, functions calls with sample code for supporting the communication with 61850 compliant devices and helps in integrating the devices for exchanging the information. Source code configuration and customization steps are presented in section IV. |
| B. IEDScout |
| IEDScout is a universal client program for IEC 61850 based IEDs/devices to see what is happening inside the IEDs [14] The client program discovers/browse the data model defined in the IED to read the actual values of the data objects. Purpose of using the IEDscout program here in this paper is to know the nomenclature of a domain name of a logical node and their attributes in order to hook them correctly inside source code program. A partial view of IEDScout client program is shown in Fig. 5 where, for better clarity, “IED_0002MEAS” represents a logical device, “MMXU1” represents a logical node, “MX” represents a functional constraint, “Hz” represents a data object, and “mag” represents a data attribute that contains the final value of a variable “frequency”. This nomenclature is called inside the source code program as discussed in the section IV. |
 |
| C. CMC 256plus |
| In the experimental test setup, SIEMENS IED SIPROTEC 7SJ64 is not connected to field devices. Therefore, to provide some test values to relay IED, a test set CMC 256plus; the left most device as shown in Fig. 4 is used. The CMC 256plus test set uses programmable voltage and current source for providing some sample test values to rely IED [15]. |
CONFIGURING SOURCE CODE FOR FETCHING DATA FROM IEC 61850 IED |
| We used Microsoft Visual C# developer environment to browse the installed source code. Following are the steps used in fetching the data from the IED. |
| Step 1: Configure the “osicfg.xml” file for providing the IP address of the remote IED from which the data need to be extracted. Fig. 6 shows a partial snapshot depicting the modification required for entering the IP address. This file is being referred by the source code internally to read configuration information while establishing the communication with remote IED. |
 |
| Step 2: Use C# visual studio to browse the “client.c” file incorporated in a solution file called mmslite802 placed in a win32 directory at the installed location of the source code. Explore the “cositcps0 Client App (NUL Security)” under a sample folder “General MMS Samples” for customizing the “client.c” program as shown in Fig. 7 |
 |
| Step 3: In the “main” function of client.c, call a function “domvar_type_id_create” to create a unique type ID for a particular domain. The called function must be comprised the following parameters: |
| • clientNetInfo – pulls the network connection information automatically. |
| • IED_0002MEAS – shall be a domain name i.e. a logical device as shown in Fig. 5 |
| • MMXU1$MX$Hz$mag – is a format for initializing the parameter frequency while creating the type ID for a particular domain where “MMXU” indicates a logical node, “MX” indicates a functional constraint, “Hz” indicates a data object, and “mag” indicates the data attribute. |
| Similarly, other type ids for different parameters can also be configured just by looking at their hierarchical structure using IEDScout of Fig. 5. |
| Step 4: Just after calling the above function, invoke a function “named_var_read” for reading the value of a parameter frequency with following inputs: |
| • clientNetInfo – already described in step 3. |
| • MMXU1$MX$Hz$mag – already described in step 3. |
| • DOM_SPEC – initialized automatically indicating domain specific names for internal use. |
| • IED_0002MEAS - already described in step 3. |
| • Meas_type_id – shall be of type integer that will contain the type id of the parameter returned by the function “domvar_type_id_create” called in step 3. |
| • Value_param – may be of type integer or float where value of the parameter will be stored. |
| • Timeout – contains some integer value e.g. 1000 indicting waiting time of 1 second for listening the response from IED. |
| After configuring the step 3 and step 4 for each parameter, build the “cositcps0 Client App (NUL Security)” library step by step to see the extracted parameter’s value as shown in Fig. 8 depicting a command output window. In the experimental test set up we configured only four parameters: voltage phase AB, voltage phase A, current phase A, and frequency. |
 |
| Hence it is demonstrated that by using the implemented steps, the practicing engineers can use the source code to fetch data from IEC 61850 IEDs without writing the whole program from scratch that can save lot of time and engineering efforts. |
CONCLUSION |
| This paper demonstrates a laboratory test setup where the IEC 61850 source code was configured and customized for fetching various parameters from IEC 61850 IED. The fetched data is used for other operations like presenting the data in some useable manner or sharing the data with other applications running at higher levels in the substation etc. The paper further discusses the role of MMS in IEC 61850 that helps in understanding the communication between the client and the server. |
| Therefore, as per the substation automation requirements, the source code can be customized to provide different goals and objectives. The paper demonstrated a sequence of steps for configuring the IEC 61850 source code which enhances the knowledge of researchers towards using it for communicating with IEC 61850 based IEDs leading to reliable automated substations. |
References |
|