Edge Computing Patterns for High-Performance IIoT

Moving logic from the cloud to the edge is no longer a luxury; it is a requirement for modern IIoT systems.

Networks fail. Latency fluctuates. Cloud costs grow faster than production output. Sensor data can exceed bandwidth. Real-time alarms cannot wait for round-trip travel to distant data centers.

Proxus Edge is designed around a few proven patterns that keep your system responsive, resilient, and cost-effective even in the harshest conditions.

Why Edge Computing Matters

Consider a modern automotive assembly plant:

• 1,000 sensors across 20 production lines
• 100 millisecond polling on each sensor (100 Hz frequency)
• 1 MB per day per sensor = 1 TB per day raw data

Streaming all of this to the cloud costs:

• Network: $10,000–50,000 per month for industrial-grade bandwidth
• Cloud ingestion: $5,000–20,000 per month
• Storage: $2,000–10,000 per month
• Latency: 50-200 ms round-trip to cloud = too slow for safety-critical alarms

Edge computing solves this by filtering, aggregating, and processing data locally, then shipping only meaningful summaries upstream.

Pattern 1 — Buffer at the Edge (Store & Forward)

Instead of streaming every raw tag change to the cloud, Proxus Edge implements intelligent buffering:

How It Works

• Raw sensor data flows into the Edge Gateway
• A local NATS JetStream queue buffers the stream
• Rules and filters reduce data by 80-95% (thresholding, debouncing, aggregation)
• Only summaries and anomalies are sent to the cloud

Example: Temperature Sensor

Raw data from sensor:   24.1°C, 24.1°C, 24.15°C, 24.1°C, 24.09°C, 24.11°C, 24.1°C...
                        (streaming every 100ms = 10 readings/second)

Buffered & aggregated:  Avg: 24.11°C (5-min window), Min: 24.09°C, Max: 24.15°C
                        Published only when: value changes by >0.5°C OR 5 min elapsed

Benefits

• 90-95% bandwidth reduction (from 1 TB/day to 50-100 GB/day)
• Zero data loss: NATS JetStream persists to local SSD during outages
• Replay capability: When cloud connectivity is restored, all buffered data replays automatically

Pattern 2 — Local Decision Making (Latency-Sensitive Logic)

Some decisions cannot wait for a round-trip to the cloud. A safety alarm that takes 200 ms to trigger is a liability.

Examples of Edge Decisions

• Emergency stop: Machine temperature exceeds 85°C → instantly stop motor (sub-1ms latency required)
• Stack light activation: Line stopped for >30 seconds → trigger audible/visual alarm
• Sensor fallback: Primary pressure sensor fails → switch to backup sensor and log anomaly
• Threshold violation: Humidity drops below 30% in clean room → activate humidifiers
• Sequence detection: Sensor A triggered AND Sensor B triggered within 2 seconds → anomaly event

Implementation with Proxus

You can use two approaches:

Approach 1: Visual Rule Engine (No-Code)

• Process engineers drag-and-drop triggers, conditions, and actions
• Execution happens at the edge, not in the cloud
• Example rule:
  content_copy check

  IF Temperature > 85°C AND NOT(Alarm Already Triggered)
    THEN Stop Motor
    AND Publish Alert to MQTT "Line1/Emergency/TemperatureShutdown"
    AND Log Event to Local DB

Approach 2: C# Scripting (Full Power)

• Complex multi-device correlations
• Zero-allocation patterns for 10,000+ operations per second
• Example:
  content_copy check

  public async Task ProcessAsync(FieldbusData data)
  {
    if (data.Temperature > 85 && !alertTriggered)
    {
      await motorController.StopAsync();
      await alertService.PublishAsync(AlertLevel.Critical);
      alertTriggered = true;
    }
  }

Real-World Impact

A beverage manufacturer implemented edge-based emergency logic:

• Before: 150-200 ms from sensor anomaly to motor stop (5-10 bottles damaged per incident)
• After: 2-5 ms from sensor anomaly to motor stop (0-1 bottle damaged per incident)
• Savings: ~$500,000 per year in reduced waste

Pattern 3 — Fan-Out to Multiple Targets

Industrial data is rarely consumed by a single system. Manufacturing plants need to send the same data to:

• Cloud Analytics: Historical analysis and ML models
• Time-Series Databases: InfluxDB, TimescaleDB for dashboards
• Message Brokers: Kafka for data lakes
• Enterprise Systems: SAP/Oracle for inventory and accounting
• External Partners: Supplier systems for supply chain optimization

Traditional Approach (Point-to-Point Hell)

PLC → Cloud Analytics (custom connector)
PLC → InfluxDB (another custom connector)
PLC → Kafka (yet another connector)
PLC → SAP (ERP-specific integration)

Result: 4 separate integrations, 4x maintenance burden, data inconsistency

Proxus Fan-Out Pattern

PLC → Edge Gateway → Proxus UNS (MQTT Broker)
                  ├─→ Cloud Analytics (subscribes to MQTT)
                  ├─→ InfluxDB (subscribes to MQTT)
                  ├─→ Kafka (Proxus Kafka bridge)
                  └─→ SAP (Proxus REST adapter)

Result: 1 source of truth, 4 independent consumers, zero data duplication

Benefits

• Single acquisition logic: Connect to PLC once
• Decoupled consumers: Add new systems without touching the gateway
• Consistent metadata: All downstream systems see the same tag context and timestamp
• Cost efficiency: One transmission upstream can feed multiple clouds or on-premise systems

Pattern 4 — Caching & Intelligent Aggregation

Not all data deserves equal priority. Edge gateways can apply intelligent caching:

Tiered Data Handling

High-Priority (Critical Safety):
  - Immediate transmission to cloud (no buffer)
  - Example: Emergency stop sensor, critical temperature

Medium-Priority (Operational):
  - Buffer for 5-10 seconds, then transmit
  - Example: OEE metrics, production counts
  - Aggregation: Batch writes reduce overhead by 90%

Low-Priority (Diagnostic):
  - Buffer locally for 1 hour, transmit only if requested
  - Example: Debug logs, raw sensor traces
  - Can be retrieved on-demand from edge gateway via REST API

Implementation

Proxus automatically categorizes data by tags:

UNS Topic: ProxusMfg/Istanbul/Line1/Robot/metrics/Temperature
Priority: HIGH (real-time safety)
Buffer: 0 seconds (send immediately)

UNS Topic: ProxusMfg/Istanbul/Line1/Robot/analytics/OEE
Priority: MEDIUM (business intelligence)
Buffer: 10 seconds (aggregate)

UNS Topic: ProxusMfg/Istanbul/Line1/Robot/debug/RawSensorTrace
Priority: LOW (diagnostic)
Buffer: 3600 seconds (1 hour)

Pattern 5 — Circuit Breaker & Graceful Degradation

What happens when the cloud connection drops? Traditional systems would queue data indefinitely and eventually crash.

Proxus implements a circuit breaker pattern:

States

• CLOSED (normal): Data flows cloud-ward
• OPEN (connection lost): Stop attempting transmission, buffer locally
• HALF_OPEN (recovery): Attempt to reconnect, resume transmission if successful

Graceful Degradation

Scenario: Internet goes down at 2 AM

t=0:     Connection lost
t=0-5min: Edge buffer fills (local SSD)
t=5min:   Circuit opens; local rules continue executing
t=5-120min: Operators still see real-time data on edge dashboards
           Local alerts (sirens, stack lights) work normally
           Critical logic (emergency stops) works normally

t=120min: Connection restored
          Circuit enters HALF_OPEN state
          Edge gateway retransmits 2 hours of buffered data
          Cloud analytics see no gaps

Result: 2 hours of downtime, ZERO lost data, ZERO operational impact

Real-World Case Study: Automotive Tier-1 Supplier

Company: AutoMfg Europe (10 plants, 5,000 PLCs)
Challenge: Rising cloud costs + requirement for sub-500ms latency on safety signals

Before Edge Patterns

• All PLC data streamed raw to AWS
• 500 TB/month data ingestion
• Cloud bill: $180,000/month
• Latency to safety trigger: 800 ms (unacceptable)

After Proxus Edge Patterns (All 5 described above)

• Local buffering + intelligent aggregation
• Caching of low-priority diagnostics
• Circuit breaker for offline resilience
• Cloud now receives only summaries + anomalies
• 50 TB/month data ingestion (90% reduction)
• Cloud bill: $12,000/month (93% savings!)
• Latency to safety trigger: 3 ms (local decision)

Annual savings: $2,016,000 (18 months ROI on Proxus investment)

Sparkplug B for Edge Data Standardization

When multiple edges send data to the cloud, standardization is critical. Sparkplug B ensures:

Automatic Schema Discovery

Edge Gateway 1 publishes BIRTH message:
{
  "metrics": [
    {"name": "Temperature", "type": "double", "unit": "Celsius"},
    {"name": "Running", "type": "boolean"}
  ]
}

Cloud analytics automatically creates schema:
- knows Temperature must be a float
- knows Running is a true/false state

State Awareness

If Edge Gateway 1 loses power:
- Sparkplug B publishes DEATH message
- All subscribers know the data is stale
- Dashboards show device as OFFLINE
- Alerts triggered (if configured)

When Edge Gateway 1 recovers:
- Publishes REBIRTH message
- Cloud knows to re-sync state
- Dashboard shows device as ONLINE

FAQ: Edge Computing Myths

Q: Is edge computing only for large manufacturers?

A: No. Even small plants (1-2 lines) benefit from offline continuity and local alarms. Start small; scale as you grow.

Q: Does edge computing require removing the cloud?

A: No. Edge and cloud are complementary. Edge handles real-time and offline; cloud handles historical analysis and global correlation.

Q: Can I run edge logic without coding?

A: Yes. Proxus visual rule engine covers 80% of use cases. Only complex multi-device logic requires C#.

Q: How do I migrate existing cloud logic to the edge?

A: Phased approach: (1) Deploy edge gateway alongside cloud, (2) Duplicate critical rules on edge, (3) Gradually retire cloud rules, (4) Optimize edge logic based on telemetry.

Best Practices for Edge Implementation

1. Start with critical paths: Move safety-critical and latency-sensitive logic first
2. Use buffering for non-critical data: Only stream anomalies and summaries
3. Implement circuit breakers: Handle connection loss gracefully
4. Cache aggressively: Reduce cloud transmission by 80-90%
5. Monitor edge health: Edge gateways should expose their own metrics
6. Test failover scenarios: Simulate network failures and verify local operation
7. Use Sparkplug B: Enforce schema consistency across edge gateways

Getting Started

Phase 1: Assessment (1 week)

• Identify latency-sensitive logic
• Measure cloud costs vs. potential edge savings
• Select 1-2 pilot production lines

Phase 2: Pilot (4 weeks)

• Deploy Proxus Edge Gateway to pilot lines
• Migrate 5-10 critical rules to edge
• Validate local decision making works
• Measure cloud bandwidth reduction

Phase 3: Scale (ongoing)

• Roll out to additional lines
• Optimize buffering and aggregation
• Add predictive maintenance logic
• Achieve target cloud cost reduction

Conclusion: The Edge is Your Competitive Advantage

Factories that move logic to the edge are not just saving money—they are gaining speed, resilience, and autonomy. A plant that can continue operating during cloud outages, respond to anomalies in milliseconds, and cut cloud costs in half is a plant that wins market share.

Proxus Edge patterns make this possible without requiring deep distributed systems expertise. Start with buffering and fan-out; evolve to local decision-making and caching as your confidence grows.

Ready to unlock edge computing? Learn how to deploy your first Proxus Edge Gateway, or explore advanced edge patterns in our architecture guide.

For cost and latency optimization consulting, contact our solutions team.