Edge-to-cloud pipeline monitoring with MQTT Sparkplug B across 300+ remote stations.
Industry: Oil & Gag Midstream | Edge Connectivity


Quick Facts

AttributeValue
CustomerMajor midstream pipeline operator
Scale300+ remote sites, 500,000+ data points
Points per Site~1,500
Update Rate10 seconds
ArchitectureEdgeConnect on router-class Linux, MQTT Sparkplug B, 4-node broker HA
StatusIn production, phased deployment

The Challenge

Challenge: Operate and observe hundreds of distributed midstream sites with PLCs and intermittent, bandwidth-limited links—while keeping on-site autonomy and ensuring a unified, secure, and scalable publish/subscribe model for corporate operations, analytics, and alarms.

Specific pain points:

  • Multiprotocol collection (ControlLogix + DF1) into a single publish model without custom middleware
  • Reliable delivery over satellite with high latency/jitter and strict bandwidth budgets
  • Broker high-availability and end-to-end observability at scale (350 sites, 500k+ tags)
  • Simple, repeatable deployment on router-class Linux hardware with unattended recovery

Impact: Without a standardized, resilient gateway + MQTT pattern, sites face delayed event visibility, manual correlation, higher truck-rolls, and longer MTTR during incidents.

Example: "Prior to MQTT + EdgeConnect, engineers had to manually pull logs from PLCs after outages; post-event diagnostics stretched MTTR and risked SLA breaches."


The Solution

Architecture

TierComponentCapabilities
FieldControlLogix (CIP), DF1 devicesSignals and controls
Edge (Site)EdgeConnect on Linux (Cisco routers)Collection, buffer, publish; AutoStart; Watchdog; local logging
TransportSatellite / WANTelemetry backhaul with store-and-forward
BrokersMQTT brokers (HA, N=4)Pub/Sub backbone; persistent sessions; retained health topics
ConsumersSCADA / Historian / AnalyticsEnterprise visibility and actions

Scale

ComponentSpecificationQuantity
Edge NodesEdgeConnect in Cisco routers300+
ProtocolsControlLogix and DF1Multiple
Data Points1,500 per site500,000 total
Update Rate10 secondsOptimized
TransportMQTT Sparkplug B4 brokers
Redundancy1 redundant server + 3 redundant MQTT BrokersAll sites

Network Architecture

  • Segmented per-site VLANs; secure egress to broker endpoints only
  • Backpressure control: publish rate limiting, payload compression, delta/exception reporting
  • Multi-endpoint broker list with exponential backoff and jitter to avoid thundering herd
ControlLogix DF1 CISCO FrameworX SCADA Server Radio 4G MqttSpB 1 MqttSpB 2 MqttSpB 3 MqttSpB 4 Application Application Legend: PLC Satellite MQTT Sparkplug B Broker Third-Party Applications Publish (to MQTT)

Redundancy & Failover

Brokers:

  • 4-node HA cluster with client failover and session persistence

Edge:

  • Store-and-forward with disk queues
  • Automatic reconnect and replay
  • Service watchdog and OS autostart

Links:

  • Multi-endpoint broker list
  • Exponential backoff with jitter

Protocols & Equipment

CategoryDetails
Drivers/InterfacesControlLogix (CIP/EtherNet/IP), DF1 (serial), TCP/IP
MessagingMQTT, MQTT Sparkplug B (birth/death, metrics, model)
Data ModelSparkplug namespaces per site/asset; Group ID, Node ID, Device ID

Observability & Health

  • Edge and broker watchdogs
  • Heartbeats (LWT/BIRTH), latency and backlog metrics per site
  • Topic-level delivery KPIs

Key Enablers

FrameworX capabilities that made this solution possible:

CapabilityApplication
Multiprotocol edge collectionControlLogix + DF1 with unified MQTT/Sparkplug output
Router-grade Linux runtimeLow footprint deployment close to PLCs on Cisco hardware
Store-and-ForwardUnattended resilience over satellite; disk queues for network outages
AutoStart + WatchdogAutomatic recovery without manual intervention
Broker HA (N=4)Access governance to prevent network overflow and ensure continuity
Real-time monitoringAlarms on heartbeat loss, queue growth, or reconnect storms



Strategic Insights

Edge Intelligence vs. Middleware

Traditional approaches require expensive middleware to aggregate multiprotocol data. EdgeConnect standardizes collection at the source, publishing unified Sparkplug B regardless of field protocol—eliminating middleware complexity and cost.

Satellite-Ready Architecture

High-latency, bandwidth-constrained links require purpose-built resilience. Store-and-forward with disk queues, rate limiting, and payload batching ensures reliable delivery without overwhelming constrained links.

Why it's non-trivial elsewhere:

The combination of CIP + DF1 ingestion, Sparkplug governance at scale, true edge resilience over high-latency links, and 4-node broker HA across 350 sites typically requires significant custom engineering; EdgeConnect standardizes it.


Build This Architecture

ItemDetails
Deployment Time (Phase 1)8-12 weeks for 50 sites
Current Stage300+ sites
Required ProductsEdgeConnect ($750/site), Enterprise Unlimited ($11,900), DataHub Station ($2,000 × 6)
Total Architecture Cost~$250,000 for complete 300-site system

The Results

  • Reduced MTTR by 70% — Eliminated manual log collection from PLCs post-outage through real-time MQTT telemetry, enabling immediate incident visibility and faster root cause analysis
  • Achieved 99.5% uptime across 350 sites — 4-node broker HA cluster with store-and-forward edge resilience maintained continuous operations despite satellite link interruptions and bandwidth constraints
  • Standardized deployment at scale — Single EdgeConnect solution replaced custom middleware across all sites, reducing deployment complexity and enabling consistent 500k+ tag collection from mixed ControlLogix/DF1 environments
  • Enhanced operational visibility — Real-time publish/subscribe model with Sparkplug B provided enterprise-wide monitoring and analytics capabilities, replacing reactive maintenance with proactive incident management

This case demonstrates large-scale edge-to-cloud architecture for remote pipeline monitoring with MQTT Sparkplug B, satellite-resilient connectivity, and standardized deployment across hundreds of sites.

  • No labels