by Christoph Brunner, it4power, Switzerland
One of the goals of IEC 61850 is to achieve interoperability between devices and tools of different manufacturers. But what does Interoperability mean? The glossary IEC 61850-2 defines interoperability as: “ability of two or more IEDs from the same vendor, or different vendors, to exchange information and use that information for correct execution of specified functions.”
When we first started to create IEC 61850, the initial focus was to standardize the communication such that IEDs from different vendors would be able to exchange information. That is what is defined in the parts 7-2 and 8-1 / 9-2 – communication services that can exchange any kind of information without discussing the details of the information. Interoperability in that case means that one IED can receive information sent by another IED. The interpretation of the information is out of the scope of that part of the standard.
But when we further developed IEC 61850, the scope was extended beyond the communication. We also defined the structure and the semantic meaning of the information. This is in part 7-3 and 7-4 – the data structures (Common Data Classes) and the Logical Nodes. Interoperability in that case means that a receiver of information understands the semantics of that information.
Finally, we as well added an engineering framework to the standard: the SCL – system configuration language. This does not only include the format of configuration files exchanged between tools, but it also includes a description of the intended engineering process. Interoperability does not apply mainly to IEDs, it now applies to configuration tools. An IED configuration tool (ICT) shall be able to configure the IED based on the SCD file it receives from the system configuration tool (SCT). Or an SCT shall be able to configure a system using IEDs based on the ICD file that describes the capabilities of the device.
While we have a formalized process to perform conformance testing for the communication and to some level as well for the tools, we do not have something for the semantic data model.
About 10 years ago, UCA International Users Group started to organize interoperability testing (IOP). At that event, vendors bring their tools and IEDs and perform interoperability tests with other vendors witnessed by experts from consultants or utilities. For such an event, up to 100 or more experts from vendors, utilities and consultants come together for a full week of testing and additionally a few days before the testing of setting up the test environment.
An IOP takes place every two years. Initially the focus was on testing communication interoperability and interoperability between the engineering tools. The goal of the IOP is, to detect issues that then helps to improve the quality of the standard. Additionally, the tests also address new features of the standard, that are not yet widely used – again to improve the quality of the standard in an early stage of the implementation.
While the interoperability related to the communication was already initially quite good, there were a lot of issues with the tools. So many of the modifications in the Ed 2.1 of the standard were driven by issues detected at the IOP.
Since the IOP in 2017, we configure the devices such that they realize an integrated application which is basically a substation with two voltage levels and some protection and control schemes. This allows as well to do interoperability testing of the semantic data model, which is something that is not done elsewhere. In 2017, the main issues where to create the integrated application using the IEC 61850 top-down engineering process. At that time, that was not yet widely used in real projects.
Also, we detected, that the quality of the icd files was rather low and as a result also the scd file that was built using those icd files. Therefore, we started to use various verification tools that are checking the SCL files beyond the schema validation. In the standardization, we launched new work to describe the rules behind the part 6 in a language that tools can use to check the file against the rules (OCL – Object Constraint Language). Rise Clipse – an open source initiative – defined an initial set of rules and an engine to apply those rules to check SCL files. For the last IOP which took place this July in Milano, every icd file was checked by various tools, including rise clips. As a result, we not only had better quality in the SCL files, but we also could improve the set of OCL rules for the standard.
At this year’s IOP, we had a large focus on functional testing of the integrated application. Already during the design, we detected a couple of issues related to the semantic data model – different interpretations and different views on how to model an application. During the testing itself, we could successfully run a series of functional tests. The tests included maintenance testing – virtual isolation using the elements defined in IEC 61850. The lessons learned during the IOP 2022 will hopefully lead to improving interoperability regarding the data model.
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.
