Project

General

Profile

Improvement #633

Initial values of paramRev and valRev

Added by Carlos Rodriguez del Castillo about 3 years ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Category:
Standard clarification required
Start date:
02/05/2021
Due date:
08/05/2021 (over 2 years late)
% Done:

0%

Estimated time:
ID:
1
Source:
ZIV
TF Unique ID:
1 # ZIV
WG10 Proposal:
Estimated Completion:
Discuss in Upcoming Meeting:
No
To discuss in WG10:
Yes
Short Proposal:
Standard(s):

IEC 61850-4

Needs More Information:
No
Assigned TF:
61850-4

Description

Has the initial value of paramRev and valRev got to be taken from the process or from the configuration file? Or is it up to the vendor to decide which approach his device is going to follow?
  • On the one hand, these parameters are defined with fc=”ST”. Apparently the initial value of fc=”ST” elements has to be obtained from the process, i.e. not read from the configuration file (see table 4 in part 7.2)
  • On the other, the standard defines how these data have to be updated, both with changes made by the tools or changes made in the IED through communications or HMI (see table 86 in part 7.3), so apparently the initial value in the SCL file has to be taken into consideration
  • Finally the standard in part 6 also indicates that it is the responsibility of the system engineer to clarify whether “the concerned IED supports loading of these data via an SCD file”. (see bullet 10.2 in part 6) (I suppose SCD is a mistake and should be SCL, right? The tools read the SCD and the IED may read the resulting CID…but no the SCD…)

Our understanding on how to deal with these attributes is that, if they are part of the data model (they may not be, as they are optional), both the tools and the device must initialize the value of these attributes with the value in the configuration file and not the value in the “process”.
Is our assumption correct?

We find very strange that these data are defined as fc=”ST”, but once defined as ST, we do not think it is clear enough in the standard that these attributes have to be treated in a special way, in the sense that they are initialized with the value in the configuration file and not with the value in the process as the rest of ST elements are. Am I missing or misinterpreting something or is our assumption correct?

Proposal descriptions

The point here is more that the paramRev and valRev are not bound to the process as such. It is an internal status of the device, and this is what is confusing here.

If we consider the internal configuration of the device as the “process” related to these DAs, then, there is no contradiction in any parts.

As per 7-2, the initial value will be read from the internal configuration, because it may change during running of the device, and so the SCD value is no more relevant.

Then, based on part 6 comment, this will be decided by the device manufacturer how this value is managed and the engineer have to know how it is managed (here we may have a hole in the standard…). The device may initialize the value from the SCD and store it in the internal configuration, or the device may manage it totally independently of the SCD and so the internal database will have to be updated also on configuration update, but with internal value.

And part 7-3 is clear on how the value have to be updated.

The certification test is not based on the paramRev, valRev values written in the SCD, but check that after import values are updated.

And choice of FC=ST for these values is because CF are not bound to trigger options and there is no process regarding live update of CF data attributes.

So maybe what could be clarified in the standard are:
- What is “process” for ST bound to internal data of the device
- Improve description of the management of the value initialisation by the device

Also available in: Atom PDF