Standard Versions and Compatibility

Author:Christoph Brunner, it4power, Switzerland

This needs to be considered on the three key elements of the standard:

  • Communication
  • Data models
  • Configuration language

With regard to the data model, the standard already with the first edition had a namespace concept. Assuming the future tools and devices understand all versions of the standard, in principle, they can always coexist, independent of the changes made. Similar is true for the SCL files where the schema version can be identified. However, from a developer perspective, we try to avoid the need to support old versions of the standard in the future. In part 6 of the standard, some elements supporting that have been introduced with Ed 2.

IEC 61850 is a living standard. New functionality is added and existing ones are being enhanced. While developing IEC 61850, we have to find the balance between extending the standard and the impact on backwards compatibility. So for the standard's developer, it is also important to know, what the users expect with regard to backwards compatibility.

The expectations towards backwards compatibility have been discussed with the users as part of the work in the Task Force “User Feedback” of the IEC TC57 / WG10. The focus was on requirements concerning future revisions of the standard beyond Ed 2, since it was understood that backwards compatibility with Ed 1 may have been a special case since some features supporting backwards compatibility have only been introduced with Ed 2 of IEC 61850.

The main use cases considered were:

  • Replacement of components in existing systems
  • Extensions of existing systems

Impacted may be IEDs and tools and the impact may be a requirement to upgrade them or to reconfigure IEDs in an existing system installation. I will briefly discuss here the use cases related to replacements:

  • The first use case considers the replacement of a failed device with a device from the same vendor, but assuming that the replacement device is only available in a newer version. Here, the users' expectation is that there is no impact at all. That means that the new device can be configured using the existing SCD file and that the communication behavior will be identical

For standards development that means that modifications to communication services need to be backward compatible. With regard to the data model, either the data model can only be extended or it is a requirement on the device development, to be able to support older data models of that device if needed.

With regard to engineering, a tool's need to be able to understand older versions of SCL files or modifications of the SCL schema can only be made as extensions. If for whatever reason, changes (other than extensions) are made to the SCL schema or the data model, this needs to be clearly indicated by the standard and then it may be a requirement for the development of  the devices and the tools to support older versions.

  • The second use case considers the replacement of a failed device with a device from another vendor. Apparently, in that case a new IED tool is required and the SCD file may need to be changed since the data model of the new device is not necessarily identical to the old device. It is considered as acceptable that, in that case, the system configuration tool may need to be upgraded to a newer version, but this shall not have an impact on the other devices. So it is assumed that while a new SCD file is created, the other devices shall not need to be reconfigured and hence, the new SCD file does not need to be loaded in the IED configuration tools of the other devices. The particular requirement, that it shall not have an impact on the other devices means, that if a GOOSE message is sent from that new device, it needs to be possible to configure it so that the structure would be identical to the old one. This requires enough flexibility with regards to the configuration of the new device.

During the last meeting in Canada WG 10 discussed also how to handle mixed systems with Ed 1 and Ed 2. It is assumed that in a mixed system, the system configuration tool shall always support the latest version used in the system. It is as well accepted that, at least for systems with Ed 1 devices, the system configuration tool needs to be able to create a downgraded version of the SCD file. The configuration of mixed Ed 1 / Ed 2 systems will be part of the IEC 61850 interoperability tests that will take place in September this year.   



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. 

Let?s start with organization in protection testing