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