10/22/2020
Hi,
We use OPC quality Code of value BAD to indicate that the measurements value they represent are BAD. This information useful to the client though they are BAD and does not represent miscommunication or something.
However, we noted that the OPC UA clients such as OPCExpert or Integration Objects OPC UA Client, show values set to OPCQualityCode BAD as null and not update the timestamp until the state changes GOOD or UNCERTAIN. Based on this behavior, we are not clear whether this is a defect in these clients or the OPC protocol allows such behavior/freedom to client implementations. If it is the later we need to rethink how we represent the BAD quality values though they are informational to the users.
Thanks for your feedback and time,
Murali
05/30/2017
BAD is intended to indicate the reason for no data and it does not have to be related to a communication problem.
The specification explicitly requires that the value be set to NULL if the Quality code is bad.
If the value is NULL then there can be no value change until the Quality changes to Good or Uncertain.
That said the default behavior is to report changes on a change to Quality as well as value so an update should be reported if the BAD Quality changes to another BAD Quality code. Changes to the timestamp do not trigger a change.
05/30/2017
It seems like when the Quality is Bad, one can use the sub code of LAST_KNOWN_VALUE.
No you can’t. BAD quality means the value cannot be used. So there is never a value.
Originally, this was not enforced but too many clients ignored the BAD code and used a bad value so the compliance tests were changed to force Servers to implement it correctly.
You need to use UNCERTAIN quality with the sub code of LAST_KNOWN_VALUE.
02/24/2014
Randy, there is an exception for Bad quality with LAST_KNOWN_VALUE, quote from the spec:
Last Known Value: “Communications have failed. However, the last known value is available. Note that the ‘age’ of the value may be determined from the TIMESTAMP in the OPCITEMSTATE.”
And, LAST_KNOWN_VALUE cannot be used with Uncertain, as you suggested. There is “Last Usable Value” with Uncertain, but that has somewhat different meaning.
This said, however, in reality some clients may have problems interpreting the value with Bad/Last Known Value – for the same reason – not following the spec carefully.
05/30/2017
exception for Bad quality with LAST_KNOWN_VALUE
The OPC UA specification is unequivocal about the no value on BAD quality rule.
COM Clients could suppress the value, even if provided, because of the concern that users would mistakenly assume everything is OK.
The test lab accepts clients that always suppress the value even when it is valid to send a value.
The only requirement is that if the value is displayed the quality but also be displayed.
Moderators-Specifications
Moderators-Companion
Moderators-Implementation
Moderators-Certification
Moderators-ProductsServices
Members
01/06/2018
02/24/2014
Would it be correct to sum it up roughly like this?
“In OPC DA, you can transfer a meaningful value with Bad quality and “Last Known Value” substatus. It may not be a good idea, though, due to unreliable support by real-world clients. When such data enters the OPC UA world, in compliant systems the value will be cleared and thus lost.”
Or, should the Part 8 reference to “Fieldbus code Bad_LastKnown” interpreted to apply also to mapping from OPC DA to OPC UA, and therefore the expected outcome is Uncertain_NoCommunicationLastUsable with the actual value?
1 Guest(s)