Testing of Intelligent Electronic Device (IED) in a digital substation

This study reports on experience gained during factory testing on a pilot project digital substation. Testing IEDs in a digital substation is dependent on how test and simulation functionality as defined by the IEC61850 is implemented by the vendors, and also requires a different approach to testing compared to testing on a conventional station. This study highlights limitations imposed on testing due to missing IED test facilities, as well as the need for the end customer to fully specify IED functionality to ensure vendor interoperability.


Introduction
Statnett has started an R&D project, Digital Substation pilot, in cooperation with Jacobsen Elektro. The intention is to gain experiences with process bus (PB) installations and nonconventional instrument transformers. The pilot will investigate the benefits this technology offers for future substation projects. The use of PB instead of hardwired connection to the primary bay introduces the possibility for new design of the control and protection in a substation.
Today's philosophy for transmission systems where protection and control is in separate hardware is challenged by a more compact hardware design. The Digital Substation pilot includes protection and control for two 300 kV transmission lines in the same IED hardware. The PB-based digital substation automation system (DSAS) was installed in a live 300 kV line bay in parallel with an already existing substation automation systems (SAS) in September 2017. This paper will discuss aspects related to testing of the IED that includes protection and control for two transmission bays. The traditional hardwired test plug will not fulfil the requirements for the new design. Instead, the IEC 61850 [1] offers a range of testing facilities that are investigated in this project. Ideally, it should be possible to test the protection functions for the different bays independently during all stages of testing.
One of the points that will be discussed in this paper is how different vendors have implemented the test features and consequences thereof. This paper will also discuss some benefits and limitations related to testing that is discovered so far in the R&D project, as well as a different approach to testing required by the IEC 61850.
In this paper the term 'test mode' refers to sending/receiving GOOSE with q-bit test = TRUE, whereas 'simulation mode' refers to sending/receiving sampled values with simulation flag = TRUE.

Pilot substation topology
Normally Statnett uses two main protections for a 300 kV bay, but in the pilot project this has been doubled to open up for investigations into the interoperability between protection and control equipment from different vendors. There are IEDs from three vendors -ABB, Siemens, and Sprecher -in addition to merging units (MUs) from Arteche.
In this project, the approach has been to combine many functions in a restricted number of IEDs. Both the control functionality and distance protection 1 for two separate line bays are included in one protection and control unit (PCU1), whereas PCU2 contains back-up control and distance protection 2 for the same two bays. Additionally PCU3 is used for distance protections 3 for the two lines, and PCU4 for the distance protection 4 for Line 1.
The main challenge for the digital substation concept is to make the whole system reliable enough to fulfil the requirement on availability as we have today. In the pilot project, this is realised with PB based on parallel redundancy protocol network redundancy technology, as shown in Fig. 1 below.
Redundancy for tripping and operation of the breaker is ensured by two station control units (SCUs). With the exception of the trip commands, which always are sent to both SCUs, PCU1 and PCU3 rely on SCU1 for operation and indications, whereas PCU2 and PCU4 rely on SCU2.
Time synchronisation is an essential aspect of PB applications and the system is synchronised from two time sources, GPS1 and GPS2, using the precision time protocol (PTP) v2 to ensure 1 µs accuracy. (The PTP is strictly speaking not according to the IEC61850-9-2LE standard profile which was specified in the tender.) The sampled values (SV) streams from the merging units (MUs) (MU/stand-alone merging units (SAMU)) are currents and voltages measured on the real transmission line and bus bar, but the SCUs are operating only on a process simulator. SV streams according to IEC61850-9-2LE with 80 samples per cycle (F4000S1I4U4) are used for metering, protection and control functions.
An important issue is the SV streams for the protection. As the distance protection relies on both current and voltage to operate, it is essential that these values have the same time stamp for the relay to operate. In this project, the SV streams contain both current and voltage emerging from the same source (MU or SAMU), so this timing is not an issue. However, other solutions may have separate MUs for current and voltage, in which case a drift in time on one of the units will cause the protection to be blocked.
In this project, Lines 1 and 2 are in reality the same line. With both an optical and a conventional current transformer measuring on the same, real transmission line, it is possible to see if there is a difference in protection response to the two measuring methods. Therefore the different PCU's were configured to use SV streams as shown in Table 1.
Not shown in Fig. 1 is the station LAN. This is used for exchange of GOOSE messages that are not time critical, e.g. interlock criteria, and reporting to the dispatch centre via a Gateway.

IEC61850 structure
Combining control and protection functionality for several lines into the same IED makes it necessary to consider aspects related to IEC61850 structure and testability. It is, for instance, useful to be able to test an IED for one of the lines without affecting the operation of the other line, or even to test the protection for one line without affecting the bay controller functionality.
As a result, in the functional design specification phase it was agreed to define the bay controller and protection functionalities of the PCUs as independent and separate logical devices for each of the two lines. Each of these logical devices would contain a number of control or protection functions (the logical nodes). Sync check and auto recloser functionality were defined as being part of the bay controller logical device (LD). Fig. 2 shows a simplified view of the structure.
With the specified structure, one should also be able to test interoperability between vendors quite easily, using test flags and simulated values. For instance, an on-line test could be performed to verify the interaction of Line 1 Protection 3 with the AR functionality in Line 1 BCU1. During this test, it could also be verified that the trip and reclose signals reached SCU1. This particular test, being an interoperability test with equipment from three vendors, would require that the LDs used in the test all be set to test and simulation mode, so as not to influence the remaining devices in the system.
However, in workshops with the vendors it soon became clear that it was not possible to obtain the IEC structure aimed for, and hence not the functional independency, nor was the desired test and simulation functionality implemented by all.
Firstly, three IED vendors had three different implementations of the test and simulation modes. One of the vendors did not support simulated sampled value streams, another vendor did not process GOOSE transmissions with the quality bit test = TRUE, while the third vendor supported both simulated SV streams and test flags.
Especially, the lack of support for simulated SV streams poses a challenge when testing on a live station. The IED cannot be tested on the PB with SV without the simulation flag set, as other IEDs also would see the SV as real and react accordingly. Hence, the IED must be disconnected from the PB, and a separate SV stream applied directly to the IED. This of course makes testing interaction with other IEDs depending on the same SV stream difficult.
The inability to process GOOSE transmission with the quality bit test = TRUE is also a significant problem which makes it impossible to use this IED while testing in an energised substation.
Secondly the level of independence varied. With the IED from one vendor, it was possible to put Line 1 in test mode without affecting Line 2. With the IEDs from the other vendors one was only able to put the whole physical device in test/simulation mode. (Alternatively one could put each and every function of a LD into test mode individually. The latter of course is not practical as it involves a large number of operations and is very time consuming and error prone.) However, none of the vendors were able to separate protection and control functionality.
It should be mentioned that during the engineering and implementation phases all vendors involved did make adjustments to their implementation in order to improve performance and/or interoperability.

Test equipment and set-up
For testing the protection relays in the digital station Omicron test sets with GOOSE and SV were used, running Test Universe software v3.10, with an upgrade to v3.20 during factory testing.
Fault finding is normally a part of factory testing, and testing a digital station is no different in this respect. However, the tools required for troubleshooting in a digital station are different. It is not like in a conventional station where you can connect a voltmeter and measure if the voltage reaches the correct terminal. Special software tools are needed to sniff on the PB to see the GOOSE signals and SV values, and generally to check what happens in the system when it does not respond in the expected manner.
This requires the test person to become familiar with the use of several programs. In this project Wireshark, IED scout, and SV scout were extensively used, in addition to vendor-specific tools from ABB, Siemens, Sprecher and Arteche.
The MU used in the project has the option of using analogue current measurement instead of the optical CT, so for test purposes also analogue currents were connected to the MU. This means that both SAMU and MU were wired to current terminals, and the Omicron could be used to inject analogue values, and the IEDs on the PB would see the SV streams coming from the MU and SAMU exactly as it would appear on site. As an additional benefit the normal test files could be used for testing the relays.
If the MU did not have the opportunity for using analogue currents, it would not have been possible to test the relays in the factory with SV streams coming from the actual MU. Generally speaking, comprehensive factory testing of a digital station require all IEDs, MUs, SAMUs, and SCUs set up in the factory.
The project team had no previous experience in using GOOSE response on the PB to interact with the test set instead of binary inputs and outputs, so some time and effort was spent on setting up  the test files. A point to make in this regards is that in a conventional station the same test file can be used on several relays, all that is required is to reconnect the wires, but in the digital station the GOOSE configuration in the test files have to be changed as the IEDs have different names. Long experience in testing on conventional stations had not fully prepared the team for testing on a digital station, and some valuable lessons were quickly learnt

Normal mode testing in the factory
Most of the testing in the factory was done in normal mode, mostly to ensure that the system actually worked like it should, but also because the test features according to the standard were not implemented by all vendors and using test mode was not very practical.
Very soon it was discovered that using test device to simulate a signal in normal mode that already exists in the station results in problems. For example, consider a signal like 'single pole trip permitted'. This is sent from the active BCU with the state being either TRUE or FALSE. If this signal is also simulated by Omicron there are two GOOSE signals in the station with the same or with contradictory states, and this will 'confuse' the relays.
The relays in the pilot did not except the same signal from two devices, nor were they prepared to deal with contradictory states of a signal. For testing, the criteria for the signal 'single pole trip permitted' had to be set in the 'real' system (process simulator) for the relays to get the correct input for the test. The alternative is to make the real device inactive on the system and use simulated signal.
In a conventional system two people can test two protections on the same line at the same time, since they are on different current circuits and/or have test plugs mounted. However, testing on a digital station in normal mode and injecting analogue values via terminals to the MU/SAMU makes it difficult for more than one person to test at the time. All the devices using values from the unit that gets the injected values will react to the SV stream.
In order to verify the correct response of a relay under test, all other relays using the same SV stream had to be turned off. Otherwise it was not possible to verify that the breaker was actually tripped by the relay under test.
What came more as a surprise -and caused some headacheswas that after a test was completed, and even after the test file on the PC was closed, the test equipment still sent out GOOSE and SV streams on the network. To make the Omicron stop transmitting the test set has to be turned off.
The reason for this behaviour is that when applying the GOOSE or SV configuration to the test device, it becomes a virtual IED that keeps sending GOOSE messages without interruption while running a complete test plan and properly updating the state and sequence numbers in the GOOSE messages the same way a real IED does.
Once these lessons were learnt -do not simulate GOOSE or SV in normal mode if the real IED is active, do not test more than one IED at the time, and turn off the test set after test is completedtesting in normal mode was not all that challenging. However, for coming projects some test preparations will need to be engineered at an early stage.

Planning for test signals
In a conventional control system, it is almost always possible to connect a volt meter to a terminal to measure the response of the system to a certain event, even if this particular signal was not planned to be tested from the start of the project. It is also possible to inject a signal at a terminal in order to initiate a system response. Such terminals are often helpful in the testing procedure although they were not planned as test terminals in the engineering phase.
Some terminals are planned and laid out especially for testing, and a similar approach must be used in a digital substation. One cannot access or inject a GOOSE signal during testing if this is not already set up in the system, so it has to be planned on from the start.
It is therefore essential in the early phase of a project to define GOOSE for testing on the PB. Setting up a dedicated test data set, rather than using data points from several data sets, will simplify the process of preparing the test equipment.
Also, the IEDs could be prepared to receive such test signals. Signals could for instance be 'Overcurrent Start' sent from the IED when testing the starting threshold of a protection device, or the command 'Manual close' sent from the test equipment to the IED for testing switch on to fault (SOTF) response of a protection relay.

Time synchronisation of SV streams
When testing with SV streams from the Omicron it is of critical importance that the values are time synchronised correctly. This is done by selecting the correct time source in the global hardware configuration of the test set. PTPv2 is used on the PB so the Omicron just had to be configured with correct profile, virtual local area network identifier (VLAN ID) and priority. Before starting the test it is important to give the test set time to actually lock itself onto the time source, so that values are time stamped correctly.
As previously mentioned one of the vendors did not support simulated SV values. That meant the test set had to be connected directly to the device, so as not to interfere with other IEDs, and the SV must be sent in normal mode. In doing so it was discovered that the test device sent out the time stamp with local Synchronisation Mode smpSynch :local (1).
However, this particular vendor did not support local synchronisation mode, but had to have global synchronisation mode, i.e. smpSynch :global (2). With the version of Omicron Test Universe available at the time this was not possible. Only after Omicron released a new version 3.20, in which was implemented a feature for forcing the Omicron to send smpSynch with global(2), could the test be performed.
Note that when forcing the global synchronisation mode on the SV streams, the Omicron does not use the time from the PTPv2, thus the injected SV stream can have a time stamp which deviates from the internal clock in the IED, which of course is time synched from the GPS clock. For another vendor this deviation caused the SV stream to be rejected.
The conclusion is that the response of IEDs may differ between vendors, also on issues related to time synchronisation.

Trip times
An improvement in response and trip times in the digital station was assumed, but it was not found to be as significant as expected.
When comparing trip times measured on terminals in the relay cubicle in a conventional station with the time it takes for the GOOSE trip signal to appear on the PB, a typical case is listed in Table 2.
Typically, the trip time was found to be 5-10 ms shorter in the 'fast' zones (normally zones 1-3), but in some cases the trip times were found to be the same as in the conventional station. For zones with longer trip times there was in effect no difference observed in the trip times.
It should be pointed out that the relays used for this comparison were not 100% identical. Newer firmware and hardware releases were used on the digital station.
The SCU processing time will come in addition to the times shown in Table 2 to make up the total trip time in the digital station. The SCUs in this pilot project had a processing time in the range of 2 ms, but this will vary between vendors.

Connection of the neutral current on SAMU
In a conventional station Main 1 and Main 2 protection relays use different cores of the current transformers, but in the digital station the SV stream from the SAMU will replace both of these cores. In the pilot project, this actually caused some problems related to the directionality of the distance protections.
Initially, two of the vendors used the value of neutral current (I N ) coming in the SAMU SV stream for the distance protection function. Invariably one relay saw the fault in the forward direction, while the other relay saw the fault in the reverse.
Swapping the terminals of I N on the SAMU, i.e. reversing the direction of I N , led to the opposite response.
The same effect was also observed when using SV from the Omicron -the two relays would not agree on the direction of the fault. Seemingly the two vendors have opposite definition on the direction of I N , and consequently the relays will disagree as long as the measured value comes from the same source.
For the pilot station, the solution was for all protections using the SV from the SAMU to use the calculated value of I N instead of the measured one. As the optical current transformer does not have a neutral current, the problem is not applicable to the MU SV stream.

Benefits
The IEC61850 PB offers some benefits with regards to testing. The main one is that there are no current circuits in the secondary control and protection system, and consequently the risks for open current circuits and potential staff injuries are greatly reduced.
Another characteristic that is sometimes brought forward as a benefit is the possibility of maintenance testing of IEDs from a remote location. This would -apart from requiring test equipment being permanently connected to the PB -also require that all devices have fully implemented the simulation and test modes of the standard so that no physical reconnections are necessary. Thus for the pilot project, remote testing was not possible.

Conclusions
This paper has reported on experiences from testing protection relays in a multivendor digital substation and some challenges encountered in this pilot project. The differences in vendor implementation of test and simulation mode led to the main bulk of testing being done in normal operation mode and also limited the project from thoroughly evaluating the test and simulation mode facilities of the IEC 61850 standard.
Examples have also been given on how the response of IEDs to everything from neutral current connection on the SAMU to the time synchronisation mode will differ depending on vendor. Hence, the end user should take great care in defining also the IED functionality in order to ensure vendor interoperability. This would require utility and vendors to work closely together.
Another point of importance is the testability of the control and protection system. Carefully planning for GOOSE data points for test in the early phase of a project can both ensure testability as well as simplify preparations for later maintenance testing.
To specify, test, and operate a fully digital substation there is obviously a need for close cooperation between experts in the fields of networking, protection, and control.
The main lesson to be learned is that in order to take full advantage of the potential in the IEC61850 standard, the user should specify for all vendors that the full test and simulation functionality must be implemented. It can easily be argued that the implementation of these should become mandatory in the IEC61850 standard.