Part IEC 61850-7-2 defines several control blocks with the attribute ConfRev, e.g. for BRCB, 17.2.2.7 ConfRev – configuration revision
The configuration revision is a very useful information for clients (Reporting) and subscribers (GOOSE and SV). It is highly recommended that a receiving IED marks the received values as invalid in case the receiver expects ConfRev=X but receives a message with a value unequal X.
The service Reporting (or GOOSE) could be used to inform receivers that there is a change in the ConfRev – long before it may receive a message with a different (incremented) value.
By the way, the functionality to “monitor” changes of control block attribute values is called “Service Tracking” and is defined in IEC 61850-7-2 Edition 2.
The Control Block Attribute ConfRev needs to become a member in a data set. This data set may have all ConfRev attributes of all control blocks as members. So, if any change is detected, a message is issued (Report or GOOSE message, or log entry posted).
It is not yet specified in IEC 61850 if the change of a value (of the ConfRev) implemented by a re-configuration of the IED (e.g., change of the data set) can be used as a trigger (dchg) to issue a report or GOOSE message or post a log entry. Because this new value may become online visible after the IED restart (to interpret the new SCL file).
It would require that the Control Block stores the last ConfRev value non-volatile; in order to figure out that the new value (from configuration tool) is larger than the old one. This is true for SV Control Blocks only, see §19.2.1.6: “A restart of the IED shall not reset the value.”
Proposal
Add text at the end of clause 17.2.2.7 and other clauses on ConfRev:
"Any increment (change) of the ConfRev - caused by a local configuration change or by a service - shall be applicable for Service Tracking, i.e., the change of value can be used to issue a report or a log entry to be posted in a log."
Discussion
Created
Status
04 Jan 13
In Force (green)
Clause 15.3.1 General
already defines "Control block value changes may be caused by servies setting a specific value or by an internal (local) event in the server.
Final Proposal from august 9th is still valid.
22 Aug 12
Ballot Period
The proposed final proposal covers the case where the confRev is set by a client with SetBRCBValues. The case of a configuration change by a (local) configuration tool should be covered as well. It does not matter how the change was implemented (locally or be services), it should be possible to, e.g., report or log the change.
13 Aug 12
Ballot Period
extend the clause 15.3.2.2.1 ServiceType = SetBRCBValues with the sentence:
The attribute confRev contains the value of the configuration revision number the the BRCB referenced by the atttribute objRef after the SetBRCBvalues service has been performed. For example, if the SetBRCBValue changed the configuration of the BRCB that lead to an increment of the configuration revision number of the BRCB, then the new configuration revision number of the BRCB is expected in the confRev attribute of the BTS.
09 Aug 12
Ballot Period
I agree with Thierry. Naturally this does not lead to a reporting of changed confRev by loading a new configuration, however anyhow each reporting client should check be confRev before enabling a RCB, like all GOOSE and SV subscribers do this for each message received.
12 Jul 12
Discussion (red)
I believe what is missing is the value of the attribute confRev in the BTS class when performing a SetBRCBValues.
I would extend the clause 15.3.2.2.1 ServiceType = SetBRCBValues with the sentence:
The attribute confRev contains the value of the configuration revision number the the BRCB referenced by the atttribute objRef after the SetBRCBvalues service has been performed. For example, if the SetBRCBValue changed the configuration of the BRCB that lead to an increment of the configuration revision number of the BRCB, then the new configuration revision number of the BRCB is expected in the confRev attribute of the BTS.