OPC UA data timestamp does not replicated correctly

[Dragonfly1]

I'm using Geoscada in edge to pull modbus devices. This Geoscada will be connect to another Geoscada (intermediate Geoscada) using OPC UA to pass data to this Geoscada, and this Geoscada will ultimately connect to Central Geoscada also using OPC UA to pass data to this Geoscada, so here is the architecture 

Geoscada (Edge) --> Geoscada (Intermediate) --> Geoscada(Central)  ( All using OPC UA Connection)

As data moves from 1 Geoscada to the others, I observed that at the Intermediate and Central level, Geoscada automatically generate more data with different quality at the Intermediate and Central level. This behavior is impacting the calculation tags which uses this tag as an input. Attached is the screenshot of my data 
Is there anyone experiencing this behavior? 

[AdamWoodlandToo]

Not seen such behaviour before, but I've not really pushed the OPC-UA driver yet.

Can you add milliseconds to the timestamp (in your user profile) just to check nothing funky going on at that level?

Might need to get some driver logs for OPC UA and get support to have a look too.

[Dragonfly1]

I added milliseconds to the timestamp and test DA protocol 

Geoscada (Edge) --> Geoscada (Intermediate) --> Geoscada(Central)  ( All using OPC DA Connection)

I notice that from Edge to Intermediate, the timestamp replicated correctly, but from Intermediate to Central, the timestamp is incorrect ( screenshot).

[Noel_Henderson]

I noticed that the timestamps in question on the final system are the same as the previous good value timestamp, which is actually the proper way that OPC UA is supposed to propagate bad quality timestamps. I wonder if this is due to different settings between the servers with regards to the 'Log Historic Value on Communication Failure' settings for the Outstations.

Server 01 is saving the timestamp of the Modbus demand poll to say that it thinks the value at timestamp '2026-06-16 10:50:16.980' was zero, even with a bad quality. In my work, this would be considered an invalid inference, since the demand scan failed, and we do not know what the value was at that timestamp. Writing any value, including a zero, would not be reliable, which is why the OPC UA spec says to write a null. Zero is a valid value, and if a client does not filter on quality, they might think there was a valid zero value at the timestamp. We only knew the value at the previous timestamp. We could not infer the value for a failed scan and assign it the timestamp of the failed scan. Therefore, all we could do was say that, as far as we knew, the last known value's timestamp was the timestamp of the previous poll, and that was also the time we wanted marked as being the start of the bad quality data, until proven otherwise by a subsequent good poll. There IS no valid data that can be inferred during a communications failure state. The ONLY information you know is that you don't know anything. Marking the value at the previous timestamp as the last known good value that is carried forward until the next good scan is the OPC standard.

I would try unchecking the box for the Modbus Outstation on Server 01 to disable the 'Log Historic Value on Communication Failure' option or increase the Persistence Timeout to longer than the scan time. However, increasing the Persistence Timeout can result in out of order data with timestamps that do not make sense. If you simply do not store made up values when you can't reach the device, you will get consistent timestamps across servers. You can still track communications failures/failed scans at the outstation level, instead of the individual point level. This would also help to minimize communication failure alarms/events on individual points.

In the Geo SCADA help system, search for:
Driver Reference > Advanced Drivers Guide > Configuring an Outstation > Specify Whether Points Log a Historic Value on Communication Failure
and
Driver Reference > Advanced Drivers Guide > Configuring an Outstation > The Effects of Logging a Value Historically on Communication Failure

[Dragonfly1]

@Noel_Henderson thank you for your response.
I tried playing with 'Log Historic Value on Communication Failure' and it still yield the same result. Also, they data from the my screenshot is not actual data from a Modbus device, they data is from my OPC data simulator, so there is no option for be to tweak the Outstation object. 

The server configurations across 3 servers are the same. I think regardless of protocol, it should document the correct timestamp when the value goes to bad quality state