Dec 23, 2025 · 7 min read
Methodology notes
What is Store and Forward in IIoT?
Network outages in manufacturing are inevitable. Learn how the Store and Forward mechanism in Edge Computing prevents critical data loss during cloud disconnections.
- Evidence level: Medium (field observations + public standards; not a universal benchmark).
- Measurement scope: Performance and economic outcomes vary by hardware, topology, workload shape, sampling profile, and process constraints.
- Primary references: IEC 62443, ISA-95 / IEC 62264, NIST SP 800-82r3.
- Implementation docs: Edge Architecture and Unified Namespace.
The Myth of 100% Factory Uptime
I've seen factories lose millions in data during network outages that lasted just 45 minutes, only to realize they had no Store and Forward mechanism in place. In an ideal world, every machine on the factory floor maintains a flawless, multi-gigabit connection to the cloud 24/7/365. In the real world of manufacturing, forklifts sever Ethernet cables, factory Wi-Fi degrades near massive metal presses, telecom providers suffer 5G micro-outages, and IT departments occasionally misconfigure firewalls.
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).
However, if the connection to the central server goes down, the Edge Gateway automatically switches to "Store" mode. It buffers incoming telemetry locally onto its internal hard drive. Once the network connection is restored, it automatically "Forwards" all the saved data to the central server in the exact chronological order it was received.
How the Store and Forward Mechanism Works
Production PLC
Edge Gateway
Local SSD Buffer
Write-Ahead Log
Central Datacenter
A robust Store and Forward system operates continuously through three distinct phases:
Phase 1: The Disconnection (Store)
The moment the Edge Gateway detects that the central broker or cloud database is unreachable, it halts all outbound transmission attempts. Instead of discarding the incoming 100-millisecond PLC data, it writes every single payload-complete with localized, high-precision timestamps-into an internal, high-speed disk buffer.
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 network link is re-established, the system doesn't just dump all the saved data at once (which could overwhelm the network or crash the central database). Instead, it enters a structured Replay phase. It streams the buffered historical data sequentially while simultaneously weaving in the new, real-time data. To the central database, it appears as if the outage rarely happened.
Why Store and Forward is Critical for IIoT
Implementing this pattern provides three core benefits for enterprise manufacturing:
- 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.
- Time-Series Integrity: In predictive maintenance, the sequence of events is everything. If data packets arrive out of order, anomaly detection algorithms will fail. A proper store and forward mechanism replays data chronologically, preserving the exact timeline of a machine failure.
- Bandwidth Management: By storing data locally, the edge can also compress or aggregate it before forwarding, saving massive amounts of GSM/LTE bandwidth.
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 utilizes an incredibly fast, internal Write-Ahead Log (WAL). Buffering capacity depends on storage and data volume:
Typical scenarios (with 500GB SSD):
- Low-frequency telemetry (500 tags @ 1Hz, <10KB/sample): 30–50 days of buffering
- Moderate frequency (2,000 tags @ 10Hz, ~100KB/sample): 7–14 days of buffering
- High-frequency (10,000 tags @ 100Hz, 1MB+/sample): 4–6 hours of buffering
Features:
- Persistent Buffering: Data persists to disk, not RAM. If the gateway loses power during outage, data is safe.
- Stateful Replay: When the connection to the Proxus Central Platform is restored, the Gateway intelligently resumes pushing MQTT payloads to the Unified Namespace exactly where it left off.
- Zero-Configuration: You don't need to write complex Python scripts to handle disconnections. It is a native, out-of-the-box feature of the Proxus Edge orchestration engine.
For critical data, avoid relying solely on in-memory buffers (RAM). If the server loses power during a network outage, RAM buffers are erased. Ensure the Edge Gateway can persist its Store and Forward buffer to a physical solid-state drive (SSD).
Conclusion
Hoping that your factory's internet connection will rarely drop is not an engineering strategy.
In industrial environments, network volatility is common. By deploying Store and Forward architectures via robust Edge Gateways, manufacturers can decouple their local machine reliability from their wide-area network stability. The result is a highly continuous, resilient, and trustworthy data pipeline - no matter what happens to the cloud.
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?
It depends on your data volume and expected outage duration. A typical production line generating 500 tags at 1-second intervals produces roughly 40 MB/hour. Proxus Edge uses a persistent queue (disk-backed) so even multi-day outages on an industrial PC with 64 GB of storage can buffer comfortably. Configure retention policies to match your worst-case network SLA.
Does Store and Forward improve message ordering?
Yes. The buffer operates as a FIFO (First-In, First-Out) queue. When the connection is restored, messages are replayed in exact chronological order. This is critical for OEE calculations and time-series analytics where event sequence matters.
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
- MQTT v5.0 OASIS Standard - Defines QoS levels and session state that complement Store and Forward patterns. mqtt.org
- IEC 62443-3-3 - Security requirements for industrial systems, including data integrity during network disruptions.