Edge Computing Patterns for High-Performance IIoT

Edge computing patterns for industrial data pipelines

Edge computing places selected data collection, buffering, transformation, and decision support close to the industrial process. It is valuable when latency, intermittent connectivity, data volume, or site autonomy makes a fully central design unsuitable.

Networks can be unavailable, latency varies, and high-frequency signals can exceed the capacity or economics of an upstream connection. Safety-critical control remains in PLC and safety systems; edge software may support monitoring and operational workflows without replacing that boundary.

The five patterns below are design options, not universal defaults. Their behavior depends on buffer capacity, connector acknowledgements, workload, topology, and recovery design. For rollout and governance context, begin with the industrial edge platform page.

The Five Patterns (Quick Reference)

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

Why Edge Computing Matters

Consider a plant with mixed low-frequency process values, event signals, and high-frequency diagnostic data. Treating every signal identically can overload site links or create unnecessary retention cost. The correct design starts by measuring tag count, sampling profile, payload size, outage tolerance, and the detail required for investigation.

Edge computing solves this by filtering, aggregating, and processing data locally, then shipping only meaningful summaries upstream. In production, this usually works best as part of a broader industrial data platform rather than as an isolated gateway project.

Pattern 1: Buffer at the Edge

Instead of depending on a live link for every tag change, the edge keeps a local buffer between the source and everything upstream. This section is the short version; The edge historian: buffering, store-and-forward and backfill covers buffer sizing, replay and backfill in full.

How It Works

• Raw sensor data flows into the edge gateway via Modbus, S7, or OPC UA.
• A local persistent buffer holds the stream whenever the next hop cannot take it.
• Filters can reduce the volume before it leaves the site (thresholds, deadbands, debouncing). Where aggregation is needed, it is a separate design decision with its own loss of detail.
• What is published upstream is what the consumers actually need.

In Proxus, the buffer lives in a messaging container that runs next to the gateway process; there is no database at the edge. Delivery to the hub is held there for 48 hours by default (configurable up to 30 days per gateway) and replayed with the original timestamps. At the source, Proxus scales, converts and filters values; it does not claim to aggregate at the edge.

Operational Benefits

• Data-loss risk reduction: The buffer persists to local disk during outages.
• Replay capability: When connectivity is restored, eligible buffered data can be replayed with its original timestamps. Completeness and ordering depend on capacity, retention, acknowledgements, and target recovery behavior.

Pattern 2: Local Decision Making

Some decisions cannot wait. A safety alarm that takes 200 ms to trigger is a liability on the factory floor.

Examples of Edge Decisions

• Maintenance Alert: Machine temperature exceeds 85°C → instantly trigger a high-priority maintenance ticket.
• Stack light activation: Line stopped for >30 seconds → trigger visual/audible siren.
• Sensor fallback: Primary pressure sensor fails → switch to backup sensor autonomously.

Implementation with Proxus

In Proxus these run as rules on the Edge Gateway, and they keep running when the network is down.

Approach 1: Expression rules (no code) Process engineers define thresholds and conditions as expressions; anomaly rules cover Z-score, IQR, moving average, rate of change, drift, flatline and gap detection. The practical goal is local handling with minimal network dependency. In pseudo-code:

IF Temperature > 85°C AND NOT(Alarm_Triggered)
THEN Publish MQTT Alert "Line1/Maintenance/ThermalWarning"
AND Trigger Webhook "Create_SAP_WorkOrder"

Approach 2: C# functions For more specialized correlations, developers write C# functions against the Proxus SDK, built and deployed from the hub. They can implement local evaluation logic that combines multiple signals, applies validation windows, and decides whether an event should be published, escalated, or ignored. The key editorial point is not the exact SDK surface, but the architectural boundary: the logic executes locally so actions are not blocked by a round trip to the cloud.

Pattern 3: Fan-Out to Multiple Targets

Industrial data is rarely consumed by a single system. A plant needs to send the exact same payload to:

• Cloud Analytics (Machine Learning)
• Time-Series Databases (Dashboards)
• Message Brokers (Data Lakes)
• Enterprise Systems (SAP/Oracle)

The Point-to-Point Hell

Traditionally, teams build custom connectors for each consumer: PLC → Cloud, PLC → InfluxDB, PLC → SAP. This creates substantial maintenance overhead and increases the risk of data inconsistency.

The Proxus Fan-Out Pattern

PLC → Edge Gateway → Proxus UNS (MQTT Broker)
 ├─→ Cloud Analytics (Subscribes to Topic)
 ├─→ TimescaleDB (Subscribes to Topic)
 └─→ SAP (REST target)

Result: One source of truth. Add new consumers without touching the PLC or the Edge Gateway. The integrations list shows the destination types available, from InfluxDB and SQL Server to Apache Kafka and Azure IoT Hub.

Pattern 4: Caching and Intelligent Aggregation

Not all data deserves the same bandwidth priority.

These tiers are a design pattern, not a product feature list. In Proxus, the edge scales, converts and filters values at the source; summaries such as averages are usually computed downstream, in the historian or in the consuming system.

Pattern 5: Circuit Breaker and Graceful Degradation

What happens when your factory loses internet? Cloud-dependent IIoT systems crash or freeze HMIs until timeouts occur.

A well-designed edge behaves like a circuit breaker:

• Closed (normal): Data flows to the central server.
• Open (connection lost): Retry pressure is limited and local workloads continue without waiting for the central connection.
• Half-open (recovery): The connection is probed and buffered delivery resumes in order.

In Proxus, rules keep running on the gateway while the hub is unreachable, and every outbound target (databases, MQTT, Kafka, REST and the others) queues at the gateway with the same retention. When the target comes back, the queue is written in order, at least once, so a consumer should tolerate the occasional duplicate.

Conclusion: The Edge is Your Advantage

Manufacturing plants that push the right logic to the edge can improve resilience, shorten decision loops, and reduce unnecessary upstream traffic. The practical benefit is not a slogan about winning the market; it is keeping critical decisions closer to the process when latency, bandwidth, or outage tolerance matters.

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 can edge computing reduce cloud costs?

There is no defensible universal percentage. Measure the raw and selected data volume, storage class, retention period, egress path, and query workload. Smart filtering may reduce upstream volume, but it can also remove diagnostic detail.

What happens when the edge device itself fails?

Failure handling depends on the selected topology, storage, health detection, source connection ownership, and recovery procedure. Store and Forward can reduce loss risk for eligible buffered data, but it is not a substitute for gateway recovery, redundancy, backup, or tested operating procedures.

Can edge rules replace PLC logic?

No, and they should not. PLC logic handles deterministic, safety-critical control (motor interlocks, emergency stops). Edge rules handle higher-level business logic - OEE calculations, predictive maintenance scoring, cross-device correlation, and enterprise notifications. The two layers complement each other.

References

1. IEC 62443 - Industrial cybersecurity standard, relevant to securing edge deployments in OT networks.
2. AWS IoT Greengrass / Azure IoT Edge - Cloud vendor edge frameworks, useful for comparison against protocol-native edge platforms like Proxus.
3. ISA-95 / IEC 62264 - Enterprise-control integration standard defining the hierarchical layers where edge computing operates (Level 1–2).

Further reading: Read Unified Namespace architecture: a practical guide or learn how to build logic at the edge.