Experience with Testing and Configuration of IEC 61850 Multivendor Protection Schemes

Authors: Rene Aguilar and James Ariza, Megger, USA

A test device must be able to subscribe as well as publish GOOSE messages. The IED being tested will publish or send a GOOSE to tell the breaker to trip. The test device subscribes to the GOOSE issued by the IED under test and reacts to it according to the test procedure.

Some of the challenges facing the testing of IEC 61850 include the lack of knowledge that protection specialists have of the standard, and also understanding the functionality and implementation of the test system used. In order to know what GOOSE messages to monitor, the user has to be aware of the basics of IEC 61850. For example, SCL (Substation Configuration Language) files contain all the information of how the substation is configured but most importantly what GOOSE messages are available.

A. Description Languages – SCL Files -Part 6 of the IEC 61850 standard introduced a common language used to exchange information between different manufactures. This guarantees interoperability and enhances the configuration phase. Each proprietary tool must support the export of the IED’s description into this common, XML-based language. The development process of a project based on IEC 61850 depends on the availability of software tools that make use of the SCL language.

SCL specifies a common file format for describing IED capabilities, a system specific caption that can be viewed in terms of a single line diagram, and a substation automation system description. Part 6 of IEC 61850 introduces four types of common files. These files are the IED Capability Description (ICD), Configured IED Description (CID), Substation Configuration Description (SCD) and System Specification Description (SSD) files.

The configuration can be performed by a manufacturer’s independent tool. Some manufacturers have advanced their proprietary software tools in a way that they can be used as IEC 61850 system configurators, however, there are also some third party tools available. All ICD files get imported into the IEC 61850 system configurator, which allows the configuration of GOOSE messages by specifying the senders (publishers) and the receivers (subscribers) of messages. The system configuration tool creates the SCD file, which includes the one line diagram of the station and the description of the GOOSE messages.  Each IED Configuration Tool must be able to import an SCD file and extract the information needed for the IED - the GOOSE messages that a particular IED will subscribe and publish (Figure 1).

It is important to know that in addition to the configuration information specified by part 6 of IEC 61850, the configuration of an IED should be completed with a proprietary IED configuration tool and can have either a proprietary format or a standard CID format.

A common misconception between vendors is what type of SCL file should be generated. Some of the IEDs will only export an ICD file while others export a CID file. Technically, these two file types are similar, the difference is how each one is generated. However, this creates a challenge when trying to configure the entire system. The download process of putting the final configuration into the IED has not been strictly standardized by IEC 61850. Manufacturers use one of the following ways to load the configuration file to their devices:

  • FTP protocol
  • IEC 61850 file services
  • Proprietary protocols designed for file transfer

B. Substation IT Network Security - As communications in the substation take on more critical roles in the protection and control task of the utility, it is important for the protection engineer to understand the basics of the IT network, the behavior and characteristics of components like Ethernet switches, Ethernet ports, and router, as well as being familiar with terminology such as LAN, VLAN, IP address, Mac Address, Network Topologic, firewalls, etc.

Many experienced protection engineers find discussion of IT network issues to be dense and perhaps intimidating, because until now they have not faced the need to understand the behavior and performance characteristics of IT Networks. Ethernet switches are as important to understand as protective relays in order to achieve availability, dependability, security and maintainability goals of the substation.

A security concern is the method an IEC 61850 substation is tested. The concern is the direct connection of a PC to the substation bus during the test. The issue is that a PC might be infected with a virus that could create GOOSE traffic on the network. This could lead to critical messages being delayed due to excess traffic. The generation of GOOSE messages from a PC could potentially trip out the substation.   To avoid some of these issues, several utilities have dedicated PC’s that are only allowed to be connected to the LAN when performing tests. This will prevent a possible compromise of the network due to an infected PC. It is also important that the tester be familiar with his testing tools and knows whether or not it will generate GOOSE messages from the PC.

Another solution is to use the test set as a firewall between the substation and the PC.  This could be done if the test set has available two Ethernet ports completely isolated from each other. One of the ports can be used to control the test set from the PC, while the other is connected to the actual substation LAN. In this manner, only the test set will be allowed to publish or subscribe to GOOSE messages. This helps to prevent the possibility of tripping the substation due to a loose GOOSE.

Configuration and Verification of GOOSE Messages

To describe how to configure and verify GOOSE messages for an automated IEC 61850 substation we will use a communications based breaker failure scheme. Figure 2 shows the one line diagram of the system. The system has four IEDs from different vendors which are shown as relays A, B, C and D. Relay’s B, C and D are the main feeder protection and relay A is the backup protection. Not shown are the IEDs in the breaker cabinet that take the GOOSE messages from each relay and convert them to a physical output to energize the breaker coil. In this example, a fault has been placed at location A, marked in the one line diagram. The instantaneous overcurrent element in relay B will transmit a GOOSE to breaker B.

Simultaneously, relay A will receive the GOOSE from relay B as the breaker failure initiate signal. Relay A will receive this GOOSE and it will initiate the breaker failure timer, which will expire in 167 ms.  If for any reason the breaker failure initiate signal is not received and breaker B does not open, relay A will trip on a definite time over-current in 250ms. This section will only show the configuration between relays A and B. This same process is repeated for the other IEDs on the system.

The programming of this scheme can be achieved in two parts. The first part is the programming of the individual IEDs in order to obtain the ICD or CID file required for the configuration of the system. These files will contain the published GOOSE messages for each IED. With this information the full system configuration can be accomplished. Before any configuration can occur, it is a good practice to create a virtual wiring map. This map will show what messages are going to be required in order to configure the scheme of interest. The map provides such information as to what GOOSE messages each IED will publish and subscribe. Figure 4 shows the virtual wiring map for the communications based breaker failure scheme.

A.  Configuration of individual IEDs- The IED is configured via its own proprietary configuration tool. It is important to get familiar with how each configuration tool works. This will save time in the long run, especially when trying to configure the system scheme. The primary goal of configuring the IED is to obtain the SCL file types necessary for the system configuration.

The SCL file types of interest would be an ICD or CID file (depending on the IED vendor). These files provide the overall information as to how the relay is configured but most importantly, what GOOSE messages the particular IED will publish or subscribe.  The configuration process begins by configuring the IEDs that will only be publishing and subscribing to the least number of GOOSE messages.

From the example, the configuration of relays B, C and D would be done first. Looking at the virtual wiring diagram it is clear that these relays will publish and subscribe to a single GOOSE message. Figure 3 shows examples of the configuration tools used to configure the individual IEDs.

When the IED is configured an ICD or CID file is exported. This same process is repeated until all IEDs of interest have been configured and an ICD or CID file is generated.

If desired, a simple test can be performed to verify that the published GOOSE messages are correct. This can be done by connecting some form of network analyzer and capturing the GOOSE messages on the network.

Some of the details of the GOOSE configuration were left out due to differences in the configuration of the IEDs. For example, in some IEDs the GOOSE messages are going to be published through GGIO (Generic Goose I/O), while others will be published through the protection node such as PDIS or PTOC. This difference can sometimes lead to the GOOSE message being delayed by some fixed time set in the IED. To avoid these problems, it is recommended to read the IED’s manual and see where the IED will publish its high speed GOOSE.

B.  System Configuration  - In order to configure the system, it is necessary to have all ICD or CID files available. The system configuration can be done by a substation configuration tool. This type of tool imports all the ICD or CID files required for the system configuration and will generate an SCD file. Another method is by opening up the configuration tool of the IEDs that will subscribe to a GOOSE message.

For example, the configuration of relay A is done by importing all the ICD or CID files into its configuration tool. The problem is that some of the IED configuration tools may import a *.ICD file, but not a *.CID file. Other IED configuration tools may import the *.CID file, but not the *.ICD file. One possible solution to overcome this challenge is to simply change the file extension to either *.ICD or *.CID whichever is required.

Using the virtual wiring map, the rest of the configuration is performed. Relay A is going to subscribe to three different GOOSE messages coming from relays B, C and D. Relay A will subscribe to the GOOSE message for breaker A position.

When the system is configured, a system verification test should be performed. This test will help identify any problems with the system configuration. The first time a system is configured, some configuration problems may occur. Many of these problems are due to the differences in the configuration of the IEDs. Some of the IEDs require a more manual approach, while others are a bit more automatic.   

C.  System Verification Test -  The system verification test will identify any configuration conflicts in the system. The tools required are going to be a network analyzer (software) and a modern test set that is IEC 61850 compliant. The test set must be able to receive and send GOOSE messages via the substation LAN. This would require the test system to interrogate the network, acquire the right GOOSE message, and stop a timer with minimal effect on time. This is only achieved by the proper algorithm implementation in the test device.

The network analyzer could be part of the test set software or a standalone program. The main purpose of the tool is to help identify all the GOOSE messages in the network. This tool also helps with the configuration of the test set. A test set must know what message or messages it must detect to perform the system test. This can be done two ways; by a direct capture of the messages on the network or by a SCL file import.

One advantage of the direct capture over the SCL import is that when a message is captured it is guaranteed to be there. On the other hand, importing the GOOSE message information from an SCL file does not guarantee that the information is correct.  An example of this is when the system configuration is updated and a new SCL file is generated, but the tester did not receive the new SCL file and is using the old one instead. This could lead to the configuration of the test set with the wrong GOOSE information. It is important to always keep up with the SCL files if the analyzer does not have a direct capture feature.  Figure 5 shows the virtual test connections of the test.

When the test set is configured, the network analyzer is sniffing the network and test connections are completed. Then the test values are applied. Figure 6 shows a typical test connection.

The test values are generated by states simulation of an A phase to ground fault on feeder B. Figure 9 shows the captured analog and digital signals.

From the captured data, it is apparent that the fault was cleared by the upstream breaker not in 166 ms but rather 260 ms after fault inception. This means that the backup relay A did not receive its breaker failure initiate signal. This could be a problem with the system configuration or a problem created during the test. The best method to determine the cause of the problem is by analyzing the data captured from the network analyzer.

The captured data shows all the GOOSE messages that were on the network during the test. Figure 7 shows the captured messages at the beginning of the test. The unbolded text represents the state of that message when it was first captured. If a state change occurs, the messages will appear bold and colored. This can be seen in Figure 8 which displays all the messages at the end of the test. Notice that the feeder B message did not change state which means relay B never tripped and did not send the breaker failure initiate signal to relay A. This event caused relay A to trip on an IOC in 260 ms.

 The data seems to point out that the issue is configuration conflicts with relay B. In this particular case, the problem is due to a wrong IED configuration. As mentioned earlier, some of these problems arise from the differences on how each IED is configured. In the example, relay B employs a more manual configuration process. This means more of the GOOSE data has to be entered manually. If relay B had a more automatic approach then this problem would not have occurred. After some troubleshooting, the problem was found to be the Dataset ID of the subscribed message configured which was not the same as the actual published message. In this case, it is important to keep track of some of the important GOOSE parameters such as GOOSE control name, IED Name, Dataset ID, and others.

After fixing the problem, the test was run again and this time the correct results were acquired. Figure 10 shows how the fault was cleared by the upstream breaker in 178.8 ms after fault inception. System verification is now complete.

Most of the time many of the problems encountered will be test problems. One of these examples has to do with VLAN tagging. Most of the network analyzing tools available that can sniff or capture messages from the network do this through a network card on the PC. Some of the PC’s will strip VLAN tags. This means that if a message is captured and the VLAN tag is removed it is possible for the test set not to detect it. This is due to the network switch filtering out the message which then will not be available on that particular VLAN. These are some of the few problems that can be encountered when performing a system verification test.

D.  Comparing Hardwire to GOOSE - This type of comparison is performed quite often. Since IEC 61850 is in its infant state, people are reluctant to switch over to GOOSE messaging for tripping or even performing control functions. This is why many installations that do have IEC 61850 are also hardwired. These types of installations are constantly comparing the operation of GOOSE to actual hardwire. To date GOOSE has been faster than hardwire. Of course, this time difference has been shown to be a function of relay configuration.

The comparison test is performed in a similar fashion as the verification test. The only difference is the actual test connections. To make the test connections for the hardwire test, look at Figure 5 and all the virtual connections are now replaced with actual wire. Figure 11 shows the required connections for this test.

One of the key benefits of IEC 61850 is the reduction of copper wiring. This can clearly be seen by looking at the connections of Figure 5. Figure 12 shows the total clearing time of the hardwired scheme.

The results above show that an IEC 61850 breaker failure scheme is approximately 4-6 ms faster than a traditional breaker failure scheme.

It is important to remember that these results are not always true. The time depends on system configuration as well as individual IED algorithm implementation. Some of these times can also be affected by the network configuration. A delay can be caused in the Ethernet switch by an improperly set priority tag in the GOOSE message.


Rene Aguilar      

received his B.S. in Electrical Engineering from the University of Texas at Austin. He worked on an Automatic Protection Device Detection System used for detecting coordinating issues between devices in a distributed generation system. He has extensive experience in the testing and commissioning of electrical schemes as well as performing power system studies.

In 2006, he joined Megger as an Application Engineer. He is in charge of the IEC 61850 implementation on the Megger products as well as multi-vendor device applications of IEC 61850. He is a member of the IEEE and an active member of Power System Relaying Committee PSRC.

James Ariza       

(M’03) received his B.S. in Electrical Engineering from Universidad del Valle, Cali, Colombia. He has extensive experience in the testing and commissioning of electrical schemes, performing power system studies and design, and electrical system fieldwork supervision.  Between 2000 and 2005 he worked as field protection engineer and then as project manager at GERS USA.  He has previously worked with EPSA an electric utility in Colombia and Fraunhofer IMBT an R&D technology center in Florida, US. In 2005, James joined Megger, where he has served as an application engineer. He presently holds the title of senior application engineer and he is in charge of relay OEMs account management. He is instructor of hands on seminars covering theory and practical application of IEC 61850. He is a member of the IEEE and an active member of Power System Relaying Committee PSRC.

Relion advanced protection & control.
Protecting your electrical assets? today and tomorrow