View Issue Details

IDProjectCategoryView StatusLast Update
000931110000-004: ServicesSpecpublic2024-01-04 10:53
ReporterBjarneBostrom Assigned ToMatthias Damm  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version1.05.02 
Summary0009311: Should SourceTimestamps be updated when "synchronizing structure-related nodes"?
Description

I see
https://mantis.opcfoundation.org/view.php?id=8423
https://mantis.opcfoundation.org/view.php?id=8514
but their status seem open even though they did target earlier than 1.05.03 which we have now in https://reference.opcfoundation.org/Core/Part4/v105/docs/7.11.3. So, it is possible some work is not yet visible.

In UA we (can) have Variable Nodes whose DataType is a Structure type. Then, we might have sub-nodes below that that represents the individual fields of the Structures. Lets call the Structure-one "top-lvl" and the subnodes "field-node(s)" in the context of this mantis issue.

Regradless of the underlying implementation, OPC UA wise we can say that the top-lvl node and field-nodes must be "synchronized" in some way, such that if one sets/writes the value to top-lvl it is set to the field-nodes as well and vice versa.

The question is what should be the SourceTimestamps for all these nodes?

I personally think they all must share the same (as it is the same data), but I have .. heard other opinions, thus I think it should be mentioned or recommended in the spec (if it already is, sorry, I missed).

The other opinion is that the value is pushed to the field-nodes only if it would change. Technically the https://reference.opcfoundation.org/Core/Part4/v105/docs/7.11.3 does say "... and should indicate the time of the last change of the value or statusCode.", so the SourceTimestamp shouldn't change at all if the value/status would not change? (Though, this would make the STATUS_VALUE_TIMESTAMP filter option in MonitoredItems useless because in practice it would not be possible to update the SourceTimestamp if value/status doesn't change??). This matters because the /Root/Objects/Server/ServerStatus i.e. i=2256 and the CurrentTime node of it (i=2258) will constantly update as the time updates, and thus the top-lvl ServerStatus node must also reflect this. But this also causes indirectly the ServerState node to update as it is part of the ServerStatus. Thus, a client cannot check when the ServerState e.g. first went to Running (maybe not the best of an example since there are other ways for this, but anyway..).

So, which way it should go, or does it depend on the situation?

Also, I think the https://reference.opcfoundation.org/Core/Part4/v105/docs/7.11.3 probably should say instead "Should indicate the time when the Value was obtained from the initial data-source" or something like that. Surely a Client e.g. writing the same value/status part, but a newer Sourcetimestamp should be applied (the current text would indicate not, since the value/status doesn't change, just the timestamp).

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Jim Luth

2023-12-19 18:15

administrator   ~0020537

Discussed in meeting. We don't want to mandate new behaivior here that would invalidate too many existing implmentations, but there may be room for some "shoulds".

Issue History

Date Modified Username Field Change
2023-12-13 13:06 BjarneBostrom New Issue
2023-12-19 18:12 Jim Luth Project UA Specification => 10000-004: Services
2023-12-19 18:15 Jim Luth Note Added: 0020537
2023-12-19 18:15 Jim Luth Assigned To => Matthias Damm
2023-12-19 18:15 Jim Luth Status new => assigned