by Christoph Brunner, it4power, Switzerland
One of the key features of IEC 61850 is the support of an engineering process that allows an exchange of standardized information between various tools. Originally focused to configure the IEC 61850 communication and data model of the devices, the scope of the IEC 61850 engineering process has been extended over time. In this update, I will discuss some topics of the engineering process related to IEDs.
Before I introduce some of the upcoming features, I would like to make a clarification concerning the various SCL (System Configuration Language) file types that apply to IEDs. Apparently, there is sometimes still some confusion. Today, there are three file types defined, that apply to an IED:
- ICD (IED capability description)
- IID (Instantiated IED description) and
- CID (IED configuration description)
While it is mostly understood that the ICD is used for the top-down engineering process, where instances of the IEDs are created based on the ICD file in the system configuration tool (SCT), compared to the bottom-up process, where the instances have been created in the IED configuration tool and imported as IID file in the SCT, the usage of the CID file apparently still creates some confusion.
First, I want to make clear that the use of the CID file is optional. As today, we assume that we need an IED specific configuration tool, the way how the IED configuration is loaded in a device is beyond the scope of the standard. Usage of the CID file is one option, but it can as well be one IED specific binary file that is loaded in the device. If a CID file is available, it may not include the full configuration information, as IED specific configuration may not necessarily be expressed in an SCL file. Sometimes peoples ask, what the difference is between an IID file and a CID file. Well – the standard defines the CID file to contain all the information, an IED needs for its IEC 61850 behavior. So, besides the description of the data model and communication configuration of the IED, the CID as well contains addressing information for IED access points as well as for GOOSE and Sampled value communications. If the IED subscribes to GOOSE messages, it needs to know the configuration of the GOOSE message and the associated dataset. That information can be found in the IED section of the device publishing the GOOSE message and would not be contained in an IID file.
Occasionally I get the question, if it would be possible to browse an IED, create a CID file and then configure with that a new replacement IED. From the previous paragraph, I assume you understand that this is not possible.
Next, let’s have a look at what is coming up soon in the standard. Remaining focused on the IEDs specifics, there are three topics I would like to mention. First, a new file type that will be introduced: The ISD or IED specification description file. That can be used by a utility, to specify the expected capabilities of an IED. It is similar to an ICD file, but it only contains elements that are required. In the service section, it is possible to specify the required services and engineering flexibility, in the data model the required information. The ISD file may as well contain a substation / process section to express the functional requirements. The ISD file will be introduced with the TR IEC 61850-90-30.
The second topic is a process improvement. One of the challenges today is to identify from an ICD file describing the model of a device, which LN instance performs which functionality. As an example, an ICD file may contain multiple LNs PTOC and it may not be obvious which one is used for a regular overcurrent protection and which one for an earth fault protection. There for an enhancement of the process is proposed where a utility may supply an ISD file including a process section that defines functions like earth fault and overcurrent protection. The ICD file supplied by the vendor shall include a mapping of the LNs available in the IED to the process section.
The third topic is related to the description of physical I/Os. New logical nodes will be introduced with the technical report IEC 61850-90-29 to describe the characteristics of physical inputs and outputs of devices. Those will contain information about the electrical characteristics of the I/O as well as identification of the I/Os. Further it will be possible to describe, how those I/Os are connected to the IEC 61850 data model of the device.
Additional extension work is mainly focused on specification and modelling of applications including behavioral description. I mentioned some of them in my last column and may discuss them in more detail in the future. I also would like to mention, that many of those extensions will be prototyped in products this year as part of a proof-of-concept project run by ELIA, the TSO of Belgium.
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.
