To be revised: it will include a discussion about setting a bit in the status code that the sourceTimestamp was estimated

The SourceTimestamp is the timestamp that is assigned to a Variable’s Value by a data source. Once a Value’s SourceTimestamp has been assigned it shall never be changed. There shall only be a single data source that supplies this timestamp. The SourceTimestamp should be generated as close as possible to the source of the value.

The sourceTimestamp shall be UTC time and should indicate the time of the last change of the value or statusCode.

If the Server supports multiple non-redundant data sources for the same Variable, then the Server shall not allow the SourceTimestamp to be set by any of the Variable’s data sources. In this case the Variable’s SourceTimestamp shall be set to NULL and never assigned a timestamp, and the Server shall set the value of the Variable’s AccessLevel attribute to indicate the SourceTimestamp is not writable, by setting the TimestampWrite bit (6) to 0.

When the data originates in redundant sources the Server may optionally support multiple sources for the SourceTimestamp – it should ascertain or must otherwise know that the sources are redundant. The Server shall set the TimestampWrite bit to the appropriate value. The clocks of the redundant sources should be synchronized.

When the OPC UA Server receives a value and it contains a source timestamp and the Server supports writing to the SourceTimestamp, it shall assign it to the Variable’s SourceTimestamp without modification, regardless of the value or statusCode in the data. If an error occurs such that the source could not supply a value, then the Server shall set the Variable’s SourceTimestamp to null, the ServerTimestamp to NOW, and the statusCode to indicate the error that occurred.

Examples of data sources include
• The Server
• A device accessed via non-OPC interfaces (e.g. Profinet, Modbus, etc.)
• An OPC UA Server supplying data to an aggregating Server.
• An OPC UA Client writing data to a Server.

The SourceTimestamp is only returned with a Value Attribute. For all other Attributes the returned SourceTimestamp is set to null.

IMO requiring the Server to set the sourceTimestamp to null to indicate there was an error communicating with the data source is a sub-optimal solution. The quality should be enough to indicate there was an error. As it is, each client must write custom code to handle the case where it is using the source timestamp, because when it goes to null it must now assume there was an error even if the quality is Good.

The text as written aligns with the discussion at the F2F on Monday, but in Friday we reached a different conclusion. See next note

In F2F on Friday, Dec 9, we discussed the source timestamp in greater detail. My notes from this are contained in the ppt Proposals\UA Timestamp negotiation proposal_2022-12-9.pptx in the meeting folder
My notes indicate we agreed to the following:

The normative text on source timestamp needs revision
The source timestamp shall be consistent and reliable, which means
: only one entity shall assign the timestamp, except as otherwise noted
:: The Server will not set the source ts to null when an error occurs, because apps logging this data will be unable to later determine when the error occurred (it wont have a timestamp)
: if the timestamp has be assigned by a data source and the source becomes unavailable, instead of the server setting the ts to null, it will provide an estimated value based on the last source ts and its own wall clock.
:: when the ts is estimated the server will set a currently unused bit in the quality code to indicate the source ts was estimated, not assigned by the source.

Creating a time sync model will be a separate subscribed object, to be defined in a working group (e.g. UAFX)

Please correct any misstatements or missing info