When a remote site loses its link to the outside world, the process it monitors does not politely pause; tanks keep filling, pumps keep running, and pressures keep changing whether or not anyone can see them. Onboard datalogging is how an RTU or edge gateway makes sure those readings survive the blackout: it timestamps and stores them locally in memory that does not forget when power blinks, and when the link comes back it sends the whole missing stretch upstream to fill the gap. This guide explains how onboard logging works, how it differs from filling gaps on the server side, and how it forms the source that store-and-forward and buffer sizing depend on.
Onboard datalogging in one line: Onboard datalogging is the practice of an RTU or edge gateway recording timestamped readings into its own non-volatile memory locally, independent of whether the upstream link is available. When connectivity drops, the device keeps logging, and when the link returns it replays the stored readings to backfill the period it could not transmit. This differs from server-side historian backfill, which reconstructs or re-requests missing data at the central system; onboard logging captures the data at the source in the first place, and it is the origin that makes store-and-forward and buffer sizing meaningful.
The defining feature of onboard datalogging is that each reading is stamped with the time it was actually taken, at the device, at the moment of measurement, rather than the time it happens to arrive at a server. This matters because data that arrives late during a backfill would otherwise be misattributed to the moment of arrival, collapsing an hour of real events into a single instant. By carrying its own timestamp from birth, each reading keeps its true position on the timeline no matter how long it waited in the buffer, so a trend reconstructed after an outage shows what really happened when it happened.
The storage must be non-volatile, meaning it retains its contents when power is lost, because the same conditions that break a communications link, storms, power dips, equipment faults, often coincide with power interruptions at the site. Volatile memory would empty on every brownout, defeating the purpose exactly when it was needed most. Onboard logging therefore writes to flash or similar persistent memory, so a reading captured before an outage is still there after the device restarts, ready to be sent once both power and comms are restored.
Because the device is logging at the edge, it can also decouple how fast it captures data from how it eventually sends it. It might sample and log frequently for good resolution while transmitting far less often, so the historical record is dense even though the live feed is sparse. This local capture is what lets a site keep a detailed history through periods when bandwidth or connectivity would never have allowed that data to be streamed in real time.
It is easy to confuse onboard datalogging with historian backfill because both end with gaps in the central record being filled, but they operate at opposite ends of the chain and solve different halves of the problem. Onboard logging is a source-side capability: it captures and preserves the data at the field device the instant it is measured, so the information exists even while it cannot be sent. Historian backfill is a server-side process that inserts or repairs data in the central historian, often by requesting whatever the field device managed to keep. Backfill has nothing to insert unless something at the source kept the data in the first place.
This distinction determines what is actually recoverable after an outage. If the RTU logged onboard, the historian can be backfilled with the true, timestamped readings for the entire gap, and the record ends up complete. If the RTU did not log, then no server-side cleverness can recover measurements that were never stored anywhere; the historian can only interpolate or leave a hole, because the underlying values are simply gone. Server-side interpolation is a guess between two known points, whereas onboard logging delivers the real values that occurred in between.
In practice the two are designed to work together rather than compete. The RTU's onboard log is the authoritative source of truth for what happened at the site, and the historian's backfill mechanism is the means by which that truth is pulled into the central record once the link returns. Understanding which layer is responsible for capture and which for reconstruction prevents the common mistake of assuming a central historian can fill any gap, when in reality it can only fill gaps that a field device took the trouble to record.
Onboard datalogging is the engine behind store-and-forward, the pattern in which a device stores readings during an outage and forwards them when it can. Store is exactly the onboard log; forward is the replay that empties it upstream when connectivity returns. Without the log there would be nothing to forward, so onboard logging is not a separate feature from store-and-forward but its foundation. When people say a site rides through an outage and backfills afterward, the onboard log is what made that possible.
The practical constraint is buffer size, because non-volatile memory is finite and a long outage generates a lot of readings. The buffer must hold enough logged data to cover the longest outage the site is likely to see, and if it fills before the link returns, the device faces a choice between overwriting the oldest data or refusing new writes, either of which loses information. Sizing the buffer therefore comes down to the logging rate multiplied by the worst-case outage duration, which is why a site that samples densely or sits in poor coverage needs more memory than a site that logs sparsely on a reliable link.
In a cloud SCADA platform, onboard logging is what turns an outage into a delay instead of a loss, and the platform is where that recovery becomes visible. When a site reconnects and streams its backlog, Merobix ingests the timestamped readings so the gap fills in with real history rather than an interpolated line, and operators can see plainly that the record is complete. That end-to-end behaviour, capture at the edge, hold in non-volatile memory, replay on reconnect, and reconcile in the cloud, is what lets remote sites deliver an unbroken record despite the unreliable links they live on.
They are two parts of the same behaviour rather than separate features. Onboard datalogging is the store: the RTU records timestamped readings into non-volatile memory as they occur. Store-and-forward adds the forward: when the link returns, the device replays those logged readings upstream to backfill the gap. Onboard logging is the foundation, because without a local record there would be nothing for store-and-forward to send once connectivity is restored.
Because readings replayed after an outage arrive long after they were taken, and without their original timestamps they would be misattributed to the moment they finally reached the server. Stamping each reading with the true time of measurement at the device preserves its correct position on the timeline no matter how long it waited in the buffer. This is what lets a trend reconstructed after an outage show events at the times they actually happened rather than bunched at the reconnection instant.
No. Server-side historian backfill can only insert data that some field device actually captured and kept; it cannot recover measurements that were never stored anywhere. If the RTU had no onboard logging, the historian can at best interpolate a guess between the last known point before the outage and the first after it, which is not the same as the real values. That is why onboard logging at the source is essential for a truly complete record.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.