Connecter OPC UA à Mosquitto / broker MQTT

Avant de commencer

• Quelque chose qui parle réellement OPC UA : un publisher, un collecteur ou une passerelle. Le broker est une destination, pas un client, et aucune configuration de broker ne fera publier un automate.
• Une décision sur le format de payload avant que le premier topic n'existe. OPC UA PubSub sur MQTT en JSON est la voie normalisée ; le format JSON propre à un collecteur et Sparkplug B sont les alternatives courantes, et elles ne sont pas interchangeables.
• Une convention de nommage des topics convenue avec celui qui les consommera, car l'arborescence de topics est le contrat, et la renommer plus tard casse tous les abonnés d'un coup.
• TLS avec de vrais certificats et une authentification configurée avant que quoi que ce soit ne publie en production. Un broker ouvert sur un réseau d'usine, c'est une usine ouverte.

Mise en place

1. Configurez d'abord le broker pour TLS et l'authentificationDéfinissez un listener explicite, désactivez l'accès anonyme, configurez des identifiants ou des certificats client, et ajoutez un contrôle d'accès par topic et par client. Le faire avant qu'un seul publisher n'existe est bien plus simple que de le rattraper ensuite sur une flotte de publishers.
2. Concevez la hiérarchie de topics à partir de l'usine, pas de l'espace d'adressageUne arborescence de topics dérivée mécaniquement des browse paths OPC UA est commode et produit des topics auxquels personne ne peut s'abonner utilement. Dérivez-la du site, de la zone, de la ligne et de la machine, puis placez le nom du signal à la feuille. Là où un publisher propose effectivement un routage automatique depuis les browse names, sachez que les caractères réservés MQTT doivent être échappés, et vérifiez ce que le publisher en fait.
3. Choisissez et figez l'encodage de la charge utileSi vous utilisez OPC UA PubSub sur MQTT, tranchez entre UADP et JSON, et si c'est JSON, entre la forme reversible et non-reversible. Le JSON non-reversible perd l'information de type et ne permet pas l'aller-retour, surprise qui se manifeste des mois plus tard chez un consommateur en aval.
4. Décidez des retained messages et du last will par classe de topicLes retained messages donnent immédiatement la valeur courante à un nouvel abonné, ce qui convient pour l'état et l'identité et ne convient pas pour les événements, où un message retenu rejoue quelque chose qui a déjà eu lieu. Configurez un topic de last will par publisher pour qu'un collecteur tombé soit visible.
5. Réglez la qualité de service selon le sens de la donnéeUne qualité de service 0 convient pour une analogique à cadence élevée que vous rééchantillonnerez de toute façon, et est inacceptable pour un événement d'arrêt ou un incrément de compteur, car un simple à-coup réseau le perd. Utilisez le at-least-once pour tout ce dont dépend un calcul, et rendez les consommateurs idempotents.
6. Vérifiez le payload avec un client avant de construire les consommateursAbonnez-vous avec MQTT Explorer ou un client en ligne de commande et lisez les octets réellement présents sur le fil. Notez en particulier que, dans l'encodage JSON d'OPC UA, un statut Good vaut zéro et est omis : un champ de statut absent signifie donc bon, et non donnée manquante.
7. Surveillez le broker et les publishers séparémentSuivez le nombre de connexions au broker et les messages perdus, et alertez sur la vitalité des publishers via des topics de last will ou un topic de battement de cœur par machine. Le silence sur un topic est ambigu et exige un signal indépendant pour être interprété.

À quoi ressemble l'espace d'adressage

MQTT n'a pas de modèle, seulement une chaîne de topic et un payload ; tout ce que connaissait l'espace d'adressage OPC UA doit donc être ré-exprimé par ce qui publie. C'est la décision de conception centrale d'un unified namespace : la hiérarchie des topics plus le schéma du payload constituent l'intégralité du modèle d'information du point de vue de tous les consommateurs. OPC UA PubSub transporte les métadonnées de dataset à côté des données, ce qui préserve les types et les noms de champs, et c'est pourquoi la voie normalisée vaut la configuration supplémentaire ; le JSON d'un collecteur ad hoc ne le fait généralement pas, et le sens d'un champ vit alors dans un document quelque part. Quel que soit votre choix, publiez l'URI d'espace de noms OPC UA et l'identifiant de nœud dans le payload ou dans les métadonnées du topic, pour qu'une valeur puisse être retracée jusqu'au nœud dont elle provient.

Les pièges

• Prendre le broker pour l'intégration est l'erreur classique. Le broker déplace des octets ; la sémantique vient de la conception des topics et des charges utiles du publisher, et c'est dans cette conception que se trouve le vrai travail du projet.
• Une qualité de service 0 sur des données de type événement perd silencieusement des événements précisément dans les conditions réseau qui produisent les événements les plus intéressants. Les enregistrements d'arrêt et les incréments de compteur exigent une livraison at-least-once.
• Les messages retained sur des topics d'événements rejouent des événements périmés à chaque nouvel abonné, ce qui corrompt les consommateurs qui supposent qu'un message signifie « maintenant ».
• L'encodage JSON non réversible perd l'information de type et ne peut pas faire l'aller-retour. Choisissez délibérément et consignez le choix ; le découvrir en aval coûte cher.
• Dans l'encodage JSON d'OPC UA, un statut Good vaut zéro et est omis : un consommateur qui interprète un champ de statut absent comme une donnée absente jettera donc des valeurs bonnes.
• Les arborescences de topics dérivées automatiquement des chemins de browse encodent la structure interne de l'automate dans votre namespace d'usine, et elles changent quand le programme automate change.
• Le broker devient un point de défaillance unique à l'échelle de l'usine et une frontière de sécurité à l'échelle de l'usine. Mettez-le en cluster ou acceptez le risque explicitement, et ne laissez jamais l'accès anonyme activé parce qu'il était pratique à la mise en service.
• MQTT ne garantit aucun ordre entre topics différents. Un changement d'état et le comptage qui va avec peuvent arriver dans le désordre s'ils sont publiés sur des topics distincts : mettez donc dans un même message les faits qui doivent rester cohérents.

En extraire les données OEE

Le broker n'apporte rien au TRS par lui-même et peut le dégrader silencieusement. Ce qu'il fait bien, c'est découpler la collecte du calcul : une plateforme d'analyse peut consommer l'état machine, les comptages et les motifs sans maintenir de sessions sur chaque PLC. Les exigences qu'il impose sont concrètes : publier les transitions d'état comme des événements portant dans le payload l'horodatage propre à la machine plutôt que de se fier à l'heure d'arrivée, publier les incréments de comptage ou les compteurs absolus avec assez de contexte pour détecter les remises à zéro, utiliser une livraison at-least-once pour les deux, et donner à chaque machine un topic de heartbeat ou de last-will afin que le silence puisse être distingué d'une machine à l'arrêt. Le temps de production planifié, les calendriers d'équipe, le contexte d'ordre de fabrication et les temps de cycle standard ne sont pas des données machine : ils doivent parvenir au calcul depuis le MES ou l'ERP, et non être publiés à la main sur un topic puis oubliés.

Dernière vérification le 7 septembre 2026 par rapport à OPC UA 1.05.07. OPC UA Connect est une ressource pédagogique et n'est pas affiliée à l'OPC Foundation.