Modbus : le protocole de bus de terrain industriel d’origine
Modbus remains widely deployed because its data model is simple, not because every implementation is simple. This guide explains frames, register mapping, ti...
Un bus de terrain est un protocole de communication utilisé dans les réseaux industriels pour connecter des appareils de terrain à des contrôleurs industriels. Un bus de terrain réduit la quantité de câblage nécessaire entre les contrôleurs et les appareils, car plusieurs appareils peuvent être connectés à la même paire de fils.
Il existe un certain nombre de technologies de bus de terrain populaires, notamment Modbus, Profibus, Foundation Fieldbus, ControlNet, DeviceNet et bien d’autres.
En 1979, Modicon a introduit un nouveau protocole exploitant la couche application du modèle OSI, spécifiquement pour ses automates programmables industriels. Ce protocole, appelé Modbus, est devenu le premier bus de terrain largement utilisé dans l’histoire de l’automatisation.
Figure 1. Un automate programmable industriel connecté à des appareils de terrain
Introduction à Modbus
Modbus a été conçu pour connecter des appareils de terrain à des contrôleurs industriels. À l’époque de son invention, la plupart des appareils utilisaient des représentations de tension ou de courant pour communiquer leur état. Modbus peut gérer efficacement les bits discrets qui reflètent les états haut/bas des capteurs et des actionneurs, ainsi que les registres contenant des valeurs entières correspondant à des valeurs analogiques du processus.
La transition progressive vers les technologies de bus de terrain a fait de Modbus l’un des protocoles les plus simples, et de nouvelles versions ont été ajoutées au fil des ans.
À l’origine, Modbus était implémenté sur une liaison de communication série, c’est-à-dire RS-232/RS-485. Ces variantes sont encore couramment utilisées sous les noms Modbus RTU et ASCII. Finalement, le protocole a été adapté pour fonctionner sur TCP/IP et Ethernet. Cette version est communément appelée Modbus TCP et constitue l’implémentation de Modbus la plus répandue dans les installations modernes.
Modèle de communication
Modbus utilise un modèle maître/esclave pour les communications (client/serveur dans Modbus TCP). Un maître Modbus envoie une requête à un esclave Modbus, qui exécute des actions et répond au maître. Dans ce scénario, le maître est souvent un automate programmable industriel (PLC), tandis que les appareils de terrain jouent le rôle d’esclaves.
Une trame de message Modbus se compose d’une unité de données d’application (ADU) et d’une unité de données de protocole (PDU). L’ADU diffère selon le type de Modbus utilisé, tandis que la PDU est indépendante de la méthode de communication.
Une PDU se compose normalement d’un code de fonction et de données. Ces éléments sont encapsulés dans l’ADU avec une adresse et un code de contrôle d’erreur. Modbus TCP utilise un en-tête MBAP (Modbus Application Protocol) dans l’ADU.
Figure 2. ADU et PDU Modbus pour Modbus ASCII/RTU (en haut) et Modbus TCP (en bas). Image adaptée de Modbus.org
Pour que la PDU reste indépendante de la couche de communication sous-jacente, elle doit respecter les limites de taille de la spécification série d’origine. Cette taille était de 256 octets pour l’ADU sur RS-485. Nous devons donc tenir compte de l’ADU – 1 octet d’adresse et 2 octets de contrôle d’erreur –, ce qui limite la PDU à un total de 253 octets. Notez que l’adresse dans l’ADU correspond en réalité à l’identifiant de l’esclave sur le réseau Modbus.
La partie données de la PDU contient des champs spécifiques au code de fonction ainsi que les données réellement transmises. Ces champs seront examinés en détail plus loin dans l’article.
Représentation des données
Modbus classique possède deux modes de transmission : ASCII et RTU.
En mode ASCII, les données sont envoyées sous forme de caractères ASCII compris entre 0 et 9 et entre A et F, tandis qu’en mode RTU, elles sont représentées en binaire sur 8 bits. Les données et les adresses sont codées en big-endian, l’octet de poids fort étant transmis en premier.
Les données Modbus se présentent sous quatre types principaux :
- Entrées discrètes
- Bobines (sorties)
- Registres d’entrée
- Registres de maintien
Les entrées discrètes représentent un seul bit de données et sont en lecture seule. Les bobines représentent également un seul bit, mais peuvent être lues et écrites. Les registres d’entrée représentent des données 16 bits en lecture seule, tandis que les registres de maintien sont des données 16 bits en lecture-écriture.
Figure 3. Tirée de la spécification du protocole Modbus
Pour chaque type, un maximum de 2^16 (65536) éléments de données peut être situé dans la mémoire d’un appareil. Il existe des codes de fonction spécifiques pour accéder à chacun des différents types de données, chaque type disposant souvent de son propre bloc de mémoire dédié.
Pour adresser un élément de données, un maître utilise simplement la plage de 0 à 65535. L’élément de données 1 se trouve à l’adresse 0x0000. L’élément de données 2 se trouve à l’adresse 0x0001. L’élément de données 65536 se trouve à l’adresse 0xFFFF. Notez que les appareils ne sont pas tenus de disposer des 65536 éléments de données ; en fait, la plupart des terminaux d’E/S déportées qui utilisent Modbus sont largement en dessous de cette limite maximale.
Transactions Modbus
Après avoir compris comment les données sont représentées dans Modbus, nous pouvons maintenant examiner les transactions en détail. Nous le ferons du point de vue de la PDU, puisque la PDU est indépendante de la couche de communication.
Les transactions Modbus utilisent des instructions sous forme de caractères hexadécimaux, où un seul octet de 8 bits est au format 0x00, avec une plage de 0 à F pour chaque caractère. Un registre de 16 bits équivaut donc à deux octets, représentés au format 0x0000.
La spécification Modbus définit trois types de PDU :
- Requête Modbus
- Réponse Modbus
- Réponse d’exception Modbus
Le maître lance une requête à l’aide du code de fonction, tandis que l’esclave envoie une réponse en réaction à cette requête. Une réponse réussie reprend le code de fonction envoyé par le maître. Une réponse d’exception renvoie le même code de fonction, mais avec le msb (bit de poids fort) activé pour indiquer qu’un problème s’est produit.
La spécification Modbus définit un certain nombre de codes de fonction. Le code de fonction 0x01 correspond à la fonction de lecture des bobines.
La figure 4 montre à quoi peut ressembler une requête et une réponse de lecture des bobines. Le maître Modbus envoie une requête avec le code de fonction 0x01 (lecture des bobines), en commençant par le premier élément de données (adresse 0x0000) et en ne lisant qu’une seule bobine. La fonction de lecture des bobines permet de lire jusqu’à 2000 (0x7D0) bobines à la fois.
Figure 4. Transaction de lecture des bobines
En cas de succès, l’esclave répond avec le même code de fonction et un compteur indiquant le nombre de bobines auxquelles il répond. L’état des bobines occupera n octets, chaque bit indiquant si la bobine correspondante est activée (1) ou désactivée (0).
Dans ce cas, la bobine à l’adresse 0x0000 est activée. Si la requête n’avait pas abouti, la réponse d’exception aurait contenu le code de fonction avec le msb activé (0x81), ainsi qu’un code d’exception expliquant le problème. Le code d’exception 0x02 signifie qu’une adresse de données non valide a été utilisée, c’est-à-dire qu’il n’y a aucune bobine à l’adresse 0x0000 dans la mémoire de cet esclave.
L’exemple suivant illustre une transaction d’écriture d’un registre unique (code de fonction 0x06). Ici, le maître demande l’écriture des données 0xA0A0 à l’adresse 0x00FF. La réponse de l’esclave est simplement un écho de la requête.
L’exemple de réponse d’exception présenté ici montre le code de fonction avec le msb activé, ainsi qu’un code d’exception 0x04. Ce code signifie qu’une erreur irrécupérable s’est produite alors que l’esclave tentait d’exécuter la requête.
Figure 5. Transaction d’écriture d’un registre unique
Tous les codes de fonction Modbus suivent un schéma similaire à celui des deux exemples présentés ci-dessus.
La figure 6 présente une liste des codes de fonction courants ainsi que des codes d’exception utilisés dans les réponses d’exception. Pour plus d’informations, consultez la spécification Modbus.
Figure 6. Codes de fonction et codes d’exception
Conclusion
Modbus permet aux automates programmables (PLC) de communiquer avec toutes sortes d’unités distantes, notamment des banques d’E/S, des unités terminales et d’autres contrôleurs, en s’appuyant sur une méthode standard de lecture et d’écriture des informations discrètes et entières, couvrant presque tous les scénarios impliquant le transfert de données numériques.
Modbus est aujourd’hui une norme industrielle et représente à ce jour le protocole industriel libre de redevances le plus répandu, bien qu’il soit antérieur à la plupart des systèmes de contrôle modernes. On le trouve dans les usines et les installations industrielles du monde entier et, malgré sa longévité, il restera certainement un protocole industriel pertinent pendant de nombreuses années.
