What is Store and Forward in IIoT?

Why upstream connectivity cannot be assumed

Industrial connections can be interrupted by cabling faults, wireless conditions, upstream service incidents, firewall changes, or target maintenance. A data architecture should define what happens to each signal while its destination is unavailable.

When your Industrial IoT (IIoT) architecture relies mostly on pushing data straight from the PLC to the cloud (direct-to-cloud), a network outage can become more than temporary visibility loss-it can create data gaps. If a machine produces 5,000 units during a 30-minute internet outage and that telemetry isn't recorded, your OEE, traceability, and shift reports may become materially inaccurate.

This is a common failure mode that the Store and Forward architectural pattern is designed to mitigate.

Outcomes depend on workload profile, hardware capacity, and deployment topology.

What is Store and Forward?

Store and Forward is a resilient networking and data management technique used heavily in industrial Edge Computing.

Instead of a sensor or PLC attempting to send data directly to a remote server, it sends the data to a local Edge Gateway sitting right next to the machine. Under normal conditions, the Edge Gateway immediately forwards this data to the central Historian or Unified Namespace (UNS).

If the central connection becomes unavailable, eligible telemetry can be persisted in a configured local buffer. When connectivity returns, the gateway attempts delivery according to its retention, ordering, retry, acknowledgement, and target-health rules. Samples outside capacity or retention limits cannot be assumed recoverable.

How the Store and Forward Mechanism Works

A robust Store and Forward system operates continuously through three distinct phases:

Phase 1: The Disconnection (Store)

When the gateway detects that a configured target is unreachable, it limits retry pressure and persists eligible payloads with their timestamps and quality metadata. What is stored depends on connector behavior, selection policy, available disk, and retention configuration.

Phase 2: Local Autonomy

While disconnected, the factory isn't necessarily blind. Because the Edge Gateway has local compute capabilities, local HMI screens and localized dashboards can continue to display real-time machine statuses by querying the Edge Gateway directly. Critical safety rules and local alarms continue to trigger independently of the cloud.

Phase 3: The Reconnection (Forward)

When the link is re-established, replay should be rate-limited so the target and network are not overwhelmed. Historical and live traffic require an explicit prioritization and ordering policy; recovery is complete only after acknowledgements and target persistence are verified.

Why Store and Forward is Critical for IIoT

Implementing this pattern provides three core benefits for enterprise manufacturing:

1. Data-loss risk reduction: Regulatory compliance (like FDA 21 CFR Part 11 or aerospace traceability) requires an unbroken chain of data. With durable local storage and replay policies, store and forward helps preserve historical logs during IT infrastructure hiccups.
2. Time-Series continuity: Original timestamps and ordering metadata help consumers reconstruct an event window. Consumers must still handle late, duplicate, or out-of-order delivery according to the connector contract.
3. Bandwidth management: Local storage may be combined with compression or aggregation, but those transformations change the retained evidence and must be governed separately.

How Proxus Handles Disconnections at the Edge

When designing the Proxus Edge Computing platform, we built Store and Forward deeply into the core architecture, rather than bolting it on as an afterthought.

A Proxus Edge Gateway can use persistent local storage for eligible outbound data. Buffering must be sized from measured bytes per second, expected outage duration, filesystem headroom, write endurance, retention policy, and replay capacity. The system requirements and connector documentation should be checked for the deployed version.

Features:

• Persistent buffering: Eligible data can be written to disk rather than relying only on memory; filesystem and power-loss behavior must still be tested on the selected hardware.
• Stateful replay: Delivery resumes according to connector state, acknowledgement, ordering, retry, and retention configuration.
• Configured policy: Buffer size, retention, backpressure, recovery rate, and monitoring are deployment decisions, not universal defaults.

Conclusion

Hoping that your factory's internet connection will rarely drop is not an engineering strategy.

In industrial environments, network volatility is common. Store and forward through edge gateways can reduce dependence on continuous upstream connectivity, but the outcome remains bounded by local capacity, source capture, connector acknowledgements, target health, and tested recovery procedures. It is one resilience mechanism inside the Industrial Data Platform, not proof of end-to-end delivery under every failure mode.

When this may not be suitable

• Lower-frequency telemetry may not justify full distributed complexity.
• Small single-line plants may prefer simpler architectures first.
• Strict legacy constraints may require phased adoption.
• Safety-critical closed-loop control should remain in PLC/Safety PLC layers.

Results vary with workload, hardware, and topology.

Frequently Asked Questions

How much local storage does a Store and Forward buffer need?

Measure encoded bytes per second under a representative workload, multiply by the required outage window, then include filesystem headroom, indexes, write amplification, and replay backlog. Confirm the result on the selected hardware and configure monitoring before production use.

Does Store and Forward improve message ordering?

It can preserve source order within a defined stream, but end-to-end ordering also depends on concurrent producers, retries, acknowledgements, partitions, and the destination. Consumers such as OEE calculations should use event timestamps and explicitly handle late or duplicate data.

How is this different from MQTT QoS 1/2?

MQTT QoS ensures delivery between the client and broker during an active session. Store and Forward operates before the MQTT handshake - it persists data locally when the broker is unreachable. They are complementary: S&F handles network-down scenarios, while QoS improves in-flight delivery reliability.

References

1. MQTT v5.0 OASIS Standard - Defines QoS levels and session state that complement Store and Forward patterns. mqtt.org
2. IEC 62443-3-3 - Security requirements for industrial systems, including data integrity during network disruptions.

Explore the Proxus Edge Architecture →