What is Store and Forward in IIoT?

This article is the short definition. For buffer sizing, what really happens on replay and how to backfill gaps, read the full guide: The edge historian: buffering, store-and-forward and backfill.

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.

• Bounded: Buffer capacity and retention
• Tested: Recovery and replay behavior

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. HMIs and SCADA keep reading the controllers as before, and rules that run on the edge gateway keep evaluating and raising local alarms independently of the cloud. Safety functions stay where they belong, in the PLC and safety systems. Which views remain available depends on where they are hosted: a dashboard served from a central site is unavailable to the plant until the link returns.

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

In Proxus, store and forward is part of how the edge is built. A gateway is one process plus a messaging container next to it, and that container holds the local buffer on disk. There is no database at the edge.

What it does:

• Buffered delivery to the hub: while the hub is unreachable, data is held at the gateway for 48 hours by default, configurable up to 30 days per gateway, and replayed with the original timestamps when the link returns.
• Every outbound target queues too: databases, MQTT, Kafka, REST, InfluxDB, cloud IoT services and the other target types queue at the gateway while their destination is unreachable, with the same retention, and are written in order when it comes back.
• At-least-once delivery: after a reconnect a consumer may occasionally see a duplicate, so writes should be idempotent or deduplicated on a key.
• Visible backlog: each target shows its status, last success, last failure, last error and, while unreachable, how many queued messages are waiting at the gateway.
• A licensing boundary: data above the gateway's licensed rate is neither delivered nor buffered, so size the licence for the real rate, including bursts.

Buffering still has to be sized from measured bytes per second, the outage window you need to survive and the disk you have; check the architecture and outbound targets documentation for the deployed version.

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.