HistoryUpdate Service, sourceTimestamp vs serverTimestamp|OPC UA Standard|Forum|OPC Foundation

Hi all,

in a HistoryWrite service call, the values being updated are ultimately represented by the DataValue type (Part 11, section 6.8.2.1).

The DataValue type is defined in Part 4, section 7.7.1, where it has fields sourceTimestamp and serverTimestamp, both defined as the UtcTime type, which, per section 8.38, Part 3, is an alias for type DateTime, which, per section 8.11, Part 3, is defined in Part 6, section 5.2.2.5, where it is defined as “as a 64-bit signed integer (see Clause 5.2.2.2) which represents the number of 100 nanosecond intervals since January 1, 1601 (UTC).”

Now, coming back to Part 4, section 7.7.3, there is a provision that sourceTimestamp of DataValue can be null. E.g., “If the source that applies the timestamp is not available, the source timestamp is set to null.”, which probably means the sourceTimestamp field is optional.

No such provision is made for serverTimestamp in section 7.7.4, which probably means the serverTimestamp field is mandatory.

I have no been able to find any information how HistoryUpdate service is supposed to interpret these two timestamps. All I can find is language like (Part 11, section 6.8.2.2) “This function is intended to insert new entries at the specified timestamps, e.g., the insertion of lab data to reflect the time of data collection”, which is not specific enough. Section 6.8.1 says “See Part 3 for a description of Attributes that expose the support of Historical Updates”, but I could not find relevant information there.

1. Is it correct that sourceTimestamp is optional and serverTimestamp is mandatory in general?

2. Is it correct that sourceTimestamp is optional and serverTimestamp is mandatory in the HistoryUpdate service case?

3. How can a null value for a sourceTimestamp field be encoded, given that it is defined as an integer value? In the ANSI C implementation, both fields are an embedded structure (not a pointer!) with two 32-bit integers, so there is no way to interpret that as null except by assigning a particular bit pattern to that, but what is it, if there is one?

4. How should the historian treat mismatches between its capability and the requested update? For example, if it only supports source timestamps (which is permitted by section 4.3 of Part 11), but one is not supplied by the HistoryUpdate client (assuming it is possible), or when both are supplied, with different values?

Thanks,

V.