IEC 61850 Edition 2 update

Author: Christoph Brunner, UTInnovation, Switzerland

In the mean time, Part 6 and part 7-4 have been published. Part 7-2, 7-3, 8-1 and 9-2 have been finalized by the working group and are now in the process to be published by IEC. It is expected to have part 7-1 as well ready to be published at the end of August. The working group also has drafts of part 1 and 3 ready to be circulated as committee drafts for comment.

Besides that, a draft of the planned technical report about the use of IEC 61850 to transmit synchrophasors according to IEEE C37.118 is ready for a first distribution as document for comments.

The Edition 2 of IEC 61850 is introducing many clarifications and a couple of new features compared to Edition 1. I will pick one or the other of these changes and explain them in my future columns. This time, I will take an example from part 6 – the configuration language. That example is complementary to my column from the last issue.  As I mentioned last time, there exists a lot of confusion about the use of ICD and CID files. As a reminder – a SCL file contains different sections: a substation section, a communication section, multiple IED sections and the data type template section.

The IED section describes basically the data model of the IED, its name and the communication capabilities. The ICD file contains exactly one IED section where the IED name is TEMPLATE; the file shall be used to create instances of the IED by the system configuration tool. Edition 2 has added an explanation that an ICD file must describe an implementable subset of all possibilities of an IED class. That means that for flexible IEDs many different ICD files will exist.

Edition 2 makes as well a clear distinction between the ICD file as a template which can be used for a top down engineering approach or a project specific instance of an IED used for bottom up engineering. For the instance, a new file type – IID (Instantiated IED Description) – has been introduced. With that, clarity has as well been added to the CID file. A CID file is not the same as the IID file. The IID file is an input to the system engineering tool and contains basically one IED section describing a specific IED instance. The CID file is the configuration information for the IED and contains more than just the IED section of that IED. The purpose of the CID file is to include all information from the configuration file that is of relevance for this specific IED. If that IED is supposed to receive a GOOSE message, it needs to know the dataset structure behind the GOOSE message. This is defined in the IED section of the sending device. So the CID file contains not only the own IED section, it may contain as well a restricted view of the source IEDs.

This is an example where clarifications have been added by Edition 2 and new features have been introduced to make the usage of the standard more standardized. There are still some topics where even the experts do not yet agree on the interpretation. A new part 7-5 is planned as a technical report that will provide additional explanations beyond the pure standard specification.

I have been confronted several times with the question, how to model the lockout relay function. This may still be realized in an external lockout relay as an electromechanical solution and would then be out of the scope of IEC 61850. But it may as well be realized as part of the protection relay. In that case, another introduced feature could be of help. Edition 2 introduces a reference to dynamic blocking signals. We may use that signal of the logical node XCBR to point to a "locked-out" signal from the protection relay. That signal could be part of the LN PTRC but it is not yet defined. There may also be other solutions – the locked-out condition could be part of the CILO function for interlocking. Or the trip output of the PTRC could remain active as long as the locked-out condition is true. In order to achieve interoperability, it is important to agree on one solution. These are the kind of topics that may be clarified by the new part 7-5.  

Christoph Brunner graduated as an Electrical Engineer at the Swiss Federal Institute of Technology in 1983. He is President of IT4Power in Zug, Switzerland. Before, he worked as a project manager at ABB Switzerland Ltd in the business area Power Technology Products in Zurich where he was responsible for the communication architecture of the substation automation system. He is Convenor of working group (WG) 10 and member of WG 17, 18 and 19 of IEC TC57. As a member of IEEE-PES and IEEE-SA, he is active in several working groups of the IEEE-PSRC. He is International Advisor to the board of the UCA International Users Group.

BeijingSifang June 2016