INDUSTRIAL DATA RELIABILITY
Industrial Store&Forward for Reliable Data Delivery
With industrial Store&Forward, vNode keeps industrial data at the edge when an upstream connection is unavailable. Instead of discarding new records during an MQTT, WAN or central-system outage, vNode buffers supported data locally and forwards the backlog after connectivity returns. Buffer duration and recoverability depend on the configured architecture, local storage capacity and documented module behavior.
Network outage: what happens?
vNode keeps collecting data, stores it locally, and automatically forwards it when the connection is restored.
1 Collect
PLC/OT acquisition continues.

! Connection fails
Broker, WAN or Central is unavailable.

2 Store locally
Pending records wait at the edge.

Reconnect & replay
Backlog is forwarded according to the configured data path.


When connection is restored
vNode automatically forwards the stored data in order and continues with real-time publishing.


DEFINITION
What Is Store&Forward in Industrial IoT?
Store&Forward is persistent edge buffering: the gateway retains newly acquired industrial records on local storage when the configured upstream destination is unavailable, then forwards the backlog once connectivity returns. This is different from a simple retry (which does not persist new data generated during the outage) and from a volatile in-memory queue (which can be lost on a restart or power loss).
ARCHITECTURE
What Happens When the Network or MQTT Broker Goes Down?
Normal
vNode acquires industrial data and sends it to the configured destination.
Failure detected
WAN, broker, Central node or destination becomes unavailable.
Store
New records are retained locally per the configured Store&Forward mechanism and available storage.
Continue acquisition
OT-side data collection continues independently of the unavailable path, within system limits.
Reconnect
vNode detects that the destination/path is available again.
Replay
Buffered records are forwarded in the documented order while live acquisition continues.
Caught up
The backlog drains and normal live delivery resumes.
Connect OT to IT
Reliable. Secure. Flexible.
PLC / OT
Industrial data sources

Data
vNode Edge
Process. Buffer. Monitor. Deliver.

Data
IT / Cloud
Publish to enterprise systems

NOT THE SAME THING
MQTT Store&Forward vs. MQTT QoS
MQTT QoS governs message delivery behavior in an MQTT session. Store&Forward addresses a different problem: what happens to new industrial records generated while the upstream path itself is unavailable.
QoS
Controls MQTT delivery semantics between MQTT peers.
Store&Forward
Retains pending telemetry locally during an outage and replays it later.
Production Architecture
Often uses both: appropriate MQTT QoS plus a bounded persistent edge buffer.
BEHAVIOR AND LIMITS
Buffering, Sizing and Architecture Details
See the OT/IT Reverse Connection Solution for the related outbound-only pattern.
Pending records are retained in a persistent local buffer. Restart/power-cycle behavior and capacity depend on the exact module and version; confirm against current documentation.
Buffered records replay with their original timestamp in documented order. Duplicate behavior can vary by destination; confirm exactly-once vs. at-least-once for your path.
Size storage as events/second × bytes/event × outage duration × overhead, e.g. ~185 events/s × 250 bytes × 24h ≈ 4.0 GB before overhead. Bounded by disk capacity, not unlimited tag licensing.
A remote vNode node keeps acquiring and buffering local OT data during a central-connection outage, then replays the backlog once reconnected.
Buffered records can forward to MQTT brokers and cloud platforms like AWS or Azure once connectivity returns, where the data path supports it.
SQL databases and historians may also be supported targets; confirm buffering semantics for your module and version.
Local buffering complements segmented, outbound-only architectures without OT acquisition depending on IT/cloud availability.
OBSERVABILITY
Monitoring the Buffer
Track these metrics for the configured data path. Confirm which are currently exposed in the vNode UI/API version you are running; where one is not yet available, treat it as a monitoring improvement item for your deployment.
Queue Depth
Records currently waiting in the local buffer.
Oldest Record Age
How long the outage has been accumulating a backlog.
Storage Remaining
Capacity margin left on the local buffer.
Replay Rate
Speed at which the backlog is draining after reconnection.
Replay Lag
Estimated time until the buffer is fully caught up.
PRODUCTION PROOF
Real-World Example: Senegal Wind Farm to UK Control Center
vNode’s published reliability case describes a remote node at the Taiba N’Diaye wind farm collecting substation data and buffering it locally when the connection to the UK control center is unavailable. The architecture demonstrates Store&Forward in a real distributed industrial deployment; this describes a measured deployment, not a universal guarantee for every project.

Test the Failure, Not Just the Happy Path
Disconnect the broker or WAN, keep collecting plant data, reconnect and measure exactly how the backlog is recovered.
Frequently Asked Questions
What is Store&Forward in an industrial gateway?
Industrial Store&Forward is persistent edge buffering: new industrial records are retained locally when the configured upstream destination is unavailable, then forwarded once connectivity returns.
How does MQTT Store&Forward work?
The gateway continues acquiring OT data during an MQTT outage, stores pending records locally, and replays them to the broker in order once the connection is restored.
Is MQTT QoS the same as Store&Forward?
No. MQTT QoS and session behavior solve MQTT delivery problems; Store&Forward retains telemetry generated while the upstream path itself is unavailable.
What happens to PLC data when the Internet connection goes down?
In a configured Store&Forward path, the edge node continues acquiring supported data and retains pending records locally until the upstream destination becomes available again, subject to local storage and configured limits.
Does vNode store data on disk or only in memory?
Store&Forward is designed around persistent local storage rather than a volatile in-memory queue; confirm the exact persistence mechanism for your specific module and version against current vNode documentation.
How long can vNode buffer data?
Buffer duration depends on event rate, average payload size, outage length and available local storage; size it using the conceptual formula above rather than assuming unlimited buffering.
Are original timestamps preserved after reconnection?
Buffered records are intended to replay with their original acquisition timestamp; confirm exact behavior for your specific data path.
In what order is buffered data replayed?
Buffered records are forwarded in the documented order for the configured path while live acquisition continues in parallel.
What happens if the local disk becomes full?
No persistent buffer is physically unlimited: behavior when storage fills depends on the configured capacity and module; plan capacity using the sizing guidance above rather than assuming it self-manages indefinitely.
Can Store&Forward survive a reboot or power loss?
A production design can significantly reduce data gaps, but an unconditional zero-loss guarantee requires defined capacity and failure assumptions: disk failure, full storage, interrupted writes and downstream-system behavior must all be considered.
Does Store&Forward work with AWS and Azure?
Where the specific vNode data path supports it, buffered records can be forwarded to cloud platforms such as AWS or Azure once connectivity returns; confirm exact supported destinations against current module documentation.
Can I monitor buffer depth and replay progress?
Queue depth, oldest-record age, storage remaining, replay rate and replay lag are the metrics worth tracking; confirm which are exposed in the vNode UI/API version you are running.


