IIoT Architecture Layers: Device, Edge, Broker and Application

A good IIoT architecture splits an industrial system into four layers: devices that sense and control, edge gateways that translate and filter, a broker that distributes messages, and applications that turn data into decisions. In this reference you will learn what each layer is responsible for, which design rules keep the layers independent, and how to run a small end-to-end example that touches all four.

Why Layers Matter in Industrial IoT

Many early IIoT projects were built as straight pipes: a script reads a PLC and writes into a database that one dashboard queries. It works for the demo. Then a second consumer needs the data, the PLC is replaced, or the database moves to the cloud, and every change ripples through the whole chain.

A layered architecture contains those ripples. Each layer has one job and a clear contract with its neighbours. Replace a PLC and only the edge configuration changes. Add an analytics tool and only a new subscriber appears. Move from on-premises to cloud and the edge simply connects to a different broker address. The publish/subscribe model is what makes this decoupling possible, which is why an MQTT broker sits at the centre of most modern IIoT designs.

The Four IIoT Architecture Layers

Device layer

This is the physical world: temperature probes, flow meters, PLCs, drives, CNC controllers and robots. Devices are optimised for deterministic control, not for sharing data. Many speak only fieldbus or serial protocols, and some have no communication interface at all. The architecture rule at this layer is simple: do not change control logic to serve IT needs. Read data non-invasively and leave safety and control where they belong.

Edge layer

The edge is the translator and the guard. An edge gateway reads PLC tags, Modbus registers or sensor inputs, converts them into a common format, and publishes them over MQTT. It also does the work that should never travel over a WAN: filtering noise, reporting by exception, adding timestamps and units, and buffering data when the uplink is down. Our guides on choosing an IIoT edge gateway and on edge computing vs cloud computing in IIoT go deeper into what belongs here.

Key edge responsibilities:

1. Protocol conversion from device protocols to MQTT.
2. Normalising names, units and timestamps.
3. Report by exception with deadbands to reduce traffic.
4. Store and forward during network outages.
5. Outbound-only connections to the broker over TLS.
6. Publishing its own health: online status via last will, firmware, last poll time.

Broker layer

The broker is the hub. Every edge gateway publishes into it and every application subscribes from it. Neither side knows about the other, which is exactly the point. Beyond routing, the broker holds retained messages so new applications see current state immediately, keeps sessions for clients that reconnect, enforces authentication and quotas, and publishes last will messages when gateways drop. If you want the fundamentals, read about what an MQTT broker does.

The broker is also where the namespace lives. A Unified Namespace organises topics by the ISA-95 hierarchy, for example connectmq/acme/plant1/packaging/line4/filler02/telemetry, so every application can find data by location instead of by tag list. The rules for designing that tree are in our UNS topic structure guide.

Application layer

Applications are where data becomes value: live dashboards, OEE calculations, alarm notification, historians, MES and ERP integration, machine learning. Each application is just another MQTT client. It subscribes to the part of the namespace it needs, and may publish results back, such as a calculated OEE or a predicted failure, which other applications can then consume. Long-term storage is usually a dedicated subscriber that writes to a time-series database, covered in our MQTT historian article.

Design Rules That Keep the Architecture Clean

1. Every arrow points at the broker. Devices never talk to applications directly, and applications never poll devices.
2. Connections go outward. Edge and applications open connections to the broker; nothing opens connections into the plant.
3. One namespace, documented. Topic hierarchy and payload format are written down and versioned.
4. Retain state, do not retain events. Current values are retained; alarms and part completions are not.
5. Each client has its own identity. Separate credentials per gateway and per application, so one can be revoked without affecting others.
6. Intelligence at the right layer. Time-critical logic stays on the device or edge; cross-site analytics belongs in the application layer.
7. Observe the system itself. Gateway status, connection state and message rates are data too.

End-to-End Example Across All Four Layers

The following example uses the public test broker. The bash command plays the edge layer, publishing device readings. The Python script is an application: a tiny historian that stores every reading in SQLite and publishes an alert when a threshold is crossed.

Edge layer (simulated), publishing a reading every two seconds:

ID=arch-$RANDOM
echo "Use prefix connectmq/demo/$ID"
while true; do
  T=$(awk -v r=$RANDOM 'BEGIN{printf "%.1f", 60 + (r % 300) / 10}')
  mosquitto_pub -h broker.connectmq.com -p 1883 -i "$ID-edge" -q 1 \
    -t "connectmq/demo/$ID/plant1/heat/furnace1/temperature" \
    -m "{\"value\":$T,\"unit\":\"C\"}"
  sleep 2
done

Application layer, storing data and publishing alerts:

import json
import sqlite3
import sys
import time
import paho.mqtt.client as mqtt

PREFIX = sys.argv[1]  # e.g. connectmq/demo/arch-12345
LIMIT_C = 85.0

db = sqlite3.connect("historian.db", check_same_thread=False)
db.execute("CREATE TABLE IF NOT EXISTS readings (ts REAL, topic TEXT, value REAL)")

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(f"{PREFIX}/plant1/+/+/temperature", qos=1)

def on_message(client, userdata, msg):
    data = json.loads(msg.payload)
    value = float(data["value"])
    db.execute("INSERT INTO readings VALUES (?, ?, ?)", (time.time(), msg.topic, value))
    db.commit()
    print(f"{msg.topic} = {value}")
    if value > LIMIT_C:
        alert_topic = msg.topic.rsplit("/", 1)[0] + "/alert"
        client.publish(alert_topic, json.dumps({"reason": "over_limit", "value": value}), qos=1)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"{PREFIX.split('/')[-1]}-historian")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Run it with the prefix printed by the edge loop, for example python historian.py connectmq/demo/arch-12345. Notice what never happens: the historian does not know the furnace's IP address, and the edge loop does not know the historian exists. You could add a dashboard, a second historian or an ML model as further subscribers without touching either. For production, move both sides to port 8883 with TLS and ConnectMQ credentials from the portal, and keep real plant data off the public broker, which anyone can read.

Choosing Where the Broker Runs

The broker layer can run on-premises, in a DMZ, in the cloud or in a combination of these. A single plant with strict isolation may keep a local broker. Multi-site organisations usually want a central broker that all sites reach outbound. Running it yourself means patching, certificate renewal, monitoring and capacity planning. A managed MQTT broker removes that work, and our cloud MQTT broker guide compares the hosting models.

ConnectMQ is designed to be the broker layer in this architecture. It supports MQTT 3.1.1 and 5.0 over TCP 1883, TLS 8883, WebSocket 8083 and secure WebSocket 8084, so edge gateways and browser applications connect to the same namespace. It detects ISA-95 and Unified Namespace topics, decodes Sparkplug B and republishes it into ISA-95 topics, and offers a devices view by ISA-95 level, a live topic explorer and threshold alert rules. Integrations with historians, databases and dashboards follow the pattern above: tools such as Node-RED, Telegraf or your own subscribers connect to ConnectMQ as MQTT clients. Deployment options range from free Serverless to Dedicated clusters and BYOC in your own cloud account. For the complete industrial picture, read the Industrial IoT with MQTT guide.

Get Started with ConnectMQ

Create a free Serverless broker at app.connectmq.com, no credit card required. Point one edge gateway and one application at it, and you have all four layers of your IIoT architecture running in an afternoon.

Frequently Asked Questions

What are the layers of an IIoT architecture?

A practical reference uses four layers: devices that sense and control, edge gateways that collect and convert data, a broker that routes messages and holds state, and applications that visualise, store and analyse.

Why is MQTT used as the IIoT messaging layer?

MQTT is lightweight, event-driven and uses outbound connections, so it works well across segmented plant networks. Its publish/subscribe model lets many applications use the same data without point-to-point integrations.

Should processing happen at the edge or in the cloud?

Time-critical filtering, protocol conversion and buffering belong at the edge. Cross-machine and cross-site analytics, long-term storage and business integration usually belong in the application layer, often in the cloud.

How does the Purdue model relate to this IIoT architecture?

The Purdue model describes network security levels, while this architecture describes data flow. They complement each other: devices sit at the lower Purdue levels, edge gateways at site level, and the broker in the DMZ or cloud.