21, rue dArtois, F-75008 PARIS http : //www.cigre.

org

(CIGRE-137)

CIGR Canada Conference on Power Systems Vancouver, October 17- 19, 2010

Improving IEC 61850 Interoperability: Experiences and Recommendations

J. NIEJAHR1 , H. ENGLERT 2, H. DAWIDCZAK 3 Siemens AG1(CAN), Siemens AG2(GER), Siemens AG3(GER)

SUMMARY Today IEC 61850 is the worldwide established communication standard for power utility automation. Performance, reduced life-cycle costs and interoperability are quoted as main drivers for its use. Currently the major application of IEC 61850 is in substation automation, where practical experience from several thousand installations has been gained. Most of these installations are predominantly single-vendor solutions with some special devices from other vendors, a few are full multivendor systems. These multivendor projects revealed that the interoperability capabilities of the available products and systems are currently limited and therefore lead to additional engineering efforts. This paper gives a definition of interoperability in the context of IEC 61850. It discusses the experiences gathered in multivendor projects and interoperability tests and identifies technical reasons for limited interoperability. Based on this analysis, a new concept for flexible IEC 61850 data modeling is presented, which helps to overcome the interoperability limitations - it even allows the exchange of devices with a minimum of re-engineering. Recommendations are given, how this concept can be applied in practice in order to avoid additional engineering costs.

KEYWORDS Multivendor Projects, Engineering, Interchangeability, Operation, Substation Automation, Testing

heiko.englert@siemens.com

1. INTRODUCTION -- INTEROPERABILITY / INTERCHANGEABILITY The standard IEC 61850 was developed with the goal to provide interoperability as key deliverable [1]. Although the standard has a clear definition of what is meant by interoperability, users interpretations may vary sometimes understood as interchangeability, even a plug and play feature is expected. The following sections shall explain these terms in the IEC 61850 context. 1.1 Interoperability According to IEC 61850, Interoperability is the ability of two or more IEDs (Intelligent Electronic Devices) from the same vendor, or different vendors to exchange information and uses that information for correct co-operation [1]. This definition includes two important aspects: information exchange and co-operation. Fig. 1 depicts the concept of the standards definition of interoperability.

IED

Information Exchange

IED

System Function
Figure 1: Concept of two IEDs establishing a common system function An example of a typical SAS system function shall give an illustration: assuming the example of substation interlocking based on IEC 61850, the IEDs would represent two bay controllers IED A and B. In order to avoid energizing an earthed busbar, IED A may send position information of busbar earthing switches to IED B. IED B then is able to allow or block connecting the appropriate bay to the busbar. For the realization of such system functions, both IEDs require a common understanding of the information exchange and the application to form the desired system function. From an abstract point of view, information exchange and application function can be divided in different interoperability layers. Fig. 2. shows these layers respectively [2], which can be explained as follows:

Business Context

IED

Semantic Understanding Syntactic Interoperability Network Interoperability Basic Connectivity

Figure 2: Interoperability layers [2]

IED

Basic Connectivity: This layer establishes the physical or logical connection of both IEDs. In the previous example this is represented by the optical / or electric Ethernet cable as well as plugs and sockets. Network Interoperability provides methods for the data exchange over different networks. In IEC 61850 this is represented by Ethernet covering the OSI physical, data link and network layers. Syntactic Interoperability includes the common understanding of the internal structure of the data, which is exchanged between the IEDs. In the above-mentioned example, this means both IEDs are understanding the coding of the switchgear position information in MMS protocol in combination with the use of appropriate MMS communication services. Semantic Understanding represents the common sense about the contents and meaning of the exchanged data. Regarding the example, this means that both IEDs have a clear understanding that the exchanged data represents the position of a distinct switch gear, by the use of standardized IEC 61850 objects (logical nodes, data objects and data attributes) Business Context represents the understanding about the correct use of the exchanged data to fulfill the desired application function. In case of the interlocking example this includes IED As transmission of the position information in case of a position change and the use of this information by IED B in order to determine if connection to the busbar is allowed or not. IEC 61850 covers the interoperability levels from Basic Connectivity to Semantic Understanding. The layer Business Context is not standardized. Its definition takes place in bilateral specifications between users and vendors or system integrators. User specify their functional (e.g. interlocking concept) and non-functional (e.g. redundancy concept) requirements for an SAS project. It is on vendors or system integrators to provide products and solutions, which meet the user requirements. Interoperability is achieved, when two or more vendors can fully support the user requirements covering all interoperability levels. Standardizing even the Business Context layer would increase interoperability, but on cost of vendor competition and consequently innovation. Harmonizing SAS application functions through best practice guidelines and user recommendations [3, 4] seems a reasonable approach to increase interoperability and not to hinder innovation. 1.2 Interchangeability According to IEC 61850, Interchangeability is the ability to replace a device supplied by one manufacturer with a device supplied by another manufacturer, without making changes to the other elements in the system [1]. 2

As a difference to interoperability, in IEC 61850 interchangeability is understood to have identical process and communication interfaces and in addition identical functionality with same function and system parameters. This implies identical algorithms for protection and automation functions. Therefore, interchangeability is achievable today only with IEDs of the same type from the same vendor. Consequently, the standard IEC 61850 states: Interchangeability is beyond this communication standard [1] in order to allow competition and innovation as mentioned in the previous section. By analyzing use cases and requirements of users (predominantly transmission system operators), a different type of interchangeability can be identified interchangeability on communication level [5]. This means identical behavior of the communication interfaces of IEDs from different vendors, which is independent from the vendor specific implementation of IED functionalities. This is the type of interchangeability what users expect and vendors shall be able to provide [5].

2. CATEGORIES OF IEC 61850 MULTIVENDOR SYSTEMS Basically different categories of IEC 61850 multivendor systems can be distinguished [6]: Category A: station controller, bay controllers and protection devices are from a single vendor. IEDs for special purposes like voltage controllers, power quality meters or equipments monitoring are provided by different vendors. Category B: bay controllers and protection devices are from the same vendor, the station controllers and special purpose IEDs are from different vendors. Category C: station controller, bay controllers, main 1 protection, main 2 or backup protection device are from different vendors, respectively, as well a special purpose IEDs. Category D: devices from different vendors are mixes with no distinct prefer. Today most of the multivendor projects are of category A type, in contrast to Category D, where only a few projects were carried out in form of pilot or research projects. Most relevant for interoperability issues are the multivendor projects of category B and C type. In these projects the full range of interoperability requirements from simple interoperable functions up to the interchange of bay controllers and protection devices are posed.

3. EXPERIENCES Utilities, research labs have carried out several pilot and research projects to evaluate the interoperability capabilities of the IEC 61850 product implementations. The following project examples shall give an overview on experiences and the progress that has been made: TVA conducted an IEC 61850 multivendor project in 2005 [7]. Designed as a category C project, the first generation of IEC 61850 devices and tools was applied. CFE realized a multivendor project (category C) in 2006 [8] with focus on IEC 61850 interoperability including device interchangeability. FGH concluded a research project with the scope on investigation of the interoperability capabilities of different vendors in 2010 [10]. The project was realized in a laboratory as a category D system. 3

All projects were carried out based on IEC 61850 edition 1. The experiences can be summarized as follow: 3.1 Implementation Maturity In early projects the first generation of IEC 61850 devices and tools were used. These showed big differences in implementation maturity. IEC 61850 certified devices together with beta devices were integrated into systems, often resulting in communication mismatch. The project teams developed workarounds and fixes to overcome the communication issues. These valuable experiences were fed back as Tissues (technical issues) to the IEC 61850 standardization community. In the recent multivendor research project [10] the second generation of IEC 61850 products and IEC 61850 firmwares was applied. Those devices and tools consider the current level of tissues, also including the experiences of previous multivendor projects. All devices were IEC 61850 certified. Taking into account that IEC 61850 certificates do not necessarily mean that the devices offer high interoperability [9, 10], but indicate the devices implementation maturity in respect to communication services. Consequently, interoperability on communication level was quickly achieved - as basis for SAS application functions. 3.2 Flexibility in supporting data models and communication services All projects revealed that the vendors have implemented different concepts of IEC 61850. This includes differences in data model structure, supported data model objects (logical nodes, data objects, data attributes) and supported communication services. In the early multivendor projects, it was hard to find a common set of data model objects and communication services. Simplistic and inflexible IEC 61850 implementations set the common de-nominator. On this small common basis the application functions were developed and did not leverage the full capabilities of IEC 61850. Device interchangeability was partly achieved by copying the complete IEC 61850 data model of one device to another device. This procedure and its result was neither conformant to the IEC 61850 standard regarding certification, nor engineering efficient. The application data was manually mapped to the copied IEC 61850 data model. Consistency was lost, as the copied data model contained fragments of unsupported data objects and communication capabilities. The recent multivendor project showed that the current products are more flexible than the first generation in data modeling and communication services. Therefore, it was possible to test and verify sophisticated SAS application function (e.g. autoreclose coordination, busbar voltage replica with synchrocheck) [10]. 3.3 Engineering quality and efficiency The first generation of IEC 61850 engineering ranged from direct SCL coding with XML editors up to support by integrated engineering suites. At the early multivendor projects, it was advantageous to have the possibility for a direct manipulation of SCL files. This was necessary because of the frequency of communication issues and therefore configuration updates. Configuration consistency was a challenge, because simplistic IEC 61850 implementations were configured by separate upload of IEC 61850 CID files and application parameter files. As consequence a mismatch between IEC 61850 configuration and application parameterization was a further risk. Consequently, a large amount of engineering efforts was required to conclude the multivendor projects [8, 9] In the recent multivendor projects there was no need for direct SCL manipulation The used IEC 61850 engineering tools were mature and flexible offering both detailed parameter manipulations for IEC 61850 experts as well as a simple configuration mode for IEC 61850 4

beginners. All engineering steps were carried out by the vendors device and system configuration tools. The maturity of these tools provides quality and ensures data consistency over the whole system. A configuration change was automatically identified by the IEDs. As result, engineering was straightforward and quite efficient compared to early multivendor projects. 3.4 Testing During the early multivendor projects only few distinct IEC 61850 testing tools were available. Those tools - network sniffers, traffic capturing tools and IEC 61850 data model browser - were designed for network experts only. Debugging capabilities, which were built into the devices, were still poor. Establishing a correct Goose communication was challenging. The effort for identification and resolving of communication and application issues was high. Currently new testing tools are available with sophisticated IEC 61850 functionalities and improved usability. Functions to compare the SCD system configuration with the real network traffic helps to identify e.g. missing or non-configured Goose telegrams. The tools are now intuitive allowing their use by regular commissioning staff. As a result, at the recent multivendor project, the effort for resolving the few communication and application issues was minimal.

4. USE CASE IED EXCHANGE 4.1 Basic Scenario The basic scenario describes the system and communication configuration of a substation automation system (SAS) and the fundamental issues for the exchange of an IED regarding IEC 61850. A typical SAS consists of a station and a bay level (Fig. 3): IEDs at the bay level, for example protection relays, bay or transformer controller, and station controllers and local HMIs at the station level. The interbay-communication with IEDs at the same bay level is executed typically with an IEC61850 GOOSE service. The communication of IEDs to one or several station controllers and local HMI is executed in a client-server mode. From the various IEC61850 communication services, the reporting service is often used.

Control Center Local HMI

IED to be replaced
Station Unit

Report Goose
Protection & Bay Control IEDs

Report

Process

Figure 3: Basic scenario, including the IED, which shall be replaced GOOSE is a multicast communication service. A publisher sends multicast telegrams and the configured subscriber read, decode and process the information in these telegrams. The configuration for the GOOSE communication will be carried out with the help of the system configuration description language (SCL). The configured data objects are provided by the publisher IED to all participants in data sets and so called GOOSE control blocks (GoCB) in a SCL-description (SCD). The reporting communication will also be configured in the SCD. The instances of the data objects will be selected within the data model and the references will be collected in data sets. By report control blocks (RCB) the detailed behavior of the client-server communication will be described in the service the report. 4.2 Use Case IED Exchange According to the current cost pressure and the high power system utilization regarding capacity, out-of-service times of substation equipment and therefore the duration of service in case of equipment failure shall be minimized. A typical example is the failure of an IED which has to be replaced by spare IED (see Fig. 2). The goal of this use case IED Exchange is to replace an existing IED A in a bay through another IED B. The following requirements shall be taken into account: IEDs A and B fulfill the same functions (e.g. protection and control) IEDs A and B are of different type (vendor or product version) Reengineering and testing of other IEDs in the system environment shall be avoided. This means that the IEDs in the system environment shall not detect any changes in respect to IEC 61850 communications. Consequently, the IED B must provide the exact behavior of IED A at the communication interface. This includes the aspects of IEC 61850 data model and services. Current limitations regarding exchange of IEDs The following limitations may complicate the exchange of IEDs: The internal data structures (LD-/ LN structures, see Fig. 3) of the devices are not flexible. It is not possible for the user to configure these data structures according to the structures of the previous IED. 6

The data classes (LN, DO, DA) that are required by the users are not supported the IED. The optional features of the IEC 61850 communication services are implemented in a different way by vendors.

Figure 4: Example - IED A and IED B with different data model As result, the behavior of the replaced IED is different to the previous IED. This makes reengineering and testing of the IEDs of the system environment necessary in order to achieve a consistent and operating substation automation configuration. Therefore the requirements of the use case IED exchange cannot completely be fulfilled. Requirements for exchange without additional IEC 61850 configuration changes In order to overcome the limitations of the current implementations the concept of Flexible Object Modeling and Naming was developed [7]. This approach covers the use case IED exchange completely by fulfilling the following requirements. Flexibility of the implemented data model of the equipment. Possibility of the users determining the logical device structures (LD). Creating and using the possibility of the user LD with that. Free creating LN in conformity with the standard. Possibility of the complete use of all essential data classes the IEC 61850 (LN, Do, since) Free name of IEDName, LDinst, Prefix and suffix. Complete mapping of the service features. The possibility carrying out the settings of the reporting and GOOSE communication identically being able to do. The elements of the data sets must particularly be absolutely identical with respect to contents and order. The information which shall be transmitted about GOOSE is used only from the FCDA level (Functional constraint data attribute). The telegrams of the reporting between server to the client shall contain only FCD elements (functional constraint data). Controllable data objects must be the same. This indicates that the location must be identical in the data model. The mapping specific structure of these objects also must be same. The control model shall be the same. also the behavior during the control sequence shall be equal e.g. use of the addCauses.. Configuration revision values (configRev) for the supervision of a solid GOOSE communication must be taken into account.

At the flexible configuration of the data structures and communication settings it must be taken mandatorily into account that there are limits and dependences between the application software and the data modeling. It has to be considered that in most cases the use of the data objects mode/behavior is not or only restrictedly possible on Logical Device-level. This has effects on testing concepts. The setting groups also must be on the top level of the LD. If settings of setting groups will be separated by the modification of the LD structure, than they cannot edit by communication services any more.

5. RECOMMENDATIONS The beneficial use of the replacement concept comprises proper planning, preparation and implementation. During planning of substation automation systems, the user has to select the IEDs capable for replacement according the following rules: Ensure that the set of IEDs, which are selected for replacement, provides a comparable functionality (e.g. protection and control) and physical compatibility (terminals, auxiliary voltage level). Ensure that all IED (including station controllers) can provide IEC 61850 certificates. Ensure that the set of IEDs supports a common set of data classes and communication services. This includes the ability for Flexible Object Modeling and Naming. In order to allow a fast replacement in case of IED failure, the IED configuration shall be prepared. This includes the pre-configuration of functions, data model and communication services. This pre-configuration can be carried out on tool-level. It is recommended to test the replacement in an offline system test bed and ensure the correct behavior prior to real application. In case of a IED failure, the IEDs are physically replaced. The pre-configuration of the spare IED is adapted to the specific application and uploaded. With a final verification of functions and communications, the replacement is completed. 6. CONCLUSION It is essential, that all stakeholders in the substation automation industry have a clear understanding of IEC 61850 interoperability. This is the basis for realistic user expectations and driver for product improvements. The experiences gathered in multivendor projects made important contributions to the IEC 61850 standard and the industries products. As result, recent multivendor projects showed, that achieving interoperability in pure multivendor projects with the currently available products and systems is practically possible. Nevertheless, these multivendor projects require additional specification and engineering efforts, as well as a high level IEC 61850 expertise. The new concept for flexible adaption of IEC 61850 data models and communication services improves the interoperability of products and systems regarding simplicity and functionality. The concept even allows the interchangeability of IEDs on communication level.

7. BIBLIOGRAPHY
[1] [2] [3] [4] IEC 61850: "Communication networks and systems in substations, Ed.1, 2004. NIST:NIST Framework and Roadmap for Smart Grid Interoperability Standard Release 1.0, NIST Special Publication 1108, http://www.nist.gov/smartgrid, 2010. DKE AK 952.0.1 "IEC 61850 - Engineering": Applications using the services of IEC 61850, www.dke.de/61850, 2008. Krings, H., Schroeder A. , Wittlinger P., Mainka M., Druml G., Hittmayer, Kurrat J., Haecker, M., Thompson, S., Englert H.: Investigating Interoperability of IEC 61850 Devices of Different Suppliers: Functional Specification for Testing, FGH, Mannheim, 2009 Dawidczak, H., Englert, H.: IEC 61850 Interoperability: German user requirements and implementation experiences CIGRE Session, Toronto, 2009. Paulo, R., Matos, F.: Practical Experience with IEC 61850 Multivendor Systems and Foreseeable Future Application A System Integrator and End-User Perspective, Cigre Session, D2-B5 103, Paris, 2010. Ingram, M.R. Ehlers, R.: Integrating IEC 61850 at TVA Substations for Protection, SCADA, and Enterprise Applications, Transmission and Distribution Conference and Exhibition, IEEE PES, Dallas, 2006. Flores, V.M., Espiniosa, D., Alzate, J., Dolezilek, D.: Case Study: Design and Implementation of IEC 61850 from Multiple Vendors at CFE La Venta II, SEL, 2007. Krings, H., Schroeder A. , Wittlinger P., Mainka M., Druml G., Hittmayer, Kurrat J., Haecker, M., Thompson, S., Englert H.: InterOP - a Research Project to investigate Iinteroperability of IEC 61850 Technology, Power Grid Europe Conference, Amsterdam, 2010 Dawidczak, H., Englert, H.: Improving IEC 61850 interoperability by flexible object modeling and naming, PAC-World Conference, Dublin, 2010.

[5] [6] [7]

[8] [9]

[10]