by Christoph Brunner, it4power, Switzerland
A focus is laid on the latest features in the standard to enhance the maturity of the specifications. During the IOP, based on test specifications that are prepared beforehand, vendors perform tests witnessed by IOP participants from utilities or consultants. The goal of the IOP is not to pass or fail a test; the goal is to identify issues, that may lead to a failure of a test and that need to be better specified in the standard. It is not unusual that already during the preparation of the test specifications, issues are identified.
When we did the first IOP in 2011, the focus was on communication interoperability. Devices exchanged GOOSE messages or reports. Later, the focus shifted to interoperability between engineering tools for the top-down engineering process. Other topics included accurate time synchronization with the PTP profiles or exchange of routable GOOSE. Issues found during an IOP are classified and may result in improving the specification or improving the conformance test procedures. All that helped to improve the quality of the specifications as well as of the products.
In the recent years, the focus shifted to do functional testing. In 2017 we designed for the first time a layout of a hypothetical substation, where each participating device got its role depending on its capabilities. This allowed us, to do functional testing. We learned a lot out of that. First – the quality of the icd files was bad – they included many errors which affected of course the system configuration file. As a result, we decided that there is a need to verify SCL files beyond schema compliance what resulted ultimately in the work now done as IEC 61850-6-3 – to define a method to specify machine processable rules (in OCL) that can be used to verify SCL files.
Second, we also realized, that there are many ways to apply IEC 61850 to model applications. And many devices still used private ways of modeling instead of what is available from the standard. This resulted in a huge effort to engineer our hypothetical substation, as the same application needed a different implementation from one bay to the other, depending on the IEDs allocated to the bay. Also, as the devices were pre allocated to a bay, if one device had troubles, the other devices interacting with that device could not perform tests, until the issues on the first device were fixed.
That’s why we decided for the IOP 2024, to do a step back. Instead of designing one large substation, we design typical bays with typical IED roles allocated to the bays. As an example, a line bay has a line protection (LPU), a bay control unit (BCU) and a process interface unit (PIU – a combination of a merging unit and a switch control unit). For the functional tests, we do applications like line protection, reclosing, control with synchrocheck or breaker fail. The test scenario is then one bay, with possible inclusion of devices from the neighbor bays (e.g. for breaker failure protection). To perform the tests, any combination of devices from different vendors depending on their functionalities is possible.
For the test scenario, we will define a set of tests based on the selected applications. Test will as well include cases for testing a device in an active environment, where virtual isolation is required (e.g. for routine testing).
To enable the engineering of such a system in short term, we use a top-down approach with virtual IEDs, and request, that all participants agree on how to implement an application. For that, we are using the concept of basic application profiles (BAP), as introduced in IEC 61850-7-6. We are defining BAPs for the applications we want to test. The functions within a BAP are then allocated to the devices. Through the BAP, it is clearly defined, what signals a device, that implements a specific function from a BAP, must produce or consume. During the preparation of the BAPs, we already identified some areas, where more clarifications from the standard is desired on how exactly to model. This will be handled by the WG10.
For the design, we then can prepare an SSD file specifying all the functions (Logical Nodes) and their signals. For the implementation, we then need to map the logical nodes on the specific instances in the IED we are using and map the input signals on ExtRefs provided by the IED in case of later binding.
So far, we are not enforcing the latest developments from IEC 61850-90-30 which would allow to specify signal flow in an SSD and to support a process ICD that provides the LN and signal mapping in electronic format. The mapping needs to be provided by the participating vendor in an Excel table. Also, we are defining the BAPs only as text document; we are not using the SCL representation that is drafted for Ed 2 of part 7-6. That may be the scope of the next IOP.
As we want to do multiple tests in parallel, we need for the IOP a network infrastructure supporting multiple independent networks. As part of the IOP, we are as well planning to configure the network (Multicast filtering or VLANs, etc) based on the SCD file. I will provide a more technical discussion on the BAPs developed, the way how multiple BAPs are applied to a project, the test cases and on the issues found in a technical paper presented at the PAC world conference 2024 in Athens.
Biography:
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.
