OPC UA, MQTT ou Modbus : comparaison

Une mesure de puissance active peut traverser les trois protocoles avant d’arriver sur une plateforme énergétique. Elle sort du compteur sous forme de deux registres Modbus sans unité, heure ni état. Un automate peut l’exposer comme un nœud OPC UA doté d’un type, d’un StatusCode et de deux horodatages. Elle quitte le site dans un message MQTT au format convenu à l’avance entre émetteur et destinataire. Chaque étape peut lui faire perdre une partie de son sens ; les défauts de mise en service décrits plus bas apparaissent tous à l’une de ces étapes.

Comparaison directe

Registres Modbus et tables de registres

Presque tous les compteurs électriques, onduleurs et variateurs disposent d’une interface Modbus. Le protocole définit quatre tables : bobines et entrées discrètes (1 bit), registres d’entrée et registres de maintien (16 bits). Les entrées discrètes et les registres d’entrée sont en lecture seule. Les bobines et les registres de maintien permettent la lecture et l’écriture lorsque le dispositif les autorise. La fonction 03 lit les registres de maintien et la fonction 04 les registres d’entrée, jusqu’à 125 registres contigus par requête. La réponse n’indique pas ce que signifient les bits. Unité, facteur d’échelle, type de donnée et ordre des mots proviennent de la table des registres du fabricant ; le protocole n’inclut ni horodatage ni état. Le guide des tables de registres Modbus explique les informations à relever pour chaque point.

Sur RS-485, Modbus RTU est assez lent pour imposer un dimensionnement de la liste d’interrogation. Avec 8 bits de données, une parité paire et 1 bit d’arrêt, chaque caractère occupe 11 bits. La lecture de deux registres comporte une requête de 8 octets et une réponse de 9 octets. À 9 600 bauds, ces 17 caractères occupent 19,5 ms sur le fil. Ajoutez un silence de 3,5 caractères (4,0 ms) après chaque trame et le délai de réponse du compteur indiqué dans sa fiche technique. Si chaque transaction dure au total 60 ms, 20 compteurs lus 4 fois chacun nécessitent 4,8 s par cycle. Un seul maître peut interroger un bus RTU.

Modbus TCP supprime la limite liée au débit en bauds, mais introduit une limite de connexions. Beaucoup de compteurs n’acceptent que quelques connexions TCP simultanées ; certains n’en acceptent qu’une. Si un BMS et un Gateway interrogent le même compteur, l’un peut perdre sa connexion ou dépasser le délai d’attente sans erreur claire.

Espace d’adressage, état et sécurité OPC UA

OPC UA, défini par la série OPC 10000 (IEC 62541), modélise un système sous forme d’un espace d’adressage de nœuds. Un client peut parcourir la structure d’une pompe jusqu’à sa vitesse, ses heures de marche et ses alarmes. Chaque lecture d’une variable renvoie une DataValue : la valeur, son type, un StatusCode, un horodatage source issu de l’appareil ou de l’automate et un horodatage serveur issu du serveur OPC UA.

Les deux bits de poids fort du StatusCode indiquent sa gravité (partie 4, 7.38.1). Good vaut 00, Uncertain vaut 01 et Bad vaut 10. Par exemple, UncertainLastUsableValue (0x40900000) indique que la source qui mettait la valeur à jour s’est arrêtée. BadCommunicationError (0x80050000) indique que le serveur a perdu sa source. Un client qui conserve la valeur et écarte le StatusCode transforme ces états en lectures ordinaires.

Les unités d’ingénierie ne figurent pas sur tous les nœuds. La partie 8 définit EngineeringUnits comme une propriété facultative des variables analogiques. Beaucoup de serveurs exposent des variables simples sans unité ; celle-ci doit alors venir de la liste de points.

OPC UA sécurise chaque connexion à l’aide de certificats d’application. Le serveur propose des points de terminaison, chacun avec une politique et un mode de sécurité : None, Sign ou SignAndEncrypt. Les utilisateurs se connectent anonymement, avec nom d’utilisateur et mot de passe, ou avec un certificat. Désactivez sur le serveur le point de terminaison None. S’il reste disponible, un client configuré pour accepter n’importe quel point de terminaison peut se connecter sans signature ni chiffrement.

Le guide des identifiants de nœuds OPC UA explique les espaces de noms et identifiants ; le guide de migration OPC DA traite du passage depuis OPC Classic.

Brokers MQTT, sujets et contrats de charge utile

MQTT est un protocole de transport. Un éditeur envoie un message sur un sujet à un broker, qui le transmet à chaque client abonné. L’éditeur et les abonnés ne se connectent pas entre eux. Le broker devient le composant que toutes les parties doivent joindre et doit être sécurisé. Un éditeur ne peut pas savoir si un abonné a reçu un message ; il lui faut un accusé de réception applicatif ou un message d’état pour le vérifier.

MQTT propose des niveaux de qualité de service QoS 0, 1 et 2, les messages conservés et un testament. Si un intervalle keep-alive non nul est configuré et que le broker ne reçoit aucun paquet de contrôle MQTT du client pendant 1,5 fois cet intervalle, il ferme la connexion. Un testament enregistré est publié après cette fermeture, sous réserve du délai de testament (Will Delay) et des règles de session ; sa publication ne coïncide pas nécessairement avec le seuil keep-alive. Le guide MQTT QoS explique les options de livraison ; le guide MQTTS présente TLS et les autorisations sur les sujets.

MQTT ne définit pas le contenu des messages. MQTT 5 ajoute un indicateur de format de charge utile, un type de contenu et des propriétés utilisateur, mais ni noms de champs ni unités. Chaque intégration exige un contrat de charge utile : structure des sujets, noms des champs, unités, format des horodatages et représentation des données invalides. Si la plateforme destinataire impose son format, procurez-vous sa spécification des sujets et des charges utiles avant la mise en service.

Deux normes définissent un contrat au-dessus de MQTT. Sparkplug B (fondation Eclipse, ISO/IEC 20237:2023) utilise des sujets de la forme spBv1.0/group/message_type/edge_node/device et une charge utile Protocol Buffers. Les messages NBIRTH et DBIRTH déclarent chaque métrique et son type. NDEATH est enregistré comme testament du nœud. Les messages de données NDATA et DDATA sont publiés avec QoS 0 ; un numéro de séquence de 0 à 255 permet à l’application hôte de détecter une perte et de demander une nouvelle déclaration de naissance. OPC UA PubSub (partie 14) peut aussi utiliser un broker MQTT, avec un codage UADP ou JSON. Avec MQTT 3.1.1, l’abonné doit connaître à l’avance le codage employé.

Une lecture transmise par les trois protocoles

Un compteur mesure 200,5 kW de puissance active. Sa table des registres place cette valeur aux registres de maintien 0 et 1, en nombre flottant IEEE 754 de 32 bits, avec le mot de poids fort en premier.

Sur Modbus, le Gateway lit les deux registres et reçoit 0x4348 et 0x8000. Assemblés avec le mot de poids fort en premier, ils donnent 0x43488000, soit 200,5. Si le Gateway place le mot de poids faible en premier, il obtient 0x80004348, soit environ −2,4 × 10⁻⁴¹. Un tableau de bord affiche cette valeur comme zéro : le défaut ressemble alors à une charge à l’arrêt. Le décodeur de registres Modbus montre les quatre ordres possibles pour deux registres.

Sur OPC UA, un automate qui lit le même compteur peut l’exposer comme nœud ns=2;s=Meter1.ActivePower. Une lecture renvoie 200,5 sous forme de Float, avec StatusCode Good (0x00000000), l’heure d’échantillonnage de l’automate et l’heure de réponse du serveur. Si l’automate perd le compteur, le serveur peut continuer à renvoyer 200,5 avec UncertainLastUsableValue. La valeur n’est valide que tant que l’état est Good.

Sur MQTT, un contrat JSON peut porter le point sous la forme {"point":"meter1/active_power","value":200.5,"unit":"kW","ts":"2026-09-24T10:15:00Z","quality":"good"}. Avec Sparkplug B, la même valeur est une métrique Float dans un message DDATA sur spBv1.0/site-a/DDATA/gateway-1/meter-1, avec un horodatage en millisecondes depuis l’époque Unix. Sparkplug ne prévoit pas de champ standard pour le StatusCode OPC UA. Convenez de la façon d’envoyer une valeur Uncertain ou Bad, par exemple sous forme de métrique null, avant la mise en service.

Défaillances à tester lors de la mise en service

Le guide des passerelles de protocole indique ce qu’il faut spécifier pour chaque point converti. Le guide des horodatages source et d’arrivée explique quel horodatage conserver.

Choisir une interface

Le guide BACnet et Modbus traite des interfaces du bâtiment.

OPC UA, MQTT et Modbus avec Edge

Edge sur le Gateway ZGW-20 joue le rôle de passerelle. Il lit les équipements Modbus TCP et RTU. Il est aussi client OPC UA et lit les nœuds de variables à un intervalle défini, de 1 s à 86 400 s. Il prend en charge les modes de sécurité None, Sign et SignAndEncrypt, avec une connexion anonyme, par nom d’utilisateur ou par certificat. Gardez l’horloge du Gateway exacte : la validation des certificats en dépend. Les appareils sans fil EpiSensor, les capteurs LoRaWAN et les contrôleurs BACnet/IP rejoignent le même modèle de données.

Edge lit OPC UA par interrogation périodique. Il n’utilise ni abonnements OPC UA ni PubSub ; il n’utilise donc pas les bandes mortes côté serveur, et un changement plus court que l’intervalle d’interrogation peut passer inaperçu. Chaque point reçoit l’horodatage de lecture prévu, pas l’horodatage source OPC UA. Le point stocké ne porte pas le StatusCode OPC UA. L’indicateur de qualité d’Edge mesure la part des lectures attendues reçues au cours d’une fenêtre glissante de 15 minutes : c’est une mesure différente. Testez la représentation dans Edge des valeurs Uncertain et Bad du serveur avant d’en dépendre.

Edge envoie les données vers l’amont par MQTTS ou HTTPS. Il peut aussi servir des points associés à un BMS sous forme de registres Modbus TCP, sur son propre port 10502, et non 502.