Based on our observations, 8 out of 10 configurators do not fully recognize the configuration of SCD files. We recently encountered an interesting case of incorrect import that led us to write tissue 1791.
Background
For one of our projects involving 43 IEDs (Intelligent Electronic Devices), we developed an SCD (Substation Configuration Description) file. The equipment described in the file included analog signal converters, discrete signal converters, protection and automation relay terminals, and bay controllers from 8 different manufacturers. When developing the SCD file, we accounted for the configuration specifics of each manufacturer's devices to ensure compatibility and unified configuration during commissioning.
During the import of the SCD file and its recognition by the IED configurators (ICT), it was found that one manufacturer's devices could not subscribe to GOOSE messages and Sampled Values (SV) streams. The capability was absent because the configured control blocks were not displayed when importing the publisher device configurations. The developed file passed validation against the SCL syntax without errors, and the ICT did not signal any issues during import. As it turned out, the reason the control blocks were not displayed was the absence of the confRev attribute in the publisher device's control blocks within the SCD file. In this article, we will investigate why the manufacturer's ICT did not display the configuration and whether such behavior is correct.
What Is the confRev Attribute and What Is It For?
confRev is an attribute that indicates the number of times the dataset configuration referenced by the DatSet attribute of a control block has been changed. The attribute is required for configuration synchronization between publisher and subscriber; its current value is included in the published GOOSE message and SV stream.
If a subscriber receives a frame in which the confRev value differs from the expected value based on the loaded configuration, this indicates a mismatch between the publisher's configuration version and the actual one. Whether the subscriber checks this attribute can be determined from the device's PIXIT document.
In the PIXIT under consideration, it is stated that the subscriber does check the confRev value. Therefore, if it differs from the expected value, signals from the incoming message will not be processed. This attribute thus provides a way to protect the receiving device from incorrectly interpreting input signals.
Evolution of confRev
From the release of IEC 61850 Edition 1 through the current Edition 2.1, the requirements describing the functional role of the confRev attribute have been progressively formalized — changes that directly contributed to the problem we encountered.
IEC 61850 Ed1
In the first edition of IEC 61850, confRev is defined as the configuration revision number of the control block. The attribute is mandatory for Report control blocks and optional for GOOSE and SV control blocks. For Report control blocks, confRev must be incremented when an element is deleted from the dataset or the order of elements changes. The initial value of confRev is not specified by the standard. The value 0 is reserved. The confRev value must not be reset to its initial value upon device restart.
IEC 61850 Ed2
With the release of Edition 2, the formalization of the confRev attribute was expanded and partially revised. confRev is now defined as an attribute reflecting the number of times the dataset configuration referenced by the DatSet attribute has been changed. The key difference from Edition 1 is that confRev becomes mandatory for GOOSE and SV control blocks in the body of the standard. However, in the Edition 2 XML schema, confRev for GOOSE and SV control blocks remains optional. The conditions requiring attribute incrementation were formalized.
Changes that must be tracked for Report control blocks:
- deletion of a dataset element;
- change in the order of dataset elements;
- dataset configuration via SetBRCBValues service that changes the DatSet attribute value.
Changes that must be tracked for GOOSE control blocks:
- deletion of a dataset element;
- addition of an element to the dataset;
- change in the order of dataset elements;
- configuration change via SetGoCBValues, where the IED is responsible for incrementing confRev;
- referencing an already-set DatSet value via SetGoCBValues.
Changes that must be tracked for SV control blocks:
- deletion of a dataset element;
- change in the order of dataset elements;
- change of attribute values MsvID, DatSet, SmpMod, SmpRate, OptFids.
Note that for SV control blocks, confRev incrementation is affected not only by dataset configuration changes but also by the control block's own parameters. Dataset configuration changes via services are not permitted for SV control blocks.
A recommendation was added for the increment step of confRev (for GOOSE and SV control blocks — tissue 1590 raises the question of why an analogous recommendation does not apply to Report control blocks — this question is still under discussion): the standard recommends incrementing by 10,000 when the change occurs in configurators (SCT, ICT), and by 1 when changed via MMS services.
The initial value for confRev is not set by IEC 61850, but an integer range from 0 to 4,294,967,295 is specified.
The behavior of confRev for Report and GOOSE control blocks upon device restart may be implemented in two ways:
- restore the value from the base configuration;
- restore the value from the configuration at the time of restart.
The implementation for a specific device must be stated in the PIXIT.
For SV control blocks, confRev must not be reset on restart — it must be restored from the pre-restart configuration.
Responsibility for changing the attribute value lies with configurators (SCT and ICT). SCT and ICT must set the confRev value of the control block when it is created or modified, as defined in IEC 61850-7-2.
IEC 61850 Ed2.1
The currently effective requirements for confRev are those of Edition 2.1. They almost entirely coincide with Edition 2, with the following additions:
- for the reserved value confRev=0 (retained from Edition 2), a clarification was added that it must only be used for Report, GOOSE, or SV control blocks that have no dataset reference;
- for Report control blocks, confRev will be incremented when an element is added to the dataset. However, according to the response to tissue 673, Edition 2 also permits incrementing confRev when new elements are added to the dataset, even though addition is not listed among the triggering changes.
Investigation
Let us return to the problem that prompted this article. Was the configurator correct in refusing to import the GOOSE and SV control blocks from the SCD file, thereby preventing the completion of device configuration?
The observed problem arose from an inconsistency between the attribute's presence requirements in the standard's text and in the schema. The built-in validation of SCT and ICT tools typically checks only conformance to the SCL syntax declared in the XML schemas. As a result, ICD files without confRev — and the SCD files derived from them, also without confRev — pass validation successfully.
In our tissue, we proposed making confRev mandatory so that the Edition 2 and 2.1 schemas would align with the standard's text and allow errors to be caught during validation. The response we received was that the attribute would remain optional in the schema to maintain backward compatibility between editions, and that configurator validation should not be limited to XML schema checks alone.
Working with SCT and ICT tools from Russian manufacturers, we observe that most of them do not comply with the standard's requirements regarding confRev. Because SCL files are validated only against the XML schema — where confRev is optional for GOOSE and SV — the attribute is often absent from control blocks in ICD files and is subsequently not added in the SCT. And when confRev is present in the ICD, the tools leave its value unchanged, meaning dataset configuration changes go entirely untracked.
Reviewing other tissues on the tissue database website, we noticed that no one had previously raised this issue — meaning foreign colleagues have either not encountered these problems or have not paid attention to them. To examine a foreign implementation, we used the ICT of a well-known manufacturer widely deployed on facilities, including in Russia.
During the analysis, confRev value changes were tested by reproducing various operational scenarios and scenarios from ICT and SCT testing procedures.
Results
When creating a GOOSE control block, the ICT assigned a default value of 1.
The value 0 was not used because the ICT under review operates according to Edition 2. We also tried loading an ICD without confRev — the ICT assigned a default value of 1.
When a dataset reference was assigned to the control block, confRev was incremented by 10,000.
When the dataset reference was removed from the GOOSE control block, confRev was again incremented by 10,000.
Subsequent changes — reordering of dataset attributes, deletion of dataset attributes, and changing the dataset reference — all caused confRev to increment by 10,000, in accordance with IEC 61850 recommendations.
When attempting to delete the confRev value from the control block, the ICT refused to save the configuration, citing the valid range of 0 to 4,294,967,295.
Conclusions
To summarize the investigation: the manufacturer's configurator on our project behaved incorrectly when importing the SCD file. The SCD file did not meet the standard's requirements, yet the ICT loaded the invalid configuration without informing the user of any error. The problem was also found on the SCT side, which was used to develop the file — it allowed the creation and export of a file that did not comply with IEC 61850.
To prevent such issues in the future, SCT and ICT developers should review how their tools handle the confRev attribute and whether its value is incremented when:
- the dataset reference of the control block changes (DatSet attribute modification);
- elements are deleted from the dataset;
- the order of attributes in the dataset changes;
- elements are added to the dataset.
For SV control blocks, additionally when:
- the parameters MsvID, DatSet, SmpMod, SmpRate, OptFids change.
IEC 61850-10 testing procedures for ICT and SCT, as well as the Server Devices with IEC 61850-8-1 and PIXIT documents, specify how tools and devices must behave when the dataset configuration of a control block changes.
ICD and IID file developers should verify the presence of confRev in control blocks if it is already included in the file.
Tekvel has developed software packages enabling automated conformance testing of IED configurators (ICT) and system configurators (SCT) against IEC 61850 requirements. ICT and SCT testing is equally important as the already established and widely practiced IED conformance testing. Such checks are essential for the successful implementation of the engineering workflow proposed by IEC 61850.
As indicated in response to our tissue, additional SCD file analysis tools are required — tools capable of checking configuration not only against the XML schema, but also against the requirements of the standard itself. One such tools is Tekvel Inspector. Tekvel Inspector is used in Russian and international markets for expert review of SCD files under development. The tool identifies non-conformances to the schema and standard, assists end clients and SCD designers by pointing to configuration areas that require attention, and provides relevant standard references to guide correct configuration practices. Using an SCD file that has passed expert review by Tekvel Inspector during commissioning prevents a large number of configuration-related problems, thereby reducing the duration of commissioning work.
It is also important to emphasize the need for continuous monitoring of confRev attribute values during commissioning and subsequent operation. At these stages, when a publisher's outgoing dataset is reconfigured — triggering a confRev change — it is critical to be aware that the change has occurred. In such a scenario, the publisher device will transmit GOOSE/SV messages with an updated confRev value that differs from the SCD file, while the subscriber will expect the value specified in that SCD. Under these circumstances, identifying the root cause of communication issues becomes extremely difficult, since both devices were configured using the same SCD file. Without continuous change monitoring, this leads to prolonged fault isolation — and ultimately to longer overall commissioning and maintenance durations.
Installing Tekvel Park hardware and software complex as monitoring system on a substation helps avoid such problems. Continuous monitoring and diagnostics of IEC 61850 communications enable commissioning and operating personnel to identify in real time that a specific IED's configuration has changed. This enhances the observability of the operating system and improves operational efficiency.