1565   db = 0 behaviour

Created: 14 Dec 2016

Status: In Force (green)

Part: Part 7-3 (2010; Edition 2)

Links: #1478 Q: dchg generation for a CMV

Page: Table 64



Category: Issue may impact interoperability of implementations of Edition 2


Current definition of db is specifying
"Value 0 shall suppress reporting events on the analog value, so that only changes of the 'range' value will lead to events.“

During the Editor meeting hold in Glasgow, the US-8 comment to 7-3 Ed2.1 CDV has been discussed and the following decision has been made:
Replace the above mentioned text with:
With a db = 0 the attribute mag (resp. cVal) follows the instantaneous value.”

An Ed2 interop tissue is needed + Tissue 1478 needs to be related.


Replace the db= 0 behavior alredy in current implementation with an interop2 tissue:

"With a db = 0 the attribute mag (resp. cVal) follows the instantaneous value.”

Discussion Created Status
ballot expired 25 Jan 18 In Force (green)
After all discussions, I do not see a strong argument, why the proposal can not be accepted and it will align the definition with what is defined for mag as Wolfgang has stated.

So final proposal:
Replace explanation with:
"With a db = 0 the attribute mag (resp. cVal) follows the instantaneous value.”
27 Apr 17 Ballot Period
We have to differentiate what the IED provides and what the user wants to have. If we assume that the IED provides all attributes, and the user wants spontaneous event based transmission with time stamp, i.e. something like DOname FC=MX in a report data set definition, then with any db caused change he will also get the range and the instMag values. The reason to define that db=0 suppresses db based events was the use case, that the user ONLY wants the range change (accompanied by mag and instMag at that time), but NOT all mag change events. With Ed2 however RangeConfig contains an own range related db (limDb), which anyhow needs to be considered when a limit is crossed. The suppression of mag based events can be reached by having a very high (e.g. 100000) db value instead of 0. Therefore the appropriate sentence in the clause 8 db definition can safely be removed (or changed appropriately). It anyhow contradicts the statement in clause 8 at the mag attribute concerning db=0. 23 Mar 17 Discussion (red)
To the question "(2) Is there a good reason that somebody needs to expose instMag through mag?".
In case only instantaneous value is wanted to be exposed and since mag is mandatory one need to have mag in any case in the model. So even if instMag was also present in the model one would still expose instantaneous value also through mag (or what else?).
23 Mar 17 Discussion (red)
One of the usage of the proposed change I am aware of, is the ability to use a db of 0 for synchrophasor application (IEC-61850-90-5). But I think that this is the wrong way. Actually, instMag and instCVal should have the dupd TrgOp since that is really what you want to do in this case. Also the dupd trigger on the mag and cVal attribute doesn't belong there (a db value is by nature only updated when the value changes).

After doing those changes, it still make sense to allow the 0 value of the db to disable changes in case you only want range changes.

On the other hand, if you want all changes and updates of the instantaneous value, you simply use instCVal or instMag with dupd trigger.
22 Mar 17 Discussion (red)
I think we have to consider several aspects here:

(1) with the suggested change, yes, a db of 0 would create many reports. But a db of 1 would do the same. So I think the argument, that a db of 0 can create too many reports does not count. The user needs to know what he does and the vendor shall provide a appropriate default configuration (of course the vendor needs to know as well what he does).

(2) Is there a good reason that somebody needs to expose instMag through mag? Bruce mentions that users want cVal (or mag) to represent instantaneous values (why? because instMag is not exposed in the model?), but they don't want to trigger report with it. If they want to see it as instantaneous value, but no report, I assume they want to see it with a read service? Well - that is possible also with the proposed modification. mag des not need to be put in the report.

(3) the only reason that seems to be a use case is, that you trigger reports through range changes and want to know the value while the range changed. But apparently that value is the range configuration value. A processed value might be different because you only take discrete samples of the value to determine a range change. But is that really of interest?

So I believe, that the proposed TISSUE resolution is still valid.
05 Jan 17 Discussion (red)
This is a bad idea. ED2 Clause 8 definition of "mag" already states "If db=0, the value of mag is identical to the value of instMag.". What is the reason for this proposal to change the operation of the reporting service regarding suppression of events when db=0?

Many Ed2 ICD file use this definition and pre-set the value of db to 0 on the assumption that excessive reports will not be generated and that users really want cVal to indicate current values. This wording invalidates 5 years of work and will result in many users needing to change db=0 to db="some-larger-value" on hundred of data objects every time a new device is commissioned. Users will also be forced to choose between "far too many reports generated" and "cVal might differ from the instVal by a large amount. This is the reason that db=0 value exists.
22 Dec 16 Triage
I change my possition and agree with Javier. It is really the question if a mag without a db or db=0 should be allowed. Else the difference between mag and instMag is useless.
If someone really have a slow system and wants to see every change in a report he can use the minimum possible db.
16 Dec 16 Triage
Does replacing "Value 0 shall suppress reporting events on the analog value, so that only changes of the 'range' value will lead to events.“ with "With a db = 0 the attribute mag (resp. cVal) follows the instantaneous value." mean that reports will be generated with each change of "mag" attribute, this is, every 2 ms for instance?
If not, the decision should be completing the sentence, not replacing it.
16 Dec 16 Triage
I think it is still necessary to keep part of the old text: "shall suppress reporting events on the analog value" otherwise there would be continuos burst of events (e.g. hundred(s) per second) when db set to 0. That is when considering e.g. current or voltage measurement. Or is it expected that db==0 is only used in cases where some measurement is by nature such that it does not change all the time (but in that case why to have db attribute at all)? 14 Dec 16 Triage


Privacy | Contact | Disclaimer

Tissue DB v.