Section 7.1 states that
"Sometimes, both dchg and dupd are specified as a possible trigger option for the DataAttribute. In that case, the concrete implementation shall select one of them, based on the purpose of the data object typed by that common data class. Trigger option dchg shall be used for DataAttribute where a change of the value is necessary to create an event, whereas trigger option dupd shall be used for DataAttribute where an update of the value (with or without change) is enough to create an event."
This is the case of cVal attributes of SDOs of WYE class.
And section 7.4.6 requires that:
"Values for 'phsA', 'phsB', 'phsC', 'neut', 'net' and 'res' have been simultaneously acquired or determined, and their respective time stamps hold the same value 't'."
And further:
"The actualization of one of the component due to a dead band calculation results in the actualization of all other components and a restart of the dead band calculation for all components."
In this way the static data shall present cVal attributes with values of the same time stamp values upon a GetDataValues request of the client.
But what is the way to assure also the reported data flow consistent with the static data?
Section 7.4.6 says in further text:
"The transmission of the values in a report follows the Trigger Options definitions – i.e. component with Trigger Option:
– dChg will only be included in the data-change Reports if it has really changed,
– dUpd will be included in the data-update Reports in any case."
So when a cVal attribute in just one SDO is a subject of data change at a given time, the other SDOs shall have their cVal attributes set to inst values of the same time.
Still, the resulting reporting of these other SDOs is not unambiguous:
Case 1) If the cVal has "really" changed:
a) does "really" mean it has not the same value but not exceeding the deadband, so then there shall be a data change report ?
b) does "really" mean exceeding the deadband and only then there shall be a data change report?
Case 2) But if the cVal has not changed at all (e.g. remains 0 for a disconnected phase) then shall we have:
a)no report at all ?
b)shall there be a data update report because of having new timestamp for the cVal (and value of that time moment) in this SDO ?
c)shall there be anyway a data change report because of having new timestamp for the cVal (and value of that time moment) in this SDO because the concrete implementation is based on trigger option dchg (and not dupd) ?
Please note that the above problem can be also considered when a quality attribute q in just one SDO is a subject of quality change at a given time:
shall the other SDOs have their cVal attributes set to inst values of the same time to assure the same value 't' for all SDOs? This is not an addressed situation in the text of Part 7-3.
Proposal
For case 1) the conclusion from tissue 1602 is that 1)a) is correct (it also allows to avoid deadband crossing in small steps which remains invisible for clients).
But for case 2)? For providing the same information in the report flow compared to static data view, the conclusion would be that 2)b) is correct. But this is, in my opinion, in contradiction with the text of section 7.1 (only one trigger option is use).
Please clarify the quality change situation as well.
Discussion
Created
Status
Approved
22 Nov 22
Editorial
The following clarification is proposed to be addded.
As it is cited in the issue report, the standard defines:
"The actualization of one of the component due to a dead band calculation results in the actualization of all other components and a restart of the dead band calculation for all components."
Add following clarification text in clause 7.4.6 & 7.4.7 after "if it has really changed":
"So, deadband calculation may have finished for e.g. phsA, but not for phsB. But still, phsB may have changed now and will trigger a dchg report. if phsB has not changed, it will not trigger a dchg report."
Add following clarification text in clause 7.4.6 & 7.4.7 after "data-update report in any case":
"because a re-calculation has occured."
11 Oct 22
Approval (Editoral)
Can we move that to Editorial - as it requires a clarification but does not create an interoperability issue?
03 Jun 21
Accepted
Accepted that a clarification is needed
1. On case 1, Agree that 1a) is correct.
2. On case 2, I would assume 2a) is correct if dchg is implemented; if dupd is implemented, 2b) is correct
This may indeed result in the situation, that a t attribute may change for a SDO, but this will not be reported. This should not be an issue however. We may add a recommendation, to use e.g. PhV[MX] to create the dataset for the report.
I disagree with the comment from Bruce, that a qchg is generated for every q attribute - only for the ones that really changed.
15 Feb 21
Accepted
This needs to be clarified. Propose for WYE/DEL/SEQ:
1. quality is updated each time cVal deadband calculation is performed. If any CMV.q attribute is changed then all of the associated q attributes are re-calculated, all timestamps set to the same value, and a qchg is generated for every q attribute in the WYE/DEL/SEQ.
2. if any CMV.cVal attribute in is changed then all instCval attributes are copied to the corresponding cVal attributes, new quality calculations are performed, all timestamps set to the same value, and a dchg / dupd event is generated for every cVal attribute in the WYE/DEL/SEQ.
25 Sep 20
Triage
In case 2, I would assume that this date attribute would not trigger a report.
If one of the other phases triggers the report, the one that did not change its value may or may not be included, depending on how the dataset is constructed (if the dataset refers e.g. to PhV[MX] it would be included; if the dataset refers to PhV.phsA[MX], PhsV.phsB[MX], ... it would not