Edge Computing vs Cloud Computing in IIoT: Latency, Bandwidth, Resilience and a Hybrid Design

Edge computing vs cloud computing in IIoT is not an either-or decision: the real question is which logic runs next to the machine and which runs centrally. This article compares both approaches on latency, bandwidth, resilience, security and cost, then walks through a hybrid design where an edge node handles fast decisions locally and publishes summarised results to a cloud MQTT broker.

Definitions in an Industrial Context

Edge computing means processing data on or near the shop floor: in a PLC, an industrial PC, a gateway or a small server in the plant. Data is acted on before it leaves the site.

Cloud computing means processing data centrally in a public or private cloud: storage, analytics, dashboards, machine learning training and cross-site reporting.

Between the two sits the messaging layer. In most modern IIoT systems that is MQTT: edge devices publish, cloud services subscribe, and the broker decouples them so either side can change without breaking the other.

Edge Computing vs Cloud Computing in IIoT: Side-by-Side

Neither column wins outright. Each row points to a class of workload that belongs on one side.

What Belongs at the Edge

1. Safety and control loops. Anything that must react in milliseconds or must never depend on the internet stays in PLCs and safety systems. The cloud should never be in a control loop.
2. High-frequency signal processing. Vibration at kilohertz sampling rates, power quality waveforms and high-speed counters produce far more data than you want to ship. Compute features (RMS, peak, frequency bands) locally and publish those.
3. Local alarms. A tank overflow alarm must sound even when the WAN is down.
4. Data reduction. Deadbands and report by exception cut traffic at the source.
5. Buffering. Edge nodes queue data during outages and replay it later, as described in store and forward for MQTT.
6. Protocol translation. Converting Modbus, OPC UA or EtherNet/IP into MQTT is inherently local; see IIoT edge gateway.

What Belongs in the Cloud

1. Cross-site comparison and OEE reporting. Comparing lines in different plants requires the data in one place.
2. Long-term history. Years of time-series data are cheaper and easier to manage centrally.
3. Model training. Machine learning models are trained on large historical datasets with elastic compute, then the trained model can be deployed back to the edge.
4. Business integration. ERP, maintenance and quality systems live in IT, not on the shop floor.
5. Remote dashboards and mobile access. Engineers and managers away from the plant need a central endpoint.

The Hybrid Pattern

The practical answer for most plants is hybrid: compute at the edge, coordinate and analyse in the cloud, and connect them with MQTT.

  Machine  -->  Edge node                         -->  Cloud MQTT broker  -->  Cloud services
  (100 Hz)      - samples raw signal                    (TLS 8883)              - dashboards
                - local alarm (no WAN needed)                                   - historian
                - 1-minute aggregates                                           - analytics
                - publishes events + summaries

The edge publishes two kinds of messages: events (alarm raised, alarm cleared) the moment they happen, and summaries (min, max, mean per minute) on a fixed schedule. The cloud never sees the raw 100 Hz stream unless an engineer explicitly asks for it.

A Working Hybrid Edge Node in Python

This script simulates a sensor sampled at 20 Hz. It evaluates an alarm locally on every sample, publishes alarm transitions immediately, and publishes one aggregate per minute. It uses paho-mqtt 2.x and the public test area of broker.connectmq.com; change the host, port and credentials for production.

import json
import math
import random
import statistics
import time
from datetime import datetime, timezone

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
PORT = 1883
CLIENT_ID = "edge-node-3c9d"
BASE = "connectmq/demo/edge-3c9d/plant1/line1/pump1"

SAMPLE_HZ = 20
WINDOW_S = 60
ALARM_ON = 78.0     # degrees C
ALARM_OFF = 74.0    # hysteresis


def read_sensor(t):
    """Simulated bearing temperature with slow drift and noise."""
    return 70 + 6 * math.sin(t / 90) + random.gauss(0, 0.4)


def now_iso():
    return datetime.now(timezone.utc).isoformat(timespec="milliseconds")


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
                     protocol=mqtt.MQTTv5)
client.on_connect = on_connect
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
# Production: client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD"); client.tls_set(); PORT = 8883
client.connect(BROKER, PORT, keepalive=60)
client.loop_start()

window = []
alarm = False
window_start = time.monotonic()
t0 = time.monotonic()

while True:
    value = read_sensor(time.monotonic() - t0)
    window.append(value)

    # Edge logic: evaluated on every sample, no network needed
    if not alarm and value > ALARM_ON:
        alarm = True
        # here you would also drive a local output, e.g. a stack light
        client.publish(f"{BASE}/event", json.dumps(
            {"ts": now_iso(), "type": "HIGH_TEMP", "state": "RAISED", "value": round(value, 2)}),
            qos=1)
    elif alarm and value < ALARM_OFF:
        alarm = False
        client.publish(f"{BASE}/event", json.dumps(
            {"ts": now_iso(), "type": "HIGH_TEMP", "state": "CLEARED", "value": round(value, 2)}),
            qos=1)

    # Cloud summary: one message per window instead of SAMPLE_HZ * WINDOW_S
    if time.monotonic() - window_start >= WINDOW_S:
        summary = {
            "ts": now_iso(),
            "window_s": WINDOW_S,
            "samples": len(window),
            "min": round(min(window), 2),
            "max": round(max(window), 2),
            "mean": round(statistics.fmean(window), 2),
            "alarm": alarm,
        }
        client.publish(f"{BASE}/summary", json.dumps(summary), qos=1, retain=True)
        print("summary", summary)
        window.clear()
        window_start = time.monotonic()

    time.sleep(1 / SAMPLE_HZ)

Subscribe from another terminal to see the difference in volume between what the edge sees and what the cloud receives:

mosquitto_sub -h broker.connectmq.com -p 1883 -i edge-3c9d-viewer -t "connectmq/demo/edge-3c9d/#" -v

The node processes 1,200 samples per minute but sends one summary plus the occasional event. The alarm decision happens locally and immediately; if the broker is unreachable, the local alarm still works. For a real deployment, add a disk-backed queue so events raised during an outage are not lost.

Cost Considerations Without the Hype

Edge hardware costs money up front and needs someone to maintain it on site. Cloud services cost money continuously and the bill usually grows with data volume. That makes data reduction at the edge the single biggest lever on cloud cost: if you only send what is needed, you can use smaller plans, smaller databases and less bandwidth, especially over metered links such as MQTT over cellular. The trade-off is that data you never send cannot be analysed later, so keep raw data locally for a while if engineers may need it.

Security in a Hybrid Design

The edge-to-cloud connection should always be outbound, encrypted and authenticated. The edge node opens a TLS session to the broker on port 8883 using credentials issued specifically for that node. No inbound ports into the plant network are needed, which keeps the OT network closed. Cloud consumers subscribe with their own credentials. The industrial IoT with MQTT guide puts this pattern into the larger plant architecture.

Choosing the Cloud Side

In the hybrid model, the cloud broker is the hub that every site and every consumer depends on. Running it yourself means operating TLS, authentication and capacity planning for a critical system. A hosted MQTT broker takes that work away, and ConnectMQ offers a range from shared serverless brokers for pilots to dedicated and bring-your-own-cloud deployments for larger rollouts. Integrations such as historians or databases are connected as ordinary MQTT subscribers (Telegraf, Node-RED or your own services), which keeps the architecture simple and portable. If you are new to brokers in general, start with what an MQTT broker does.

Connect Your Edge to ConnectMQ

Give your edge nodes a secure cloud hub in minutes. ConnectMQ provides MQTT 3.1.1 and 5.0 over TLS, issued credentials, a live topic explorer and threshold alert rules for monitoring summaries. Create a free Serverless broker at app.connectmq.com with no credit card and point the script above at it.

Frequently Asked Questions

Is edge computing replacing cloud computing in IIoT?

No. They solve different problems. The edge handles fast, local and bandwidth-heavy work; the cloud handles cross-site analysis, history and integration. Most systems use both.

What latency can I expect from cloud processing?

It depends on the network path and the provider region, typically tens to hundreds of milliseconds with occasional spikes. That is fine for dashboards and analytics but not for control loops.

Does edge computing improve security?

It can, because raw data stays inside the plant and only summaries leave it. The edge nodes themselves still need patching, hardening and secure credentials.

How does MQTT help a hybrid architecture?

MQTT decouples producers and consumers. Edge nodes publish to topics without knowing who consumes them, so cloud services can be added or changed without touching the plant.