Produits/ EMU Professional II/ TCP/IP

Interface · EMU Professional II

Le TCP/IP sur l’EMU Professional II : Modbus TCP et MQTT

Pas de bus de terrain, pas de convertisseur de niveau – la version TCP/IP se branche sur l’Ethernet. Deux approches fondamentalement différentes y circulent : Modbus TCP va chercher les valeurs, MQTT les livre. Ce choix décide davantage de votre architecture que du matériel.

Deux voies depuis la même prise

Quelle est la différence entre Modbus TCP et MQTT ?


Sur l’Ethernet, le compteur propose deux protocoles. Ils diffèrent surtout par le sens dans lequel circulent les données – et ce sens détermine l’architecture de votre installation davantage que le matériel.

Modbus TCP est une procédure question-réponse : un client ouvre une liaison et va chercher des registres quand il le veut. MQTT inverse cela : le compteur annonce ses valeurs de lui-même à un broker, et qui en a besoin s’y abonne. L’un va chercher, l’autre livre.

Modbus TCP

Le même modèle de registres que le Modbus RTU, mais sur Ethernet au lieu du RS-485. La somme de contrôle CRC disparaît, car TCP s’en charge déjà ; à la place, chaque télégramme porte un en-tête MBAP avec un numéro de transaction et un identifiant d’unité. Le port standard est le 502.

La lecture utilise les mêmes codes de fonction qu’en RTU, habituellement 3 et 4 pour les holding et input registers. Les valeurs 32 bits sont réparties sur deux registres ; les adresses de registres et l’ordre des octets figurent dans le manuel.

L’avantage pratique par rapport au RTU : plusieurs clients en même temps, pas de monopole du maître, pas d’intervalle de silence, pas de questions de topologie. L’inconvénient : chaque compteur a besoin d’une adresse IP et d’une place dans votre plan de réseau.

Port

502

Mode de fonctionnement

Le client demande, le compteur répond

Modèle de données

Registres 16 bits, codes de fonction 3 et 4

Typique pour

Supervision, SCADA, automatisation

MQTT

MQTT travaille avec un broker au milieu. Le compteur publie ses valeurs sous un topic – un chemin hiérarchique tel que batiment/sous-sol/compteur-03/energie – et tout intéressé s’abonne à ce topic. L’émetteur et le destinataire ne se connaissent pas ; ils ne connaissent que le broker.

Cela résout deux problèmes à la fois. Premièrement, personne n’a besoin d’interroger : les valeurs arrivent quand il y en a. Deuxièmement, la liaison est sortante – le compteur se connecte au broker, et non l’inverse. Le pare-feu n’a donc besoin d’aucune autorisation entrante, ce qui rend les raccordements au cloud praticables.

QoS fixe la garantie de livraison : 0 envoie et oublie, 1 garantit au moins une livraison, 2 exactement une. Pour des valeurs de compteurs, QoS 1 est le compromis usuel. TLS chiffre la liaison.

Mode de fonctionnement

Le compteur publie, les intéressés s’abonnent

topic

chemin hiérarchique, librement choisi

QoS

0, 1 ou 2 – garantie de livraison

Typique pour

Tableaux de bord, solutions cloud, plateformes IoT

Le raccordement MQTT aux tableaux de bord et aux solutions cloud est réservé à la version TCP/IP.

Réseau

De quoi l’informatique a-t-elle besoin pour des compteurs sur le réseau ?


Adresses fixes

Les compteurs interrogés en Modbus TCP ont besoin d’une adresse stable – attribuée statiquement ou liée à l’adresse MAC par une réservation DHCP. Une IP changeante signifie que la supervision perd l’appareil.

Un segment propre

La métrologie appartient normalement à un VLAN qui lui est propre, séparé du réseau bureautique. Cela facilite les règles de pare-feu et évite qu’un problème de réseau côté bureaux n’emporte les données de facturation.

Sens du pare-feu

Pour le Modbus TCP, le client doit atteindre le compteur – une liaison entrante dans le réseau de mesure. Pour MQTT, une liaison sortante vers le broker suffit. Lorsque les données doivent quitter le bâtiment, MQTT est donc la voie nettement plus simple à travers le pare-feu.

Micrologiciel

Pour la version TCP/IP, nous mettons à disposition un outil de mise à jour dédié ; le téléchargement se trouve plus bas.

Liste de contrôle avant la remise à l’informatique

  • Nombre d’appareils et adresses IP nécessaires
  • Statique ou réservation DHCP
  • VLAN et routage vers le système de supervision
  • Pour MQTT : adresse du broker, port, TLS, identifiants
  • Un schéma de topics encore lisible dans cinq ans

Schéma de topics

Hiérarchie par lieu et par fonction plutôt que par numéro d’appareil. site/batiment/etage/point-de-mesure/grandeur survit à un remplacement d’appareil ; compteur/0815 non.

Cas d’usage

Compteurs directement sur le réseau ou via le M-Center ?


Les deux fonctionnent, et la réponse tient moins au compteur qu’à l’installation qui l’entoure.

Directement sur le réseau

Pertinent avec peu de points de mesure, là où l’Ethernet est déjà en place, et lorsque le système cible utilise lui-même Modbus TCP ou MQTT. Chaque compteur est alors un nœud réseau à part entière, avec sa propre adresse et son propre entretien.

Avec le nombre, la donne change : vingt compteurs, ce sont vingt adresses IP, vingt versions de micrologiciel et vingt endroits où une relève peut échouer sans que personne ne le remarque.

Via l’EMU M-Center

Le M-Center relève jusqu’à 60 appareils par Modbus TCP et les regroupe en un point unique sur le réseau. Au lieu de vingt appareils, l’informatique en entretient un. Et comme le même appareil gère en même temps le M-Bus et le Modbus RTU, les compteurs des trois interfaces se retrouvent dans la même base de données.

S’y ajoute ce qu’un compteur seul ne peut pas faire : 16 Go de mémoire pour l’historique, la surveillance des indicateurs d’erreur et des valeurs aberrantes, et la transmission simultanée vers BACnet IP, OPC UA, MQTT, (s)FTP et e-mail – supervision, cloud et facturation depuis une seule source, sans que trois systèmes se disputent le même compteur.

Règle empirique

Jusqu’à environ cinq points de mesure et un système cible : en direct. Au-delà, ou dès qu’un deuxième système cible s’ajoute, le M-Center est presque toujours rentable – pas pour des raisons techniques, mais pour des raisons d’exploitation.

Positionnement

Modbus TCP ou MQTT – lequel pour quoi ?


La supervision doit interroger des valeurs instantanéesModbus TCP
Les données doivent aller dans un cloud ou un tableau de bordMQTT
Le pare-feu n’autorise aucune liaison entranteMQTT, parce que sortant
Plusieurs destinataires pour les mêmes valeursMQTT, par abonnements
Le SCADA existant ne gère que ModbusModbus TCP
Beaucoup de compteurs, plusieurs systèmes ciblesLes deux, regroupés via l’EMU M-Center

Documents

Manuels et fiches techniques à télécharger


Cette page explique le principe. Les listes de registres, la structure des télégrammes, l’affectation des bornes et les paramètres exacts de chaque version figurent dans le manuel d’interface.

PDFManuel de l’interface TCP/IP1475 · Professional II · anglais PDFManuel des registres Modbus1485 · table des registres · anglais ZIPOutil de mise à jour TCP/IPMise à jour du micrologiciel de la version TCP/IP PDFManuel M-Center2151 · regroupement et transmission

Flux de données

Comment les valeurs mesurées arrivent-elles dans Joulio-Web par MQTT ?


Le compteur n’attend pas d’être interrogé – il publie ses valeurs lui-même. Cela change la configuration du pare-feu et permet à plusieurs systèmes de lire la même valeur en même temps.

  1. Le compteur établit lui-même la liaison – vers l’extérieur, pas vers l’intérieur. Le pare-feu n’a donc besoin d’aucune autorisation entrante.
  2. Chaque valeur mesurée part comme message vers un topic. La structure des topics détermine comment les valeurs seront attribuées par la suite.
  3. Le broker distribue le message à tous ceux qui se sont abonnés à ce topic. Joulio-Web est l’un de ces abonnés, un tableau de bord peut en être un autre.
  4. Les liaisons sont chiffrées avec TLS. Sans identifiants valides, le broker n’accepte aucun message.

Le chemin des valeurs mesurées, de l’EMU Professional II TCP/IP jusqu’à Joulio-Web en passant par un broker MQTT. Comme c’est le compteur qui établit la liaison, l’autorisation du pare-feu reste orientée vers l’extérieur.

Questions fréquentes

Questions fréquentes sur l’interface


Quelle est la différence entre Modbus TCP et MQTT ?

Modbus TCP, c’est aller chercher : un client ouvre une liaison vers le compteur et lit les registres quand il le veut. MQTT, c’est livrer : le compteur publie ses valeurs auprès d’un broker, et les intéressés s’y abonnent. Modbus TCP convient à la supervision et au SCADA, MQTT aux tableaux de bord et au cloud.

Quel port le Modbus TCP utilise-t-il ?

Le port 502 par défaut. La somme de contrôle CRC du Modbus RTU disparaît, car TCP sécurise déjà la transmission ; à la place, chaque télégramme porte un en-tête MBAP avec un numéro de transaction et un identifiant d’unité.

Pourquoi MQTT passe-t-il plus facilement le pare-feu ?

Parce que la liaison est sortante : le compteur se connecte au broker, et non l’inverse. Le Modbus TCP exige au contraire une liaison entrante dans le réseau de mesure. Dès que des données doivent quitter le bâtiment, MQTT est donc la voie nettement plus simple.

Chaque compteur a-t-il besoin d’une adresse IP fixe ?

Pour le Modbus TCP, oui – attribuée statiquement ou liée à l’adresse MAC par une réservation DHCP. Une adresse changeante signifie que la supervision perd l’appareil.

À partir de quand le M-Center vaut-il mieux qu’un raccordement réseau direct ?

En règle générale à partir d’environ cinq points de mesure, ou dès qu’un deuxième système cible s’ajoute. Le M-Center relève jusqu’à 60 appareils par Modbus TCP, les regroupe en un seul nœud réseau, conserve l’historique dans 16 Go et sert en même temps la supervision, le cloud et la facturation.

Comment nommer les topics MQTT ?

De manière hiérarchique, par lieu et par fonction plutôt que par numéro d’appareil. Un schéma tel que site/batiment/etage/point-de-mesure/grandeur survit à un remplacement d’appareil ; une dénomination par numéro de série, non.

Vous hésitez à choisir le TCP/IP ?


Envoyez-nous le nombre de points de mesure, les distances et le système cible. Nous vous dirons quelle version a du sens – et quand une autre interface serait le meilleur choix.

Téléphone
+41 (0)41 545 03 00

Support technique
helpdesk@emuag.ch

Commandes Suisse
orders@emuag.ch