by Christoph Brunner, it4power, Switzerland
A key benefit of IEC 61850 is the integration of the engineering process in the standard. The possibility to use one single tool to design a multivendor system with all interactions between the devices facilitates system integration.
Also, the possibility to specify a system formally offers new possibilities in the procurement process including simulation of the specification and tool-supported validation of submitted proposals.
However, to have that working, it is crucial that the devices and the associated tools and SCL (System Configuration Language) files comply with the latest version of the standards. Thanks to various initiatives, including the IOP (Interoperability Testing), we learned where to improve the specifications to ensure interoperability and ease of integration. This has been incorporated in the first amendment of Edition 2 (what is also called Edition 2.1).
So, there was a good reason to produce this Edition 2.1. Devices and Tools not supporting Edition 2.1 should not be on the market anymore, as apparently, they are not state-of-the-art.
The test setups for functional testing done at the IOP24 were all designed using a top-down approach. We used system configuration tools (SCT) from various vendors participating at the IOP to design the multivendor systems. As IEC 61850 does not standardize products, a device vendor has some flexibility in how to implement IEC 61850. Nevertheless, that flexibility needs to stay within the rules defined by the standard. For a SCT, it is important to understand what an IED supports and what it does not support. As an example, the SCT needs to know how many report control blocks may be configured in an IED and what number of entries may be in a dataset. In some cases, the SCT may not even be allowed to configure control blocks and must use the ones predefined in the IED. That kind of information is available in the “service element” of the IED in an ICD file.
As the name implies, that element was originally mainly used to indicate which communication services are supported by an IED as a server and to some extent, what constraints exist in e.g. the size of the dataset. Many of additional constraints were in Edition 1 of the standard only documented in the so-called PICS (Protocol Implementation Conformance Statement), a paper document not usable by tools. With Edition 2 and 2.1, the service element has significantly been expanded to include everything that was before only defined in PICS and much more. It not only describes the capabilities of a server and publisher; it also can be used to declare the capabilities of a client or a subscriber.
During the preparation of the IOP24, we had to notice that many of the icd files submitted by the various vendors had incomplete or incorrect service elements. This created problems for system integration, as the system tools were not able to understand what they are allowed to do with a device. Here there is room for improvement – the UCA test committee should improve conformance testing in that area.
An example of something that did not exist in Edition 1 and was only marginally defined in Edition 2 is the element ClientServices. This element defines, what service classes a device can subscribe to or can receive as a client. This element has attributes like e.g. “goose,” which indicates, that the device can subscribe to GOOSE messages. Most of these attributes, if missing, have a default value, which is typically “false.” This means that, in case an icd file is published as Ed 2.1 file, but the file has not been updated, an SCT will assume the default values and may complain that it cannot configure the device to subscribe to a GOOSE message.
Another aspect in an SCL file that needs to be looked at carefully, is the declaration of values for parameters or configuration attributes. In the IED data model of an SCL file, it is possible to add instance data and configure values using the “val” element. The way in which such a value must be interpreted, depends on the context of the SCL file (icd, ssd or scd file) and the value of the attribute valKind. As an example, a valKind=RO means, that a value can only be set at configuration time. However, as an SCT, you cannot assume that you can preconfigure any values as you wish. Initially, it was assumed that those values are predefined by the IED and could not necessarily be changed by the SCT.
Only with Edition 2, the additional attribute valImport was introduced to indicate that the IED configuration tool would import a preconfigured value from an SCL file. A very special case is when valKind is set to “Conf.” This means, that the value of a parameter of configurator attribute is provided in the SCL file, but the attribute with the value is not visible in the data model of the device exposed over the communication. That may have had some justification in an early stage of IEC 61850, when existing IEDs were upgraded to support IEC 61850. I would not expect that case still to exist with the latest IEDs – unfortunately however, we still see those at the IOP – whether intended or unintended, I do not know.
As we see, an SCL file contains much more information than just the configuration of control blocks and communication parameters. The whole framework around SCL has been defined to support a design process, where all information is available in machine processable format. But the success of that depends on products and tools that have been designed to support it. Integrators and utilities need to describe the processes they want to use; the standard shall support them. Product designers finally need to understand them and make the products compliant.
The interoperability testing (IOP) organized by the UCA users’ group is there, to identify gaps. And we need to understand that, if gaps are detected, this will lead to a new revision of the standard which needs to be supported by products. The good news is, that since Edition 2.1, rules are in place for both standard specification as well as product design, such that coexistence of products supporting different versions of the standard is possible.
Biography:
Christoph Brunner is the President of his own independent consulting company it4power LLC based in Switzerland. He has over 40 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.
