by Christoph Brunner, it4power, Switzerland
As the usage of IEC 61850 is growing and new functionality is added to the standard, the standard documents are undergoing changes which result in new Editions or new Amendments.
Those changes apply in principle independently to each part of the standard. For the core parts we had so far, an Edition 1, an Edition 2 and a first Amendment to Edition 2 (which was published as well as a consolidated version Edition 2.1).
From a user perspective, it is important to understand, how the new versions of the standard will affect your projects. From a vendor perspective, it is important to know, what you must do. One of the key questions is: what happens, if a product (device and tool) of a newer version is added to an existing system that was built using an older version of the standard.
When considering how products of different versions work together, we need to differentiate between backward compatibility and forward compatibility. In IEC 61850 we define those from the perspective of an information user (e.g. an IED that receives a GOOSE message or a tool that loads a SCL file). As backward compatibility, we consider the case where an information user must deal with information from an information provider of an older version of the standard. An example would be a system configuration tool that needs to import an ICD file based on an older version of the SCL schema. Forward compatibility would be the opposite – using again a tool use case, an IED configuration tool that needs to import an SCD file based on a newer version of the SCL schema.
When the first Edition of the standard was created, elements to identify the standard version were already added. Therefore, it will always be possible, to identify from the device nameplate, which version of the standard the data model is based on. Also, the SCL files included references to the schema version. So, in principle, backward compatibility can be achieved if the information user supports both the old and the new version. But that is not really practicable as a long-term approach as it would mean that a vendor would need to have all the old versions of the standard and implement them.
Forward compatibility is challenging as it is not known what future versions of the standard will add or modify. One approach to make forward compatibility easier is, to have a tolerant design in the products, ignoring unknown stuff. SCL introduced in Ed 2 the concept of “must understand – may ignore” which means, that a tool can ignore everything in an SCL file that it does not know and that is not flagged as “must understand”. Elements flagged as “must understand” cannot be used if they are not known. So as an example, a report control block for routable GOOSE has a new attribute indicating it as such. That report control block is flagged as “must understand” – so e.g., a system configuration tool that does not know that new attribute (and hence does not support routable GOOSE) shall not configure such a report.
In some cases, with SCL, instead of achieving forward compatibility, a tool of the newer version can as well produce a downgraded version of the file. This is typical between Ed 1 and Ed 2 – Ed 1 did not yet have the CDCs with enumerations (e.g. ENS), it was using the integer CDCs instead (e.g. INS). A downgraded version of an Ed 2 file would change all the CDC names for enumerated CDC from Exx to Ixx.
In Ed 2.1 of part 7-1, an Annex was provided, that lists all the possible use cases for modifications between versions of the standard and provides rules how to deal with them. Those rules include rules for product implementations. Specific Annexes on the individual parts summarize the issues with all older versions, that an implementation needs to consider.
Rules for Editors of the standard, how changes to the standard shall be made between one version and the next can as well facilitate compatibility between versions. The above-mentioned Annex of part 7-1 provides those kinds of rules as well.
Another resource of information dealing with compatibility issues between versions of the standard is chapter 6.4 of IEC 61850-4. That chapter discusses various use cases from a utility perspective, that may require the introduction of devices of a newer version in an existing system. For each use case, the impact on the rest of the system is described. A use case discussed in part 4 is the failure of an IED that needs to be replaced with an IED of a newer version. Preferably the new IED can be configured such that the data model is identical to the old one, including configuration of report control blocks and data sets. If that is not possible, an update is required for the system configuration file (SCD) and possibly as well the configuration of the client interacting with the new IED. If GOOSE messages cannot be configured the same way as they have been with the old IED, subscribing IEDs need to be reconfigured as well.
To summarize, a device and tool vendor shall follow the requirements provided in Annex of part 7-1 and part 6. With that, forward compatibility for future editions and backward compatibility to older editions will be supported. A user shall request that the products support those requirements. Use cases may need to be analyzed. As a general recommendation, if possible, a client shall be upgraded to the latest version of the servers in the system. Between amendments (e.g. from Ed 2 to Ed 2.1), that should not be an issue, as an amendment replaces the previous version, so upgrades to the products must be available.
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.
