Protocoles de communication pris en charge

Modbus (RTU / TCP)

Objet et description

Protocole industriel simple et largement répandu pour l’échange de données de process entre automates, capteurs et actionneurs. Développé en 1979 par Modicon (aujourd’hui Schneider Electric), il est devenu le standard de fait de l’automatisation industrielle. Il est utilisé dans les systèmes SCADA, les automates programmables, les variateurs de fréquence, les appareils de mesure et les capteurs. Grâce à sa simplicité de mise en œuvre et à ses besoins minimes en ressources de calcul, le protocole est parfaitement adapté aux systèmes embarqués et aux appareils à mémoire limitée.

Architecture et modèle de données

Le modèle de données fondé sur les registres repose sur quatre types d’espace d’adressage :

• Coils (0x) — sorties discrètes (lecture/écriture de valeurs binaires)
• Discrete Inputs (1x) — entrées discrètes (lecture seule)
• Input Registers (3x) — registres d’entrée 16 bits (lecture seule)
• Holding Registers (4x) — registres de maintien 16 bits (lecture/écriture)

Architecture client-serveur (maître-esclave) : l’appareil maître initie les requêtes, les esclaves répondent. Chaque appareil esclave possède une adresse unique (1–247). Le protocole ne comporte aucune sémantique de données intégrée — l’interprétation des valeurs des registres est définie au niveau applicatif et dans la documentation de l’appareil. Il prend en charge les opérations de lecture et d’écriture sur un ou plusieurs registres.

Transport

Modbus RTU :

• Liaisons série RS-485 (jusqu’à 32 appareils par bus, distance jusqu’à 1200 m) ou RS-232 (point à point)
• Représentation binaire des données
• Vérification d’intégrité par CRC-16
• Débit : de 1200 à 115200 bauds
• Transmission semi-duplex

Modbus TCP :

• Encapsulation des trames Modbus dans TCP/IP (port 502)
• En-tête MBAP (Modbus Application Protocol) pour l’identification des transactions
• Transmission duplex intégral
• Possibilité de travailler simultanément avec plusieurs appareils
• Pas de somme de contrôle requise (la fiabilité étant assurée par TCP)

Principales fonctionnalités

• Lecture et écriture de signaux discrets (Coils) et de registres
• Prise en charge des codes de fonction standard (FC 01–06, 15–16, 23)
• Fonctions de diagnostic (FC 08)
• Lecture des données d’identification de l’appareil (FC 17, 43)
• Besoins minimes en ressources de calcul pour les appareils
• Mise en œuvre et débogage simples
• Faible coût de déploiement
• Gestion des exceptions et codes d’erreur
• Prise en charge des messages de diffusion (adresse 0) en RTU
• Extensibilité jusqu’à 247 appareils sur une ligne (RTU) ou illimitée via TCP

OPC UA

Objet et description

Standard universel et multiplateforme (OPC Unified Architecture, IEC 62541) pour l’échange sécurisé et structuré de données industrielles, de métadonnées et d’informations sémantiques. Développé par l’OPC Foundation comme successeur des spécifications OPC DA/AE/HDA classiques, il élimine la dépendance aux technologies Microsoft DCOM. Il permet l’intégration verticale et horizontale dans les systèmes industriels — du niveau terrain aux systèmes d’information d’entreprise (ERP, MES). Il prend en charge les concepts d’Industrie 4.0 et de jumeaux numériques grâce à de riches capacités de modélisation de l’information.

Architecture et modèle de données

Modèle de données orienté objet représentant l’information sous la forme d’un espace de nœuds adressable (Address Space) :

• Nœuds de différents types : Variable, Object, Method, View, DataType, ReferenceType
• Attributs des nœuds : Value, DataType, AccessLevel, Timestamp, Quality, DisplayName, etc.
• Références entre nœuds : hiérarchiques, associatives, par composant
• Types de données : primitives, structures, tableaux, énumérations

Services pris en charge :

• Subscription — surveillance des changements de données avec intervalles d’échantillonnage et filtres configurables
• Events & Alarms — notifications asynchrones d’événements, d’alarmes et d’états
• Historical Access — accès aux données et événements archivés
• Methods — appel de procédures à distance sur les appareils

Modèles d’information sectoriels (Companion Specifications) : construction mécanique, énergie, pétrole et gaz, pharmacie.

Transport

Protocole binaire UA sur TCP/IP :

• Protocole binaire à sérialisation optimisée (port 4840)
• Hautes performances et surcharge minimale

HTTPS / SOAP :

• Profil Web Services pour l’intégration avec les systèmes d’entreprise
• Encodage JSON pour les applications cloud

OPC UA PubSub :

• Modèle éditeur-abonné pour les systèmes distribués
• Transport : UDP Multicast, MQTT, AMQP, Ethernet TSN
• Transmission déterministe pour les applications à contraintes temporelles

Sécurité :

• Modes de sécurité à plusieurs niveaux (None, Sign, SignAndEncrypt)
• Certificats X.509 pour l’authentification
• Chiffrement AES, RSA

Principales fonctionnalités

• Modélisation de l’information : transmission non pas seulement de valeurs « brutes », mais de données structurées complexes dotées de sémantique, de typage et de métadonnées
• Abonnements avec intervalles d’interrogation configurables, filtres à bande morte (deadband) et mise en mémoire tampon
• Événements et système d’alarmes avec filtrage conditionnel
• Appel de méthodes pour la commande des appareils et l’exécution d’opérations
• Accès aux données historiques avec agrégation
• Découverte de services dans les réseaux locaux
• Sécurité intégrée : chiffrement des canaux, authentification par certificat ou par nom d’utilisateur/mot de passe, contrôle d’accès au niveau des nœuds
• Redondance et tolérance aux pannes des serveurs
• Multiplateforme : Windows, Linux, VxWorks, QNX et autres systèmes d’exploitation
• Extensibilité : des microcontrôleurs aux systèmes distribués

MQTT

Objet et description

Protocole de messagerie léger (Message Queuing Telemetry Transport) destiné à la télémétrie, à la supervision à distance et à la gestion des appareils IoT, optimisé pour les réseaux peu fiables, à bande passante limitée et à latence élevée. Développé en 1999 par IBM pour la surveillance d’oléoducs, il a été normalisé par l’OASIS et l’ISO/IEC (20922:2016). Il est largement utilisé dans l’IoT industriel, la domotique, la télématique des véhicules et les applications mobiles. Le protocole vise à réduire au minimum le trafic réseau et la consommation d’énergie des appareils.

Architecture et modèle de données

Modèle Publish/Subscribe asynchrone avec un courtier centralisé :

• Publisher — appareil ou application publiant des messages sur des topics
• Subscriber — appareil ou application abonné pour recevoir les messages de topics
• Broker — serveur central de routage des messages (Mosquitto, HiveMQ, EMQ X, etc.)

Topics — structure de chemin hiérarchique pour catégoriser les messages :

• Séparateurs de niveau : / (par ex. factory/building1/temperature)
• Caractères génériques : + (un seul niveau), # (plusieurs niveaux)
• Exemple d’abonnement : sensors/+/temperature ou factory/#

Format des données défini par l’application : JSON, Protocol Buffers, XML, données binaires, texte.
Messages conservés (retained) : le courtier stocke le dernier message d’un topic et le délivre aux nouveaux abonnés.
Sessions persistantes : le courtier conserve les abonnements du client en cas de déconnexion.

Transport

• Couche transport : TCP/IP (port 1883 pour les connexions non sécurisées)
• TLS/SSL (port 8883) pour le chiffrement et l’authentification
• WebSockets pour l’intégration avec les navigateurs et les applications web
• Versions du protocole : MQTT 3.1.1 (la plus répandue), MQTT 5.0 (fonctionnalités étendues)
• Taille de l’en-tête : minimum 2 octets (en-tête fixe)
• Mécanisme keep-alive : PINGREQ/PINGRESP périodiques pour la surveillance de la connexion
• Le fonctionnement reposant sur un courtier assure le découplage éditeur-abonné, la mise à l’échelle horizontale et la gestion centralisée

Principales fonctionnalités

• QoS (Quality of Service), trois niveaux de garantie de livraison :
  • QoS 0 : au plus une fois (sans accusé de réception)
  • QoS 1 : au moins une fois (avec accusé de réception)
  • QoS 2 : exactement une fois (handshake en quatre étapes)
• Surcharge réseau minimale : en-tête fixe de 2 octets, encodage binaire efficace
• LWT (Last Will and Testament) : mécanisme de notification automatique en cas de déconnexion imprévue d’un appareil — le courtier publie un message prédéfini si le client met fin à la session de manière anormale
• Clean Session / Persistent Session : possibilité de restaurer les abonnements et les messages après reconnexion
• Messages conservés (Retained Messages) : disponibilité de la dernière valeur pour les nouveaux abonnés
• Faible consommation d’énergie : idéal pour les appareils alimentés par batterie
• Extensibilité : prise en charge de millions de connexions simultanées sur des clusters de courtiers
• Abonnements par caractères génériques pour un filtrage souple des topics

DLMS / COSEM (IEC 62056)

Objet et description

Standard international pour l’échange de données avec les compteurs de services publics : électricité, gaz, eau et chaleur (Device Language Message Specification / Companion Specification for Energy Metering). Développé par la DLMS User Association en collaboration avec l’IEC afin de garantir l’interopérabilité des compteurs intelligents au sein des systèmes automatisés de relevé et de facturation (AMBS). Il permet le relevé à distance des compteurs, la surveillance de la qualité de l’énergie, la gestion des tarifs et la détection des accès non autorisés. Il est largement utilisé par les gestionnaires de réseaux électriques, les fournisseurs de services publics et les intégrateurs de systèmes Smart Grid.

Architecture et modèle de données

Modèle objet COSEM (Companion Specification for Energy Metering) :

• Les données du compteur sont représentées sous forme d’objets logiques (objets COSEM) dotés de classes d’interface
• Codes OBIS (Object Identification System) — identifiant de six octets pour l’adressage universel des paramètres : A-B:C.D.E*F
  • A — type d’énergie (1=électricité, 6=chaleur, 7=gaz, 8=eau)
  • B — canal de mesure
  • C — grandeur physique (par ex. 1=énergie active)
  • D — type de mesure (8=période d’intégration)
  • E — zone tarifaire
  • F — profondeur historique

Protocole DLMS :

• Couche application selon le modèle OSI
• Associations avec différents droits d’accès : Public, Reader, Manager
• Authentification : Low Level Security (LLS), High Level Security (HLS) avec challenge-response
• Chiffrement : prise en charge de la DLMS Security Suite avec les algorithmes AES-GCM-128
• Profils de charge (Load Profiles) : objets tampons pour le stockage de séries temporelles
• Système de scripts : exécution de séquences d’actions sur le compteur

Transport

Couche physique et liaison de données :

• Port optique (IEC 62056-21, flag) — connexion directe via tête infrarouge pour le relevé local
• RS-485 / RS-232 avec protocole HDLC (High-Level Data Link Control) pour les réseaux multipoints
• TCP/IP (port 4059) — DLMS sur TCP ou encapsulation IP pour l’accès à distance
• GSM/GPRS/LTE — transmission de données via réseaux mobiles (protocoles d’encapsulation)
• PLC (Power Line Communication) — transmission sur les lignes électriques (PRIME, G3-PLC)
• M-Bus — pour l’intégration avec les systèmes de comptage d’eau et de chaleur

Profils de transmission selon l’implémentation du compteur :

• IEC 62056-46 : COSEM sur HDLC
• IEC 62056-47 : transport COSEM sur TCP-UDP/IP

Principales fonctionnalités

• Relevé du compteur — valeurs courantes de consommation d’énergie, de puissance, de tension, de courant, de facteur de puissance
• Profils de charge (Load Profiles) — données détaillées horodatées (intervalles de 15 min, horaires, journaliers)
• Journaux d’événements — enregistrement des ouvertures de capot frauduleuses, des coupures de courant, des surtensions, des modifications de paramètres
• Authentification et autorisation à plusieurs niveaux : contrôle d’accès basé sur les rôles (accès public, lecture, configuration)
• Gestion des tarifs — modification à distance des grilles et des barèmes tarifaires
• Synchronisation temporelle pour la précision des horodatages
• Commande de relais (connexion/déconnexion de la charge)
• Surveillance de la qualité de l’énergie (creux, surtensions, harmoniques)
• Prise en charge des opérations de groupe sur plusieurs compteurs
• Protection cryptographique des données et intégrité des messages