Process late data at runtime

Data received from the Telemetry Server or other sources may arrive late, especially when using publish/subscribe models such as MQTT, with or without Sparkplug B. "Late data" refers to process data that is received after the time of the actual event. For example, an OMI ViewApp may receive data along with its VTQ timestamp some number of minutes or even hours after the triggering event has occurred.

Application Server allows late data received through a DI Object to backfill historical data in the Historian while presenting live data to OMI ViewApps. Note that value historization is done only for attributes that have the History extension enabled.

When connection to the data source is lost, historical data and alarms are backfilled once the connection is restored. References to ScanGroup items directly in scripts allow late data to be processed. For example, "me.Int1 = DiObject.Scangroup.Item1" assigns late data values to user-defined attribute (UDA) Int1.

Late data received from DI objects referenced through the I/O extension is not backfilled. In the meantime, OMI ViewApps show the last known good value. The live data feed resumes once the data connection is restored. Historical data is sent directly to the Historian and does not affect the runtime values shown in the ViewApp.

While the Historian is procesing the historical data, Application Server uses a Quality and Status animation, "Processing Historical Data," to notify the ViewApp that this is occurring, while the live data feed continues. At the end of the historical data processing, the current data/states/values are determined based on either the live data or, in the absence live data, by using the last-known good values from the historical data. Trend pens, the Trend Client, and any other visualized data that relies on historical data are updated when historization is finished.

The historical data is historized appropriately and can be later queried as if it had been received in order.