I don't agree with your discussion - since this is assumming processing of the system. When the EU information changes - if the value also needs to be change they should be locked together. A client that is just reading the EU - get a new EU when it changes - he would then mis-interpret the value. When the server set the bit - the value should also have been set- if it needs to be updated - if the logic in the server does not trigger a new value(because it did not change - the EU change is such that the resulting value in the same - it is -40 degrees out side - the value in C and F is the same - the bit is still set when the EU was updated and an new report is generated.

we don't think anything needs to be changed

Well, that sounds all nice and clean, but we don't have a mechanism in OPC UA that would enable me to distinguish between the situations where the semantic change will be accompanied with a value change (sooner or later) or not.

My assumption is that if the Engineering Units is changed from C to F, the value always needs to be updated as well. Assuming something else can be very dangerous at worst.

The whole idea with the SemanticsChanged bit is to tell that if the server configuration has been changed while the client is monitoring data changes in a way that requires the client to update it's understanding of the values , the client can notice it and avoid interpreting the new value with old semantics. If the client is not expected to react to the unit change, since it does not really affect the interpretation of the values, there is also no need for this bit to be sent.

Meaning, in your case, if the server is expected to send the following data to the client:

25 C
25 F (Semantics Changed)

we don't really need to send the Semantic Change or the same value again at all.

The main reason for the SemanticsChanged bit is to avoid the situation, when the server really starts sending values in a different ballpark as in my original example.

OK, let's assume you are actually expecting this, instead:

0 m
0 yd (Semantic Change)
1 yd

Why is it important or even necessary to send the value 0 with Semantic Change? If it is OK to use 0 with 'm', it is as OK to use it with 'yd'. So, I can as well send

0 m
1 yd (Semantic Change)

And this is what we are doing, when we get the new sample that changes in value.

And finally, let's assume that the change of units really comes from a client application (as happens with the CTT) and it should be accompanied with a value change. For example:

25 C
77 F

Who is responsible of doing the unit conversion (25->77). Should the server expect the client to write it and if it doesn't, should the server be clever enough to do this conversion? Or if the client is supposed to do it, how does it know that it should send a new value as well, when it only wants to tell the server that I would actually want to see these measurements in F instead of C?

Or if the client only changes the units, how is the server supposed to know that it may apply it with the current value that used to be in different units? (and why would it then need to send the old value with new units?)

Anyways, our implementation in the SDK follows the above logic and is safe in every case: it marks the SemanticsChange bit to be added to the next value change. This leaves it up for anybody to provide the new value. Only after that will we report the new data change. That means we will never send an unexpected value (25 F) in case the real sample in F is expected in a few seconds (which we don't know).

The usual assumption is that this kind of unit changes cannot be made safely from client applications and my expectation is that this is server internal configuration since the server knows the values that it is updating and their proper units. So the assumption is that within the server the units are changed first and the value update will shortly proceed. If the server is capable of using different units, it must also be capable of doing the conversions. Since we don't have such functionality built in, I expect that the applications written with the SDK will take care of it. So, I can only mark the Semantic Change and expect that the application will update the value shortly. I don't need to do anything special for that.

As discussed in UA working group - no change required

Agreed in call