Hi, we are using Ignition to pull OPC-UA and publish to AWS Kinesis using AWS Injector. The source of the OPC-UA data is in the past (~November 2023), and we have been playing back the data via the OPC-UA server. All works well but we have noticed some issue with the timestamps in the DDATA payloads with float array type arriving in AWS. Instead of showing the timestamp comes with the OPC-UA tag, which is from the past, it shows the current time. Inspecting the timestamp of the same tag in Ignition Designer indicating the timestamp is correct, as in, in the past.
Where with the same AWS Injector agent, the payload with data type of String is showing the timestamp in the past correctly. Below is an example.
Can someone please assist with understanding this behavior? Obviously, we want to keep the timestamp from the OPC-UA source. Any hint or suggestion would be appreciated. Thank you in advance.
MQTT Transmission does always use the timestamp from the tag change event time except in one case - and that is in the Sparkplug BIRTH message. That uses a timestamp of ‘now’. The reason for this, is that when the connection is lost between the Edge (Transmission) and the Host Application (Engine), MQTT Engine sets the tag quality to BAD_STALE for all tags and uses the timestamp of ‘now’.
When MQTT Transmission comes back online, if any tags hadn’t changed, the timestamp could be before the BAD_STALE event in Engine. This would cause a couple of problems. For one, this is a duplicate event which would cause a collision in the historian if tag history was used. Also, the timeline of events would be invalid. At this point, it would appear that the tag is still BAD_STALE until a new/true tag change event occurs.
I should’ve also mentioned that the Injectors use this same logic that Transmission does. So, all BIRTH messages will use a timestamp of now and DATA messages will use the tag change event timestamp.
Hi Wes. Thanks for the explanation. This aligned with my understanding of the timestamps used in the Sparkplug messages.
I have done a bit more testing today. It would appear that (so far) the timestamp only incorrectly interpreted by the AWS Injector module if the tag is the data type of Float4Array. I have confirmed the timestamps included in the payloads for the tags with both Float and String data type are good.
I have email support with a sample message arrived in AWS. I have since upgraded the Ignition to 8.1.43 and the AWS Injector module to 4.0.22. This didn’t make any different.
FYI the support call reference is: SUP-4780.
Just closing the loop on this - This issue was related to a problem in Ignition prior to v8.1.43 where certain datatypes (Array types, Datasets, and Document) did not properly reflect the tag change event time when generating an event. MQTT Transmission is really driven by tag change events and relies on the timestamps sent from Ignition to Transmission.
As a workaround, MQTT Transmission would always force the timestamp to ‘now’ using the gateway system time if the event was one of these datatypes. This ensured that tag change events were in-order/chronological/updating. However, this introduced an issue in that if an old timestamp was being used in the updateTag call (i.e. the timestamp would not be the supplied one but would be overridden to ‘now’). This is why the timestamp was being updated to ‘now’ even though that was not what was being supplied.
Since this was fixed in Ignition 8.1.43, MQTT Transmission (and all Injectors) were modified to honor the supplied timestamp rather than updating it to ‘now’ if the Ignition version it is running on is Ignition 8.1.43 or newer.
To see proper timestamp handling for these specific datatypes requires MQTT Transmission v4.0.23 and newer and Ignition 8.1.43 or newer.
