Une bonne architecture IIoT découpe un système industriel en quatre couches : des appareils qui mesurent et pilotent, des passerelles edge qui traduisent et filtrent, un broker qui distribue les messages et des applications qui transforment les données en décisions. Dans cette référence, vous verrez de quoi chaque couche est responsable, quelles règles de conception maintiennent les couches indépendantes et comment exécuter un petit exemple de bout en bout qui traverse les quatre.
Pourquoi les couches comptent dans l'IoT industriel
De nombreux projets IIoT des débuts étaient construits comme des tuyaux directs : un script lit un automate et écrit dans une base de données interrogée par un tableau de bord. Cela fonctionne pour la démo. Puis un deuxième consommateur a besoin des données, l'automate est remplacé ou la base de données part dans le cloud, et chaque changement se répercute sur toute la chaîne.
Une architecture en couches contient ces répercussions. Chaque couche a une seule mission et un contrat clair avec ses voisines. Remplacez un automate et seule la configuration edge change. Ajoutez un outil d'analytique et seul un nouvel abonné apparaît. Passez de l'on-premise au cloud et l'edge se connecte simplement à une autre adresse de broker. C'est le modèle publish/subscribe qui rend ce découplage possible, et c'est pourquoi un broker MQTT se trouve au centre de la plupart des architectures IIoT modernes.
Les quatre couches d'une architecture IIoT
| Couche | Responsabilité | Composants typiques | Protocoles | Responsable |
|---|---|---|---|---|
| Appareil | Mesurer, actionner, piloter le procédé | Capteurs, automates, variateurs, CNC, robots | Bus de terrain, Modbus, OPC UA, E/S analogiques et numériques | Automatisme |
| Edge | Collecter, normaliser, mettre en tampon, filtrer, sécuriser la liaison montante | PC industriels, passerelles, Node-RED, convertisseurs de protocole | Protocoles des appareils en aval, MQTT en amont | OT, parfois conjointement avec l'IT |
| Broker | Acheminer les messages, conserver l'état actuel, authentifier les clients | Broker MQTT, managé ou auto-hébergé | MQTT 3.1.1 et 5.0 via TLS et WebSocket | Équipe plateforme ou fournisseur managé |
| Application | Visualiser, stocker, analyser, intégrer, décider | Tableaux de bord, historians, MES, connecteurs ERP, analytique | Abonnement et publication MQTT | IT, équipes data, exploitation |
La couche appareil
C'est le monde physique : sondes de température, débitmètres, automates, variateurs, contrôleurs CNC et robots. Les appareils sont optimisés pour un contrôle déterministe, pas pour le partage de données. Beaucoup ne parlent que des protocoles de bus de terrain ou série, et certains n'ont aucune interface de communication. La règle d'architecture à ce niveau est simple : ne modifiez pas la logique de contrôle pour répondre aux besoins de l'IT. Lisez les données de façon non intrusive et laissez la sécurité et le contrôle là où ils doivent être.
La couche edge
L'edge est à la fois le traducteur et le gardien. Une passerelle edge lit les tags d'automate, les registres Modbus ou les entrées de capteurs, les convertit dans un format commun et les publie en MQTT. Elle se charge aussi de ce qui ne devrait jamais transiter par un WAN : filtrer le bruit, publier sur changement, ajouter horodatages et unités, et mettre les données en tampon quand la liaison montante est coupée. Nos guides pour choisir une passerelle edge IIoT et sur l'edge computing face au cloud computing dans l'IIoT détaillent ce qui a sa place ici.
Principales responsabilités de l'edge :
- Conversion des protocoles des appareils vers MQTT.
- Normalisation des noms, unités et horodatages.
- Publication sur changement avec bandes mortes pour réduire le trafic.
- Stockage et retransmission (store and forward) pendant les coupures réseau.
- Connexions uniquement sortantes vers le broker via TLS.
- Publication de sa propre santé : statut en ligne via last will, firmware, heure de la dernière lecture.
La couche broker
Le broker est le hub. Chaque passerelle edge y publie et chaque application s'y abonne. Aucun des deux côtés ne connaît l'autre, et c'est précisément le but. Au-delà de l'acheminement, le broker conserve les retained messages pour que les nouvelles applications voient immédiatement l'état actuel, maintient les sessions des clients qui se reconnectent, applique l'authentification et les quotas, et publie les messages last will lorsque des passerelles décrochent. Pour les fondamentaux, lisez ce que fait un broker MQTT.
Le broker est aussi l'endroit où vit le namespace. Un Unified Namespace organise les topics selon la hiérarchie ISA-95, par exemple connectmq/acme/plant1/packaging/line4/filler02/telemetry, afin que chaque application puisse trouver les données par emplacement plutôt que par liste de tags. Les règles de conception de cette arborescence se trouvent dans notre guide sur la structure des topics UNS.
La couche application
Les applications sont l'endroit où les données deviennent de la valeur : tableaux de bord en temps réel, calcul du TRS, notification d'alarmes, historians, jumeaux numériques, intégration MES et ERP, machine learning. Chaque application n'est qu'un client MQTT de plus. Elle s'abonne à la partie du namespace dont elle a besoin et peut republier des résultats, comme un TRS calculé ou une panne prédite, que d'autres applications pourront consommer. Le stockage long terme est généralement assuré par un abonné dédié qui écrit dans une base de données de séries temporelles, sujet traité dans notre article sur l'historian MQTT.
Les règles de conception qui gardent l'architecture propre
- Chaque flèche pointe vers le broker. Les appareils ne parlent jamais directement aux applications, et les applications n'interrogent jamais les appareils.
- Les connexions partent vers l'extérieur. L'edge et les applications ouvrent des connexions vers le broker ; rien n'ouvre de connexion vers l'usine.
- Un seul namespace, documenté. La hiérarchie des topics et le format des payloads sont écrits et versionnés.
- Retenir les états, pas les événements. Les valeurs actuelles sont retenues ; les alarmes et les fins de pièce ne le sont pas.
- Chaque client a sa propre identité. Des identifiants distincts par passerelle et par application, pour pouvoir en révoquer un sans affecter les autres.
- L'intelligence à la bonne couche. La logique à contrainte de temps reste sur l'appareil ou l'edge ; l'analytique multisite appartient à la couche application.
- Observer le système lui-même. Le statut des passerelles, l'état des connexions et les débits de messages sont aussi des données.
Exemple de bout en bout à travers les quatre couches
L'exemple suivant utilise le serveur MQTT public gratuit, réservé aux tests. La commande bash joue le rôle de la couche edge en publiant les mesures d'un appareil. Le script Python est une application : un mini-historian qui stocke chaque mesure dans SQLite et publie une alerte lorsqu'un seuil est dépassé.
Couche edge (simulée), qui publie une mesure toutes les deux secondes :
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
Couche application, qui stocke les données et publie des alertes :
import json
import sqlite3
import sys
import time
import paho.mqtt.client as mqtt
PREFIX = sys.argv[1] # p. ex. 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()
Lancez-le avec le préfixe affiché par la boucle edge, par exemple python historian.py connectmq/demo/arch-12345. Remarquez ce qui ne se produit jamais : l'historian ne connaît pas l'adresse IP du four, et la boucle edge ignore l'existence de l'historian. Vous pourriez ajouter un tableau de bord, un deuxième historian ou un modèle de ML comme abonnés supplémentaires sans toucher ni à l'un ni à l'autre. En production, passez les deux côtés sur le port 8883 avec TLS et des identifiants ConnectMQ issus du portail, et tenez les vraies données d'usine à l'écart du serveur MQTT public gratuit, lisible par n'importe qui.
Choisir où exécuter le broker
La couche broker peut s'exécuter on-premise, dans une DMZ, dans le cloud ou dans une combinaison de ces options. Une usine isolée soumise à des contraintes strictes peut conserver un broker local. Les organisations multisites veulent généralement un broker central que tous les sites atteignent en sortie. L'exploiter vous-même implique correctifs, renouvellement des certificats, supervision et planification de capacité. Un broker MQTT managé supprime ce travail, et notre guide des brokers MQTT cloud compare les modèles d'hébergement.
ConnectMQ est conçu pour être la couche broker de cette architecture. Il prend en charge MQTT 3.1.1 et 5.0 sur TCP 1883, TLS 8883, WebSocket 8083 et WebSocket sécurisé 8084, de sorte que passerelles edge et applications web se connectent au même namespace. Il détecte les topics ISA-95 et Unified Namespace, décode Sparkplug B et le republie dans des topics ISA-95, et propose une vue des appareils par niveau ISA-95, un explorateur de topics en temps réel et des règles d'alerte à seuil. Les intégrations avec les historians, bases de données et tableaux de bord suivent le modèle ci-dessus : des outils comme Node-RED, Telegraf ou vos propres abonnés se connectent à ConnectMQ en tant que clients MQTT. Les options de déploiement vont du Serverless gratuit aux clusters Dedicated et à BYOC dans votre propre compte cloud. Pour la vue industrielle complète, lisez le guide de l'IoT industriel avec MQTT.
Démarrer avec ConnectMQ
Créez gratuitement un broker Serverless sur app.connectmq.com, sans carte bancaire. Connectez-y une passerelle edge et une application, et les quatre couches de votre architecture IIoT tournent en un après-midi.
Questions fréquentes
Quelles sont les couches d'une architecture IIoT ?
Une référence pratique utilise quatre couches : des appareils qui mesurent et pilotent, des passerelles edge qui collectent et convertissent les données, un broker qui achemine les messages et conserve l'état, et des applications qui visualisent, stockent et analysent.
Pourquoi MQTT est-il utilisé comme couche de messagerie IIoT ?
MQTT est léger, piloté par les événements et utilise des connexions sortantes : il fonctionne donc bien à travers des réseaux d'usine segmentés. Son modèle publish/subscribe permet à de nombreuses applications d'utiliser les mêmes données sans intégrations point à point.
Le traitement doit-il se faire à l'edge ou dans le cloud ?
Le filtrage à contrainte de temps, la conversion de protocoles et la mise en tampon ont leur place à l'edge. L'analytique entre machines et entre sites, le stockage long terme et l'intégration métier relèvent généralement de la couche application, souvent dans le cloud.
Quel est le lien entre le modèle de Purdue et cette architecture IIoT ?
Le modèle de Purdue décrit des niveaux de sécurité réseau, tandis que cette architecture décrit le flux de données. Les deux sont complémentaires : les appareils se situent aux niveaux Purdue inférieurs, les passerelles edge au niveau du site et le broker dans la DMZ ou le cloud.
