Resilience of IIoT data at the edge: Buffering and store-and-forward

Selecting the architectural approach for implementing buffering and store-and-forward mechanisms on edge gateways is crucial for ensuring continuous transmission of critical data in unstable network conditions.

Reasons for IIoT data loss at the edge and the necessity of buffering

The Industrial Internet of Things (IIoT) is transforming manufacturing by enabling the collection of vast amounts of data from sensors and devices at the physical layer. However, reliance on stable network connectivity to transmit this data to cloud platforms or central systems creates significant vulnerabilities. Network failures and power outages are primary causes of IIoT system downtime. According to Deloitte, unplanned downtime costs industrial manufacturers approximately $50 billion annually, with a significant portion of these losses attributed to connectivity issues rather than equipment failures.

The loss of critical IIoT data, such as product quality metrics, safety parameters, or energy consumption data, can lead to substantial financial losses and production downtime. The average cost of a data breach in the industrial sector is $5.56 million, an 18% increase compared to 2023. IBM reported that in 2026, the average cost of a data breach in the industry was $5.00 million. These figures underscore that data loss is not merely a technical problem but a direct threat to a company's competitiveness and reputation.

Therefore, buffering and store-and-forward mechanisms on edge gateways are not optional features but a critical component of IIoT architecture. They enable temporary data storage directly on devices closer to the source of generation and transmit them once connectivity is restored. This ensures operational continuity and data integrity even in conditions of unstable or completely absent network connection.

Data buffering mechanisms at the edge: From protocols to file systems

Implementing robust data buffering on edge devices can range from built-in protocol features to using local databases and message queues. The choice of approach depends on the data volume, its criticality, the duration of expected outages, and the available gateway resources.

Built-in protocol features

  • MQTT Persistent Sessions: The MQTT protocol, widely used in IIoT, supports "persistent sessions." When an MQTT client establishes a persistent session (by setting the Clean Start = false flag), the broker stores information about its subscriptions and all unsent messages with Quality of Service (QoS) levels 1 and 2 while the client is offline. Upon reconnection, the client receives all missed messages without needing to re-subscribe to topics. This ensures uninterrupted communication even during temporary network interruptions.
  • OPC UA PubSub: OPC UA also offers buffering mechanisms. An OPC UA client attempts to reuse a session and corresponding subscriptions after losing connection, which allows for the use of buffered data in subscriptions and avoids data loss during short-term connection breaks. OPC UA PubSub, especially with broker-oriented transports like MQTT, can be resilient to intermittent cloud connectivity, a common requirement at the edge. Buffering works without data loss if the connection break is shorter than the subscription and session timeouts, and the buffer size for monitored items is not exceeded.

Local databases and message queues

For more complex scenarios requiring storage of large data volumes, complex queries, or extended periods of offline operation, local databases and message queues are used on edge gateways:

  • SQLite: This embedded database is widely used on edge devices due to its small footprint (around 600 KB) and self-contained design. It is ideal for offline transactional storage, queues, and device configuration management.
  • Time-series databases: For IIoT data, which are typically time series, optimized solutions exist, such as InfluxDB Edge or TimescaleDB. They are designed for efficient storage and processing of large volumes of sensor data.
  • Message queues at the edge: Solutions like RabbitMQ or Apache Kafka (via Kafka Streams at the Edge) can act as powerful buffers, collecting and storing data locally until connectivity is restored. They provide high throughput and reliable message storage.
  • Hybrid strategies: Some architectures employ a hybrid approach, combining an in-memory FIFO buffer with configurable capacity and a persistent file storage layer to ensure data durability during prolonged outages.

It is important to note that traditional databases, such as PostgreSQL or MySQL, are designed for centralized clusters with ample resources and stable connectivity, and are poorly suited for the limited resources of edge devices. Edge databases are optimized for low latency, operation without stable network connectivity, and efficient processing of large volumes of records.

Store-and-forward strategies: Ensuring data delivery reliability

The store-and-forward mechanism is fundamental for ensuring the resilience of IIoT data. It implies that when the outbound channel is unavailable, the edge device buffers data locally and then forwards it as soon as the connection is restored. This transforms a temporary network failure from potential data loss into a simple delay.

Key aspects of store-and-forward strategies:

  • Ensuring data integrity: The store-and-forward mechanism guarantees that only complete data packets are forwarded, reducing the number of errors. Industrial Ethernet switches by default use store-and-forward, checking each incoming frame for errors using a CRC checksum before forwarding.
  • Message delivery order: After connectivity is restored, buffered data must be forwarded in sequential order to ensure traceability and correctness of subsequent analytical reports.
  • Retry algorithms: Effective store-and-forward strategies include retry mechanisms with exponential backoff. This allows the device to gradually increase intervals between retry attempts to avoid overwhelming the network during unstable operation and give it time to recover.
  • Buffer size management: Buffering is not infinite. Buffer size is limited by available storage and configuration. It is crucial to carefully configure buffer size, considering expected data volume, network reliability, and device limitations. If the buffer is exceeded, the system should clearly indicate data gaps rather than concealing them.
  • Data prioritization: Not all data has the same criticality. Some edge buffers implement prioritization schemes, ensuring the primary transmission of critical alerts and anomalies, followed by regular operational data.

The application of store-and-forward is particularly relevant in environments where connectivity between the edge device and the central system is not entirely reliable: remote sites, gateways with cellular connectivity, or production floors where IT and OT networks are separated.

Choosing an architectural approach: Criteria and trade-offs

Selecting the optimal architectural approach for buffering and store-and-forward on edge gateways requires a balanced decision that considers technical capabilities and economic factors. There is no one-size-fits-all solution, as data resilience requirements can vary significantly for different IIoT systems.

Key criteria and trade-offs to consider:

  • Data volume and generation rate: High-frequency data from a large number of sensors will require greater local storage capacity and more performant buffering mechanisms (e.g., time-series databases).
  • Frequency and duration of network outages: Frequent and prolonged outages necessitate reliable persistent storage mechanisms and a significant buffer size. The average duration for resolving network failures in enterprises is 11.2 hours.
  • Data criticality: For data where loss is unacceptable (e.g., safety or product quality data), solutions with guaranteed delivery (e.g., MQTT QoS 2) and persistent disk storage must be used.
  • Available edge gateway resources: Limited resources (CPU, RAM, storage) dictate the choice of lightweight solutions, such as SQLite or built-in protocol features, as opposed to full-fledged databases or message brokers that require significant computational power.
  • Implementation and maintenance complexity: Custom solutions with local databases may offer greater flexibility but require significant effort for development, testing, and maintenance. Built-in protocol features are simpler to implement.
  • Cost: Additional local storage and computational resources on edge devices increase initial costs. However, these costs should be compared with potential losses from critical data loss and production downtime, which can amount to millions of dollars.

Standards such as ISA-95 (IEC 62264) provide frameworks for integrating enterprise and control systems, helping to define what information should flow from the shop floor, what should be managed by MES, and what should remain in the ERP system. They promote standardization of information exchange, reducing integration complexity and improving transparency of manufacturing operations.

Architectural approach selection matrix for buffering and store-and-forward

Criterion Low requirements Medium requirements High requirements
Data volume (MB/hr) < 10 MB 10-100 MB > 100 MB
Network outage frequency (hr/day) Rare (several times a month) Moderate (several times a week) Frequent (several times a day)
Network outage duration (min/hr) Short (< 10 min) Medium (10 min - 1 hr) Long (> 1 hr)
Data criticality Low (acceptable loss) Medium (desirable to retain) High (loss unacceptable)
Available edge gateway resources (CPU, RAM, storage) Limited (1-2 cores, 1-2 GB RAM, < 16 GB storage) Moderate (2-4 cores, 2-4 GB RAM, 16-64 GB storage) Significant (> 4 cores, > 4 GB RAM, > 64 GB storage)
Implementation and maintenance complexity Low (built-in features) Medium (ready-made libraries, lightweight DBs) High (custom solution development, distributed DBs)
Recommended approach MQTT Persistent Sessions (QoS 1, 2), simple file buffers SQLite, InfluxDB Edge, file queues, OPC UA with buffering Distributed time-series DBs (TimescaleDB), Edge message brokers (Kafka, RabbitMQ), hybrid solutions

The AZIOT platform supports flexible buffering and store-and-forward mechanisms on edge gateways, integrating with various protocols (MQTT, Modbus, BACnet, OPC UA) and local storage. This allows AZIOT clients to adapt solutions to unique data resilience requirements in industrial environments, ensuring continuous telemetry collection and object automation even in unstable connectivity conditions.

Choosing the right approach to buffering and store-and-forward on edge gateways is a strategic decision that directly impacts the reliability, efficiency, and economic viability of IIoT solutions. Careful analysis of requirements and trade-offs will enable the creation of a resilient architecture capable of withstanding the challenges of real industrial environments.

Explore Intecracy solutions and inbase.com.ua solutions for comprehensive data management and IoT integration.

Source list

  1. trafalgarwireless.comBest Practices for IoT Connectivity Reliability: Ensuring Zero Downtime - Trafalgar Wireless
  2. wirtek.comConnectivity reliability in industrial IoT: designing for intermittent and degraded networks
  3. ibm.comCost of a data breach: The industrial sector | IBM
  4. app.stationx.netAverage Cost of a Data Breach [2026]: Latest Statistics
  5. totalcareit.netWhy Data Breaches Cost Manufacturers More Than They Realize
  6. elpisitsolutions.comStore-and-Forward in IIoT: What It Means (and What It Doesn’t) · Elpis
  7. questdb.comEdge Buffering | QuestDB
  8. datacenterknowledge.comKey Considerations for Developing an Edge Computing Storage Strategy