Dossier IoT

OPC UA vers MQTT — bridge industriel et Unified Namespace

Bridge OPC UA client vers MQTT publisher : Unified Namespace, Sparkplug B, HiveMQ, AWS IoT. Comparaison OPC UA vs Modbus, sécurité, architecture IIoT moderne.

En bref
Un bridge OPC UA → MQTT se connecte en tant que client OPC UA à vos serveurs (automates, SCADA, robots) et publie les valeurs des nœuds souscrit en MQTT JSON ou Sparkplug B vers un broker cloud. Il est le pilier de l'Unified Namespace (UNS), l’architecture de référence de l’Industrie 4.0 pour centraliser toutes les données de production.

OPC UA : le protocole de l’Industrie 4.0​

OPC UA (OPC Unified Architecture, IEC 62541) est le protocole de référence de l’Industrie 4.0. Contrairement à Modbus qui expose des registres sans contexte, OPC UA expose un modèle d’information orienté objet : chaque variable est un nœud typé dans un espace d’adressage hiérarchique, avec métadonnées (unité engineering, plage, description), méthodes invocables et événements.

Les automates modernes (Siemens S7-1500, Beckhoff CX, Rockwell ControlLogix), les robots et les SCADA récents embarquent tous un serveur OPC UA. Le bridge OPC UA → MQTT permet d’extraire ces données riches et de les injecter dans l’architecture cloud.

Architecture du bridge OPC UA → MQTT​

Serveurs OPC UA Bridge Eziwan MQTT Broker / UNS
─────────────── ────────────── ─────────────────
Automate Siemens ─┐ ┌── OPC UA Client HiveMQ Cloud
Robot Beckhoff ─┤── TCP ───►│ Subscriptions MQTT AWS IoT Core
SCADA Ignition ─┤ │ MonitoredItems ──TLS► Mosquitto
MES Wonderware ─┘ │ Decode + Map Eziwan UNS
└── Sparkplug B / JSON

Le bridge maintient une connexion OPC UA persistante avec chaque serveur. Il crée des Subscriptions OPC UA avec des MonitoredItems sur les nœuds à surveiller. Le serveur envoie proactivement les valeurs modifiées (mode push), ce qui est beaucoup plus efficace que le polling Modbus.

Mappage des nœuds OPC UA vers les topics MQTT​

La configuration du bridge consiste à associer des NodeIDs OPC UA à des topics MQTT. Deux approches coexistent :

Mappage manuel

OPC UA NodeID → Topic MQTT
ns=2;s=Station1.Pompe.Pression → usine/ligne1/pompe01/pression_bar
ns=2;s=Station1.Pompe.Debit → usine/ligne1/pompe01/debit_m3h
ns=2;s=Station1.Pompe.Etat → usine/ligne1/pompe01/etat

Mappage automatique (OPC UA → UNS) Le bridge parcourt l’espace d’adressage OPC UA et génère automatiquement une hiérarchie de topics MQTT miroir. C’est l’approche recommandée pour les installations avec de nombreux nœuds.

Unified Namespace : OPC UA comme source de vérité​

L'Unified Namespace (UNS) est l’architecture IIoT moderne recommandée par les experts Industrie 4.0. Elle positionne un broker MQTT central (HiveMQ, EMQX, VerneMQ) comme hub de données unique :

SourcePublication dans le UNS
Automates (OPC UA)Bridge OPC UA → MQTT
Équipements legacy (Modbus RTU)Bridge Modbus → MQTT
Compteurs M-BusBridge M-Bus → MQTT
MES / ERPAPI → MQTT
Capteurs IoTMQTT natif

Toutes les applications (SCADA, MES, dashboards, IA) s’abonnent au broker MQTT selon leurs besoins. Plus d’intégrations point-à-point : chaque système publie une fois, tous les consommateurs reçoivent.

Sparkplug B : la spécification pour l’UNS industriel​

Sparkplug B (Eclipse Foundation, spBv1.0) standardise l’utilisation de MQTT pour l’IIoT :

Structure des topics :

spBv1.0/{group_id}/NBIRTH/{edge_node_id} ← Connexion nœud
spBv1.0/{group_id}/DBIRTH/{edge_node_id}/{device_id} ← Connexion device
spBv1.0/{group_id}/NDATA/{edge_node_id} ← Données nœud
spBv1.0/{group_id}/DDATA/{edge_node_id}/{device_id} ← Données device
spBv1.0/{group_id}/NDEATH/{edge_node_id} ← Déconnexion (LWT)

Avantages Sparkplug B :

  • Payload Protobuf (binaire, 3 à 10x plus compact que JSON)
  • Gestion du cycle de vie des équipements (BIRTH/DEATH)
  • Alias de métriques pour réduire la bande passante
  • Compatibilité avec HiveMQ Sparkplug Extension, Ignition Cirrus Link, AWS IoT SiteWise

Sécurité OPC UA + MQTT : défense en profondeur​

La combinaison OPC UA et MQTT offre deux couches de sécurité :

Couche OPC UA (terrain → bridge) :

  • Mode Security : Sign & Encrypt (AES-256)
  • Authentification : certificat x509 ou username/password
  • Validation des certificats serveur et client

Couche MQTT (bridge → cloud) :

  • Transport : TLS 1.3
  • Authentification : certificat client x509 (mutual TLS)
  • Autorisation : ACL par topic sur le broker

Cette architecture defense-in-depth est conforme aux recommandations IEC 62443 pour la cybersécurité des systèmes industriels.

Compatibilité avec les plateformes cloud majeures​

PlateformeProtocoleModule spécifique
AWS IoT CoreMQTT TLSAWS IoT SiteWise (OPC UA natif)
Azure IoT HubMQTT / AMQPAzure IoT OPC Publisher (open source)
HiveMQ CloudMQTT 5.0 + SparkplugSparkplug Extension native
Eziwan CloudMQTT TLSDashboard + alertes intégrés
Ignition (Inductive Automation)MQTT TransmissionModule Cirrus Link Sparkplug

Questions fréquentes

À consulter aussi