Store-and-Forward Architecture: Why Remote Industrial Sites Can’t Afford Data Gaps

July 20, 2026·By ketsoladmin·Blog

Store-and-Forward Architecture: Why Remote Industrial Sites Can't Afford Data Gaps

Written by Ketsol Manufacturing Suite

Industrial Data & AI Practitioners | OT/IT Convergence Specialists.

Ketsol is an industrial technology firm specialising in data infrastructure for manufacturing environments. With over 15 years of experience across discrete and process industries, the team has delivered large-scale data architecture and IIoT implementations, including work with Tier-1 manufacturers.

Core expertise includes Unified Namespace (UNS) architecture, industrial data modelling, and AI readiness for production systems. Ketsol combines deep operational understanding with modern data engineering practices to bridge the gap between OT and enterprise systems.

Published: Jul 2026

A pumping station on the edge of a refinery. A water treatment plant is an hour from the nearest town. A tank farm where the closest connectivity is a cellular modem or a satellite uplink. These sites run around the clock, but their network connection doesn’t always keep up.

When the WAN drops, most plant teams assume the SCADA screen or historian trend is simply “down” for a few minutes. In many industrial setups, that’s not what actually happens. The connectivity gap becomes a permanent gap in the data. No trend line for that window. No alarm history. No proof that a batch stayed within spec.

This is the exact problem store-and-forward architecture is built to solve. This piece breaks down how it works, how it prevents data loss during a WAN outage, and where Indian manufacturers are already leaning on it to keep remote sites audit-ready.

What Happens When a Remote Manufacturing Site Loses Connectivity?

Most legacy setups stream data continuously from PLC to SCADA, SCADA to historian, historian to head office over a single network path. It works fine as long as the link stays up.

The moment that link drops, a few things happen at once:

The historian stops receiving new values, but the process doesn’t stop running.
Whatever happens during the outage, a temperature spike, a valve state change, or a batch event, goes unrecorded at the central system.
When the connection returns, there’s a blank stretch in the trend with no way to reconstruct it.
Someone eventually notices the gap, usually while pulling a report, and has to explain it after the fact.

For a site on solid fibre, this rarely comes up. For a remote or unmanned site running on cellular, radio, or satellite backhaul, it’s a recurring risk, and in regulated or safety-critical environments, an unrecorded gap can be as serious as a bad reading.

How Do You Prevent Data Loss During a WAN Outage in Manufacturing?

The fix isn’t a more reliable network; remote sites will always have weaker links than a plant on the main grid. The fix is making sure that the network being down doesn’t mean the data is lost.

That’s what store-and-forward does. Instead of relying on a live, uninterrupted stream, the edge device holds the data locally the moment it senses the uplink is gone, and sends it on once the connection is back in the correct order, with nothing skipped.

In practice, this means:

Every tag value is written to a local buffer at the edge, not just forwarded and forgotten.
The buffer keeps growing for as long as the WAN stays down, limited only by local storage capacity.
On reconnect, queued data forwards automatically and in sequence, no manual export, no reconciliation.
The central historian ends up with a complete timeline, whether the link was up for 30 seconds or 3 hours.

How Does Store-and-Forward Architecture Work at the Edge?

Store-and-forward sits between the field device and the network, not between the network and the head office. That distinction matters. If the buffering only happens centrally, an edge-side outage still creates a gap that the buffer needs to live on the same side of the failure as the data source.

A typical flow looks like this:

The edge gateway reads tag data from the PLC, DCS, or RTU at its native poll rate, regardless of WAN status.
Each value is timestamped and written to local storage in real time.
The gateway continuously checks WAN availability in the background.
When the link is live, data forwards immediately ; the buffer only grows when the connection is genuinely down.
When the link returns, queued records drain out first, oldest to newest, before live data resumes.

Because the timestamping happens at the point of capture, not at the point of arrival, the resulting record reflects what actually happened on the plant floor, not what the network allowed through.

Where Does Protocol Conversion for Remote Industrial Sites Matter Most?

Store-and-forward tends to matter most where three conditions overlap: the site is unmanned or lightly staffed, the network is inherently unstable, and the data has compliance, safety, or cost implications if it’s incomplete.

That combination shows up across a fairly consistent set of use cases:

Tank farms and terminals’ custody transfer and inventory data can’t have blind spots; a missing hour is a reconciliation headache with a finance team attached.
Water and wastewater plants’ regulatory reporting often requires continuous records, not best-effort ones.
Pipeline and pumping stations are spread across long distances with inconsistent cellular coverage.
Substations and utility-adjacent sites where IEC 60870-5-104 and DNP3 reporting to a control room need to stay intact through link flaps.
Multi-site rollouts with a mix of connectivity quality, one weak link at one site, shouldn’t mean one broken dashboard at head office.

In each of these, protocol conversion and store-and-forward work together. The gateway is already translating Modbus, S7, or MELSEC into OPC UA, IEC-104, or DNP3, so buffering that same converted data locally is a natural extension of the job it’s already doing.

How Does Hot-Standby Redundancy Gateway Design Add Another Layer of Protection?

A WAN outage isn’t the only failure mode worth planning for. The gateway itself can fail a power blip, a hardware fault, firmware crash, and if it’s the only thing sitting between the field and the rest of the stack, that single point of failure undoes the benefit of store-and-forward entirely.

This is where hot-standby redundancy gateway design comes in. Two gateways run in an active/standby pair, sharing state continuously over a dedicated sync link:

Tag values, subscription lists, and in-flight write queues stay mirrored between both nodes at all times.
If the active gateway fails, the standby takes over inside the SCADA or IEC-104 timeout window before the master side even registers a disconnect.
In-flight reads and writes complete on whichever node survives, so nothing gets half-written or dropped mid-transaction.
Combined with store-and-forward, this means the site is protected against both a network failure and a hardware failure — not just one or the other.

For a remote site with no one on-site to power-cycle a gateway at 2 a.m., that failover behaviour is often the difference between a non-event and a multi-hour outage.

Key Insights

A dropped WAN link doesn’t have to mean a permanent data gap — store-and-forward buffers at the edge, not centrally.
Buffering only helps if it happens at the point of data capture, before the network hop, not after it.
Store-and-forward and protocol conversion are naturally paired — the gateway is already touching every tag, so local buffering adds minimal overhead.
Hot-standby redundancy protects against the gateway itself failing, which store-and-forward alone doesn’t cover.
Remote, unmanned, and compliance-sensitive sites benefit the most, since manual recovery isn’t realistically an option for them.

Conclusion

Remote sites will always have weaker, less predictable connectivity than a plant sitting on the main grid, which isn’t something a network upgrade fully solves. What can be solved is what happens to the data when that connectivity drops. Store-and-forward architecture, paired with hot-standby redundancy at the gateway, means a WAN outage becomes a short delay in delivery rather than a hole in the record.

Ketsol’s Edge Gateway runs store-and-forward and hot-standby redundancy natively, alongside protocol conversion for 50+ industrial protocols as a standalone converter or paired with KMS for full edge-to-cloud visibility. If your remote sites have ever had a trend gap you couldn’t explain, that’s usually where the conversation starts.

Frequently Asked Questions:

What is store-and-forward in industrial IoT?

Store-and-forward is an edge-level buffering method where data is written to local storage the moment it’s captured, then transmitted once network connectivity is restored. It ensures no readings are lost during a WAN outage, regardless of how long the disconnection lasts.

2. How do you prevent data loss during a WAN outage in manufacturing?

Data loss during a WAN outage is prevented by buffering values locally at the edge device as they’re generated, rather than relying on a continuous live stream. Once the connection returns, the buffered data forwards automatically in the correct sequence.

3. What is a hot-standby redundancy gateway, and how does failover work?

A hot-standby redundancy gateway runs two units in an active/standby pair that continuously sync state over a dedicated link. If the active unit fails, the standby takes over within the SCADA or IEC-104 timeout window, so the connected systems don’t register a disconnect.

4. Does store-and-forward work with protocol conversion at remote industrial sites?

Yes. Since the gateway is already converting protocols like Modbus, S7, or MELSEC into OPC UA, IEC-104, or DNP3, it can buffer that same converted data locally without added complexity — making it well-suited to remote and unmanned sites with unreliable connectivity.

5. Is store-and-forward only useful for unmanned or remote sites?

It’s most valuable there, since there’s no one on-site to notice or manually recover from an outage. But any site with compliance reporting requirements, custody transfer data, or safety-critical monitoring benefits from having a complete, gap-free record regardless of staffing.