Sparkplug Store-and-Forward: Keep Replayed Samples Out of the Live Equipment View
When an industrial gateway sends stored measurements after an outage, the host must distinguish recovered history from current equipment state. A newly arrived MQTT publication is not necessarily a newly acquired measurement. Design the live display and historical-storage paths around that distinction before enabling store-and-forward.
Consider a hypothetical compressor that records pressure while its reporting connection is unavailable. After reconnection, an older high-pressure sample and a current normal-pressure sample reach the host close together. If the dashboard treats arrival order as equipment chronology, the older sample can produce a misleading live indication even though the transport delivered valid data.
Carry the acquisition context through replay
The Sparkplug 3.0.0 specification defines a metric timestamp as its acquisition time and provides the is_historical flag for values that should not be considered current. Section 5.16 requires chronological ordering within the metric lists of NBIRTH/NDATA and DBIRTH/DDATA payloads when is_historical is false. This is not a global ordering guarantee across separate messages. These rules are relevant to the gateway-to-host contract, not just to a chart's sorting preference.
Keep acquisition time when recovering stored data. Do not replace it with the reconnect or publication time to make the sample look recent. If the device clock was uncertain during the outage, preserve that limitation in the application's data-quality treatment rather than silently claiming a precise time.
The pinned Eclipse Tahu payload schema represents metric timestamp and is_historical as separate fields. It also has a payload-level timestamp. Inspect the actual decoder and downstream mapping so these different fields do not collapse into a single generic time column.
Specify the two consumer decisions
For each incoming metric, decide whether it is eligible to update the live equipment state and whether it should enter historical storage. These are separate application decisions. Historical eligibility must not automatically grant permission to overwrite the current display.
In the compressor example, the recovered high-pressure sample belongs at its original acquisition time in the historical record. It should not make the operator think that the compressor has just returned to that condition. The current sample and the host's data-validity rules determine the live indication.
Also define how analyses should react to recovered history. Rebuilding a retrospective report is different from issuing a new real-time notification. The desired behavior depends on the operational use case and must be agreed with the host application owner. A protocol flag alone does not prove that every chart, historian and alarm consumer applies that policy correctly.
Test replay while fresh data is arriving
A replay-only test can miss the important failure. Prepare an isolated fixture with an old interval, a current interval and overlapping delivery in the order the selected gateway actually produces. Give the samples distinctive values so their roles remain visible during review.
Check the decoded historical flag and acquisition timestamp before the application update. Then inspect both the live display and the stored timeline. Include a case where a historical value arrives after a newer current value. The expected result should state which view changes and which remains governed by current-data rules.
These proposed cases do not establish that a gateway buffers every sample or that its storage survives every outage. Buffer capacity, persistence and transport recovery remain separate requirements. This exercise targets semantic correctness after a recovered value reaches the host.
Keep recovery evidence specific
Record the gateway and host versions, the sample acquisition times, the transmitted classification and the actual destination behavior. If the historian accepts the sample but the dashboard also treats it as current, report the live-state mapping defect rather than calling the replay successful without qualification.
No gateway or host test was executed for this article. The acceptance result should demonstrate that recovered history enriches the past without misrepresenting the present. That is the essential application boundary for useful Sparkplug store-and-forward, beyond merely seeing old messages arrive after a reconnect.
