1 Verifying the IEC 61850 Configuration and Assessing the Communication Network during Commissioning Dr. Fred Steinhauser, OMICRON, Austria Abstract Although IEC 61850 is sometimes just called the "new communication protocol for the substation" it is much more. Besides the fact that it indeed defines a collection of protocols for different purposes (GOOSE, Sampled Values, Client/Server), there are many more elements which are defined by the standard. One of these additional elements is the Substation Configuration Language (SCL) [2]. Its intended purpose was for engineering, especially the vendor independent engineering. While the IEC 61850 community is still working hard to achieve this goal to the full expectations of the customers, the SCL already serves multiple uses when dealing with IEC 61850 devices and systems. The SCL as universal data source One important aspect is that the SCL is a perfect basis for testing. The SCL contains the communication configuration. While this was still partly incomplete in IEC 61850 Edition 1, this has been essentially enhanced in Edition 2. For instance, not only the publishing side of the GOOSE communication can now be persisted in an SCL file, but also the subscriptions. From an SCD (Substation configuration description) file, that contains the communication definitions for the whole multiplicity of devices comprising the protection, automation and control (PAC) system, it can be easily derived which GOOSE messages and SV streams that should be present in the power utility communication network if all publishing devices are connected, active, and correctly configured. It is now possible to sniff this actual traffic from the communication network and to verify if it matches the configuration from the SCL file. Fig. 1 The SCL description contains information which actual traffic shall be on the network Matches and orphans The criteria for a match are not exactly defined by the IEC 61850 standard. It takes some common sense to come to a useful convention. Identifiers GOOSE messages and Sampled Values streams have multiple "identifiers", such as control block references (CBRef), GOOSE ID, SV ID, APPID, multicast MAC addresses. But when looking at the details of the definitions, e.g. for GOOSE, it becomes obvious that only the GOOSE control block reference is really unique. The other identifiers are not necessarily unique (although partly recommended), so they can be used e.g. for filtering, but not really for unambiguously identifying a GOOSE message. For a human, these control block references are readable and, if sensibly constructed, give good information about the GOOSE's origin and use. But technically speaking, these are potentially long strings (of variable length) and thus among the most ineffective data structures for performing a comparison. With the Sampled Values, a different practice has been established: while the control block references are still unique, the mainly used identification field is the Sampled Value ID (SvID). Of course, it must then be also unique within the scope of the application using the SV streams. During this verification, multiple results can occur. If all identifiers match, the verification can be simply checked as "OK". If only the "main" (unique) identifier matches but there are differences with others, the device is obviously online and publishing, but there are configuration issues that have to be resolved. If an expected GOOSE message / SV stream is not found, it needs to be checked first if the IED is online at all. The non-matching cases have to be worked off until all comparisons show a perfect match. The following figure shows a list of IEDs (the SLC file represents an artificial case from a multi-vendor interoperability demonstration) and related GOOSE and Sampled Values definitions being parsed into a testing tool.
2 Observation of the process quantities Observation is a live view on the data for checking if the connected, acquired and mapped signals are plausible. Wrong scaling of ratios of instrument transformers or inverted binary statuses become visible at this stage. The time resolution on this function is not suitable to assess the exact timing of the signals, but it can well be observed if the values change as expected. Fig. 2 GOOSE and Sampled Value information parsed from an SCL file for comparison with actual traffic published by the IEDs During commissioning, the case of not having all devices online at the same time is not unusual. So the option of incrementally re-checking the configuration without losing previous results is useful. Orphans It can also occur that GOOSEs or SVs show up that have not been defined in the provided SCL file. Such messages that cannot be related to a configuration are called orphans. By additionally loading SCL files that contain information for individual IEDs (typically ICD or IID files) such cases can be resolved as well. The last resort is manually creating an IED entry to relate the messages to and to make use of the conveyed data later on. Mapping and Observation To use the information coded in the messages, they need to be mapped to a "signal" that represents the actual meaning of the information in the electrical power system. For example, binary status information from GOOSE messages may be mapped to binary traces, just as if the information came from a conventional binary input. The data in Sampled Values packets have to be mapped to voltages and currents to represent their actual meaning. Fig. 3 Observation view with binary trace originating from a GOOSE message This step ensures that the values recorded later on are correctly connected and calculated. Recording and analysis For an in-depth investigation of the signals, especially the timing, recordings have to be made and analyzed. Fig. 4 Flexible trigger conditions for good discrimination of events to be captured in a recording To make the acquisition device recording only the events of interest, flexible and configurable trigger conditions are required. During commissioning, this might not be much of an issue because the start of the test case can be easily detected in most cases. But for troubleshooting, the importance of a sophisticated trigger condition is much more significant. The particular metrics that can be derived from recorded data and which are useful for assessing the communication network are occupied bandwidth and propagation delays for Ethernet packets when traversing through the network. These values are not calculated from the mapped signals, but from the generically captured traffic on the Ethernet network.
3 Propagation delay measurements From recorded network traffic, the bandwidth usage can be displayed, showing in detail which kind of traffic (GOOSE, SV, IP) contributed which share to it. Such an analysis is valid for a single port and can be easily obtained. To measure propagation times, data from at least two different locations need to be captured. The captures need to contain the same Ethernet packets, showing up at the different locations at different times. When captured, the packets obtain an accurate time stamp. The propagation delay is the difference of the time stamps. When this calculation can be performed for many packets, solid statistics can be evaluated. In a local network, such measurements can be relatively easy performed when it is possible to reach all locations from which traffic is to be captured from one single measurement device. The relative timing of the data packets captured with the device is always accurate and no additional time synchronization is required. The figure below shows such a measurement setup for a minimal network with two switches S1 and S2 that are connected by a trunk link. The next figure shows the delay time distribution of the Sampled Values under the described conditions. Fig. 6 Delay time distribution with ICMP packets (size: 500 bytes) as network load The left two bars, that contain most (96 %) of the measured packets represent the delay times between 25 µs and 28 µs. This is the time needed for a packet to traverse the little network undisturbed. The bars to the right, extending to delay times with a maximum of 66 µs, come from packets that got in conflict with one of the ping packets. The maximum is exactly 40 µs (the duration of the ICMP packets) higher than the average value for an undisturbed passage. This result matches perfectly the expectations that can derived from the theoretical examination of the situation. This demonstrates how other traffic can for example influence the transfer times of mission critical information in such networks. On the other hand, the actual performance of a communication network can easily be assessed by looking at the propagation delay distribution for a certain type of traffic. Outliers at with high propagation times are a safe indicator for a problem in the communication network. Conclusion Fig. 5 Possible measurement setup in a LAN A Sampled Value source (a merging unit) publishes one Sampled Values stream into the network. The measurement device captures the Sampled Values packets coming from the Sampled Values source before they enter the network at switch S1 and then again when they are broadcasted from the other switch S2, after traversing through the network. A PC connected to switch S1 generates load traffic by "pinging" an IED which is connected to switch S2. This forces ICMP messages to be exchanged over the trunk link and therefore interfering with the Sampled Values. The ping utility used for generating this load traffic allows specifying the size and the frequency of the ICMP packets. In the used setup, all Ethernet links, also the trunk link, operated at 100 Mbit/s. The ICMP packets were be issued at a rate of about 1000 packets per second. At a packet size of 500 bytes, one ICMP packet occupies the network for 40 µs and the ping packets utilize 4 % of the total bandwidth. When commissioning a power utility automation system with IEC 61850, some new testing tasks need to be performed. But with the usage of the configuration information in standardized SCL format and with modern measurement equipment, the verification of the communication setup is even easier to perform as with other protocols. The proper setup and performance of the power utility communication network itself can be easily verified by looking at the propagation delay statistics. Possible problems with the network performance would become visible as unexpectedly high propagation delay values. Bottom line, the described tasks can be performed in much shorter time than formerly needed for doing the corresponding checks with conventional signaling and communication technologies, which are now replaced by IEC 61850.
4 Literature [1] Ingram, D., et. al.: Direct Evaluation of IEC 61850-9-2 Process Bus Network Performance. IEEE Transactions on Smart Grid, Vol. 3, No. 4, December 2012 [2] IEC 61850-6: Communication Networks and Systems for Power Utility Automation. Part 6: Configuration description language for communication in electrical substations related to IEDs. IEC, 2009 [3] Steinhauser, F.: Measuring the Performance of GOOSE Communication - Assessing IEC 61850 Real Time Messaging, CIGRÉ SEAPAC 2011, Sydney About the Author Dr. Fred Steinhauser was born in Austria. He studied Electrical Engineering at the Vienna University of Technology, where he obtained his diploma in 1986 and received a Dr. of Technical Sciences in 1991. In 1998 he joined OMICRON, where he worked on several aspects of testing power system protection. Since 2000 he works as a product manager with a focus on substation communication issues. Fred Steinhauser is a representative of OMICRON in the UCA International Users Group. As a member of WG10 and WG17 in the TC57 of the IEC he contributes the standard IEC 61850. He is also a member of SC B5 of CIGRÉ.
OMICRON is an international company serving the electrical power industry with innovative testing and diagnostic solutions. The application of OMICRON products allows users to assess the condition of the primary and secondary equipment on their systems with complete confidence. Services offered in the area of consulting, commissioning, testing, diagnosis and training make the product range complete. Customers in more than 140 countries rely on the company s ability to supply leadingedge technology of excellent quality. Service centers on all continents provide a broad base of knowledge and extraordinary customer support. All of this together with our strong network of sales partners is what has made our company a market leader in the electrical power industry. For more information, additional literature, and detailed contact information of our worldwide offices please visit our website. www.omicron.at www.omicronusa.com OMICRON