Log In
Home
06/25/2014
Offline
Hello all,
the CTT script ‘Data Access/Data Access AnalogItemType/020.js’ test the Write Service to modify an AnalogItemType value which is out of the InstrumentRange-Range. The expected status for this write request shall be Bad_OutOfRange and no modification from the current value. In which part of the UA specifications is this behaviour defined? The only place where I could interpret this would be UA Spec. Part 4, 1.03, p. 53, table 60, Description from Bad_OutOfRange.
But if I compare the required behaviour from the CTT with UA Spec. Part 8, 1.03, chapter 5.3.2:
“Sensor or instrument failure or deactivation can result in a returned item value which is actually outside of this range. Client software must be prepared to deal with this possibility. Similarly a Client may attempt to write a value that is outside of this range back to the server. The exact behaviour (accept, reject, clamp, etc.) in this case is Server-dependent. However, in general Servers shall be prepared to handle this.”
I assume that it is our decision how the server should handle this situation.
Based on the CTT tested behaviour I am not familiar with at the moment.
Assumption:
1. a server receives valid values from the Client (i. e. a temperature sensor)
2. the physical connection from the device is corrupted and send data values which are out of the InstrumentRange-Range.
3. the server will show forever the last valid value and nobody assumes that the temperature sensor works not correct.
Probably someone can explain me the idea/concept behind this behaviour.
Regards,
Martin
Hello Martin,
The test you refer to in the CTT was defined back in 2009/2010, so it’s an older test case now. I reviewed it and it doesn’t contain information to justify the decisions made. I wonder if at the time the specifications (probably 1.0/1.01) were dissimilar?
Anyhow, the InstrumentRange is intended to provide the upper/lower bounds of what the instrument can handle. You’re right that the spec does provide some flexibility in terms of the values that may be reported by the device.
I think that when we created the case we focused on the start of the sentence “Sensor or instrument failure or deactivation can result in…”. I think this means that a value outside of the range indicates a failure in the device. With that said, we weren’t sure how a Server would handle writing a value that exceeded the range of the device if the former [statement] was true. I think for this reason, we considered the resulting write should fail.
If you feel strongly against this, then please do justify your thoughts and we can discuss it in our next CMPWG meeting.
06/25/2014
Offline
Hello Nathan,
I have a short look into the UA Spec 1.0 and 1.01, but could not recognize fundamental changes.
I had today a discussion in which it came out, that there exist several principles of operation in this case.
At the moment I see my arguments are not strong enough to change something which is alright specified.
I think a possibilty could be the writing value result is BadOutOfRange, the value is written within the server and the value statuscode is also modified from Good to BadOutOfRange. In this case a client should handle this server behaviour in a own way.
Thanks for your detailed explanation!
Regards,
Martin
1 Guest(s)
Usage Policy