The current definition of the quality doesn't allow the specific identification of 2 very frequent use cases:
1. The value being invalid as a result of the corresponding LN being Offline (Beh="off").
2. The value has never been set or updated, for example at startup.
Proposal
Multiple solution could be used to identify those causes for invalid quality:
1) For the first case, we could use the "reserved" value of the validity attribute. But this may lead to issues with some systems that only use 1 bit of this field.
2) Specify to use the detailQual.failure attribute in these case.
3) Define new quality attribute(s) to identify those condition.
4) Do nothing, but clarify the expected behaviour in those cases.
Discussion
Created
Status
oldData implies 'questionable' and not 'invalid'.
Therefore it is the wrong choice.
According to 7-3 detailQuality might provide more detailed information - but only, if this is also a correct information.
In case 1 therefore no detailQuality needs to be set, as none applies. Due to the state of Beh the reason should be clear.
In case 2 it depends on the situation. If e.g. an RMS value cannot be calculated because the sample input stream was never activated or failed, failure=true is the correct detailQuality. For 'real' directly taken process values this should not happen, as the inputs can be read before communication is activated.
No change is needed.
30 Mar 17
Not Applicable
No change is needed. Both of the scenarios should result in oldData=TRUE