IEC 61850 - open to improvements without affecting installed products

Author: Christoph Brunner, it4power, Switzerland

IEC 61850 has grown significantly. New versions of the standard have been developed to address new requirements. Also, clarifications and corrections have been made. This is not possible without making changes to existing definitions. Such changes have an impact on compatibility between versions.
To address the compatibility issues, it was decided to create Annexes to each part of the standard, which I had discussed in the 38 issue of the PAC world. While working on preparing the Annexes, we realized that with a few generic design rules for tools and devices, we can improve compatibility in the future while still being able to improve the models defined by the standard.
So, we decided to create a generic Annex discussing requirements on products to facilitate compatibility between versions, and giving as well guidelines to editors of the standard on how to make extensions, or modifications to the models. The preparation of that generic Annex, which will go into part 7-1, consumed some time. A draft has been finished in early May and is currently reviewed by the WG10.

This Annex identifies all possible use cases of changes in the IEC 61850 model - both the semantic data model and the control blocks. It then discusses the impact from the perspective of the information user regarding forwards as well as backwards compatibility and provides design rules where needed. Information consumers are clients for MMS messages, subscribers for GOOSE and sampled values, system tools and IED tools of information users. Forward compatibility of an information user is defined as the ability to understand information from an information provider that is based on a newer version.
Examples of use cases discussed are “adding a new DA of an existing basic type to a CDC” or “make a presence condition stronger” (e.g. change an attribute from optional to mandatory. The use cases are described to be applicable to parts 7-2, 7-3 and 7-4 as well as all parts defining logical nodes.

As an example, the use case “make a presence condition stronger” applies to both 7-3 (DA, Sub DA and Sub DO) as well as 7-4 (DO). That particular use case is obviously forward compatible, as e.g. a client will expect that the element may be there. To make it backwards compatible, a general compatibility rule has been defined, that information users shall be tolerant for missing elements; i.e. a client that would expect an element to be there as mandatory shall be tolerant if it is not there.  Another compatibility rule defined requires a system tool to be tolerant, if e.g. a configuration attribute (FC = CF) it expects and would like to configure, is not there. However, it may issue a warning to the user of the tool.
In some cases, specific compatibility rules need to be defined on the particular instance of a use case. As an example, the use case “Extend a CDC with elements of existing types and functional constraints” requires a specific compatibility rule for backwards compatibility for clients, if a DA has been added as mandatory. These specific rules are given per instance in the compatibility Annex of the particular part of the standard.

For the above use case, the DA “maxPts” has been added to a couple of CDC’s that are array based. The specific compatibility rule says, that if maxPts is missing, the client has to use the value of the attribute “numPts” to define the size of the array.

Besides the annex with the generic rules, each part (7-2, 7-3, 7-4) will have a dedicated annex where all changes are listed per use case for all previous versions (i.e., part 7-3 lists all CDCs that have been added per version) and where the specific compatibility rules are listed for all versions. So, for developing a device or tool according to the latest version, it is sufficient to implement the generic compatibility rules as defined in the Annex of part 7-1 together with the specific compatibility rules defined in the particular annex. The implementer does not need to know previous versions of the standard.  Everything that is relevant for implementation is listed in the Annex of the latest version.

There are a few cases, where compatibility is not achievable, mainly related to control blocks and services. Regarding the data model, forward compatibility is not achievable if new basic types are introduced - this needs to be handled by the system integrator e.g. by configuring GOOSE messages to be sent to old subscribers without elements based on these new types. As all cases are listed in the part specific Annexes, this can be handled. Finally, as recommendation for future standardization work, several use cases have been identified, that shall be forbidden in the future. As an example, the type of a DA shall not be changed - we would rather introduce a new DA (with a new name) and deprecate the old one.
Of course, all this is valid only from Ed 2.1 forward. Devices and tools compliant to Ed 2.1 will be compatible with other versions within the limits explained in the Annex of part 7-1. Also, it has to be noted that all these discussions are related to the model version, and not to the version of the SCL. Those are completely independent. 


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 TC57. He is senior member of IEEE-PES and IEEE-SA. He is an IEEE Fellow and he is active in several working groups of the IEEE-PSRC and a member of the PSRC main committee and the subcommittee H. He is international advisor to the board of the UCA international users group. 

Relion advanced protection & control.
Protecting your electrical assets? today and tomorrow