by Christoph Brunner, it4power, Switzerland
Before a system design starts, we need to consider not only the functional requirements but the test requirements as well.
With IEC 61850, we have the possibility to realize fully digital substations. Instead of using many wires between the devices, those systems rely on communication. This requires some changes in the tools and method to test the system.
Something that does not change, is the fact that the system needs to be designed to be testable. In a conventional system this was a standard practice. Where to place test switches and test plugs needed to be planned already during the design phase. With digital substations, this is even more important. However, the methods are different.
At the start of a system design we shall not only consider the functional requirements, but the test requirements as well. How shall the system be tested before it is put in operation? What maintenance tests are required? Do we need to do routine testing in a live substation? What are the procedures to test a system upgrade? The tests needed for a replacement of a failed device.
The first concern is the observability of the system. In a conventional system, we may have test plugs, where we can connect equipment like a logic analyzer and analyze the signal. In a fully digital system, the signal is part of a GOOSE message. With higher integration of functions, some signals may only be internal in the IED. The first question to answer is therefore:
- What signals do I need to be able to observe to test the system?
- The second question is – how can I observe those signals?
As an answer to the second question, we typically have GOOSE and sampled value messages, reporting or polling. Which one to use, depends on the test and the test equipment. If a test equipment needs to react on a signal from the IED; e.g. if a test equipment injects a fault and needs to react on the trip signal, to take the fault away, then a GOOSE message will be used. If a test equipment is passive, and only displaying or recording the values of the signals, it is important to capture the timing, so in that case reporting may be the better choice.
Those reports and GOOSE messages required to observe test results need to be predefined in the system configuration. This means, there may be dedicated GOOSE messages, that are only activated by the test equipment. Regarding reporting, it is wise to configure besides the reports used for the communication to the gateway or the local HMI an additional report that can be used by a test equipment. Alternately, if dynamic configuration of datasets and report control blocks is supported, the test equipment may create a report.
The second concern is the virtual isolation, if tests are performed in a live system. For that, test bit and test mode have been introduced. In Ed 2.1, the usage of those has been clarified. A part of an IED that is in test mode will send out all information with the test flag set to TRUE in the quality. With the mode test/blocked it is prevented that the IED issues a physical output signal (e.g. a trip to a breaker).
The third concern is the differentiation between messages from test equipment and the real messages. For that, the simulation flag has been introduced in the GOOSE and SV message and a device can be set to receive simulated instead of regular messages. I have explained in more details how test mode and the simulation flag work in the column from the September 2018 issue.
For tests in live systems, it is important that already during the design phase, you know how you will perform those tests. Do you plan to do partial testing – one part of a device will be tested, and the other part remains in operation? As you can only receive for a given GOOSE message either the simulated one or the real one, this needs to be considered during the design as in that case, information to be received by the part in test cannot be in the same GOOSE message with information that has to be received by the part in normal operation. Also, you may need to know, if you set an IED in test mode with a button on the front panel or if you want to send a command to the IED to change the mode. This creates requirements on the IEDs.
And this brings me to my last point – the test tools. To do testing in a live system, devices need to be put in test mode, simulated messages need to be put on the network and received – all this requires a step of actions. A test tool should allow you to program sequences to set your IEDs in the right mode before you start the test as well as to set it back to normal operation. And it will allow you to visualize not only the test results, but lso to visualize the LN mode and behavior as well as GOOSE message subscription. With the LN LGOS, it is not only possible to monitor the status of the subscription, it is also possible to see, if a normal or a simulate GOOSE message is currently subscribed.
I have now talked a lot about live testing – of course testing is also important, to verify that the system behaves as specified before going into operation. Also, for those system tests (FAT/SAT) it is important, that the right information is available for test tools to monitor the correct operation. While system testing is done with the IEDs in normal mode, it is important that you also test your scenarios for live testing during FAT and SAT.
To summarize – it is important to include the staff from the utility that is responsible for the maintenance of the substations already in the design phase. If you follow those recommendations, you should not have any surprises with your fully digital substation.
Christoph Brunner is the President of his own independent consulting company it4power LLC based in Switzerland. He has over 25 years of experience with knowledge across several areas within the Utility Industry and of technologies from the Automation Industry. He has worked as a project manager at ABB Switzerland Ltd in the area of Power Technology Products in Zurich / Switzerland where he was responsible for the process close communication architecture of the automation system. He is Convener of WG 10 of the IEC TC57 and is a member of WG 17, 18 and 19 of IEC TC 57. He is member of IEEE-PES and IEEE-SA. He is an IEEE Fellow and is active in several working groups of the IEEE-PSRC and a member of the PSRC main committee and the subcommittee H. He is advisor to the board of the UCA international users’ group.