Académique Documents
Professionnel Documents
Culture Documents
Le Protocole Modbus PDF
Le Protocole Modbus PDF
1
Chapitre III Le protocole Modbus
1 - Introduction
Le protocole Modbus a été créé en 1979 par Modicon1 comme un moyen d'échange de
données entre leurs PLCs (programmable logic controller). Modicon a adopté l'approche de
publier ouvertement ses spécifications et permettre son utilisation par quiconque sans
demander de redevances. Ces facteurs, ainsi que la simplicité du protocole lui-même, lui ont
permis de devenir le premier standard de fait largement acceptée pour la communication
industrielle.
Actuellement, Modbus est utilisé dans des équipements allant des plus petits
capteurs et actionneurs compatibles réseau aux contrôleurs d'automatisation complexes et
aux systèmes SCADA (supervisory control and data acquisition). De plus, de nombreuses
implémentations sont disponibles gratuitement sous forme de code source dans une grande
variété de langages de programmation. Les lecteurs intéressés par les normes Modbus ou
l'une des nombreuses implémentations disponibles du protocole sont invités à accéder au
site Web Modbus-IDA à http://www.mobus.org.
Réponse
1
À l'époque, Modicon était un fabricant d'automates programmables industriels. C'est désormais une marque
de Schneider Electric.
2
Figure 3.1 Modèle de communication client/serveur
Typiquement, une RTU agissant comme un serveur Modbus permettra à ses entrées
digitales physiques d'être lues à travers la zone de mémoire "discrete inputs", les sorties
digitales d'êtres lues et écrites à travers la zone de mémoire "coils, l'état de toutes les
entrées analogiques sera lu à l'aide de la zone de mémoire "input registers" et les valeurs de
toutes les sorties analogiques seront lues et modifiées via la zone mémoire "holding
registers". Néanmoins, il appartient entièrement au fabricant du serveur de décider de la
sémantique attribuée aux données situées dans ces zones mémoire. En d'autres termes, le
protocole Modbus ne définit pas ce qui se passera sur le serveur lorsqu'une adresse
mémoire spécifique est écrite avec une valeur déterminée. La façon dont les zones mémoire
sont organisées et où les données sont réellement stockées dépendra du type d'équipement
faisant office de serveur Modbus.
3
Tableau 3.1 Zones mémoire du modèle de données Modbus
Les équipements agissant en tant que serveurs Modbus peuvent même décider de
mapper plusieurs zones mémoire Modbus sur la même mémoire physique interne. Dans ces
cas, les zones mémoire Modbus peuvent se chevaucher et écrire dans un "holding register",
par exemple, peut également changer l'état de l' "input register" correspondant résidant sur
la même mémoire physique.
Notez, cependant, que bien que le modèle de données Modbus spécifie que les
éléments dans chaque zone de mémoire sont adressés en utilisant des valeurs allant de 1 à
65536, malheureusement, ces valeurs d'adresses sont en fait codées sur les trames
échangées sur le support de transmission entre le client et le serveur comme allant de 0 à 65
535. Cela conduit généralement à de nombreuses erreurs, car les manuels de certains
fabricants d'équipements spécifient comment les zones de mémoire Modbus sont mappées
sur l'architecture interne de l'équipement en supposant la plage d'adressage 1–65536, tandis
que d'autres fabricants d'équipements supposent la plage d'adressage 0–65535. Lors de la
lecture d'un manuel, on ne peut jamais être sûr de la plage d'adressage utilisée, sauf si cela
est explicitement indiqué, ce qui est rare. Cependant, si le manuel fait référence à une valeur
d'adresse de "0", alors on peut généralement supposer que la plage d'adressage 0–65535
est considérée.
La couche inférieure définit la façon dont les messages de la couche supérieure sont
encapsulés et codés sur des trames à envoyer sur le support de transmission par la couche
physique sous-jacente, et comment les équipements serveurs sont adressés. Il existe trois
versions distinctes de cette couche inférieure. La version ASCII (American Standard Code
for Information Interchange) code le message de la couche supérieure en caractères ASCII,
tandis que les versions RTU et TCP utilisent une représentation directe en octets. Les
versions RTU et ASCII devraient être envoyées via EIA/TIA-232 ou EIA/TIA-485
(communément appelés RS232 et RS485). La version TCP, comme son nom l'indique, est
envoyée via des connexions TCP établies via le protocole IP. Bien qu'il soit courant que les
trames de protocole IP soient ensuite envoyées sur un LAN Ethernet (réseau local), il n'y a
aucune raison qu'elles ne peuvent utiliser un autre réseau sous-jacent, y compris l'Internet
mondial. Comme les versions RTU et ASCII sont très similaires, elles sont toutes deux
décrites dans la même section 5. La version TCP ne sera pas abordée dans ce cours.
4
Figure 3.2 Organisation du protocole Modbus
Modbus peut être utilisé dans plusieurs architectures réseaux (Figure 3.3).
5
4 - Couche application Modbus
Le protocole Modbus définit trois APDUs distinctes (figure 3.4) utilisées dans la couche
application Modbus. Les trois APDUs commencent par un "code fonction" de un octet
indiquant la fonction Modbus demandée ou à laquelle une réponse est envoyée. Après le
"code fonction" viennent toutes les données et les paramètres de cette fonction spécifique.
Les données et les paramètres ont un nombre d'octets variable, selon la fonction en
question, et le nombre de registres de mémoire auxquels on accède.
Cependant, tous les APDU sont limités en taille à un maximum de 253 octets, en
raison des limitations imposées par la couche EIA/TIA-485 sous-jacente. Le protocole
Modbus spécifie également que toutes les adresses et données 16 bits sont codés à l'aide
d'une représentation big-endian. Cela signifie que lorsqu'une quantité numérique supérieure
à un seul octet est transmise, l'octet le plus significatif est envoyé en premier. Néanmoins,
certains fabricants d'équipements permettent à l'utilisateur de spécifier si l'équipement doit
utiliser un codage big ou litte-endian.
L'APDU de la requête est envoyée par le client au serveur. Une fois la fonction
souhaitée terminée, le serveur répond avec une réponse APDU. Si le serveur rencontre une
erreur, le serveur notifie le client avec une réponse d'exception APDU.
Toutes les fonctions répertoriées dans le Tableau 3.2, à l'exception des fonctions
0x14, 0x15, 0x16 et 0x18, demandent simplement que certaines données soient lues ou
écrites dans une zone mémoire spécifique. Les codes fonction 0x05 et 0x06 sont utilisés
pour écrire sur un seul élément (coil ou holding register, respectivement). Les fonctions
restantes permettent au client de lire ou d'écrire plusieurs éléments consécutifs de la même
zone de mémoire.
6
Zone mémoire Nom fonction Code fonction (Hex) Elements adressables Codes d'erreur
Discrete inputs Read disrete input 0x02 1-2000 01, 02, 03, 04
Coils Read coils 0x01 1-2000 01, 02, 03, 04
Coils Write single coil 0x05 1 01, 02, 03, 04
Coils Write multiple coils 0x0F 1-1976 01, 02, 03, 04
Input registers Read input registers 0x04 1-125 01, 02, 03, 04
Holding registers Read holding registers 0x03 1-125 01, 02, 03, 04
Holding registers Write single register 0x06 1 01, 02, 03, 04
Holding registers Write multiple registers 0x10 1-123 01, 02, 03, 04
Holding registers Read/write multiple 0x17 1-121 (write) 01, 02, 03, 04
registers 1-125 (read)
Holding registers Mask write register 0x16 1 01, 02, 03, 04
Holding registers Read FIFO queue 0x18 1-32 01, 02, 03, 04
Files Read file record 0x14 01, 02, 03, 04, 08
Files Write file record 0x15 01, 02, 03, 04, 08
Tableau 3.2 Fonctions utilisées pour l'accès aux données
Requête Réponse
7
Notez que le nombre maximal d'éléments adressables est limité par la taille maximale
de l'APDU. Par exemple, pour le code de fonction 0x0F, l'APDU de demande commence par
6 octets contenant le code fonction et les paramètres respectifs (voir la figure 3.5), laissant
un maximum de 247 (égal à 253 - 6) octets disponibles dans lesquels envoyer les données.
Les données, composées d'éléments à 1 bit, sont regroupées à 8 par octet, ce qui donne un
maximum de 1976 (247 × 8) éléments adressables.
La fonction 0x16 (Mask Write Register) modifie la valeur stockée dans un seul
"holding register". Cependant, contrairement aux autres fonctions, la nouvelle valeur n'est
pas obtenue directement à partir des données envoyées dans l'APDU, mais est plutôt
obtenue en appliquant une opération logique en utilisant la valeur actuelle du "holding
register" avec deux masques, un masque AND et un masque OR, envoyés avec l'APDU.
𝑁𝑜𝑢𝑣𝑒𝑙𝑙𝑒_𝑣𝑎𝑙𝑒𝑢𝑟 =
𝑣𝑎𝑙𝑒𝑢𝑟_𝑎𝑐𝑡𝑢𝑒𝑙𝑙𝑒 𝐴𝑁𝐷 𝐴𝑛𝑑_𝑚𝑎𝑠𝑘 𝑂𝑅 (𝑂𝑟_𝑚𝑎𝑠𝑘 𝐴𝑁𝐷 𝑁𝑂𝑇 𝐴𝑛𝑑_𝑚𝑎𝑠𝑘 )
En utilisant cette fonction, le client peut désactiver certains bits et positionner d'autres
bits du "holding register" à 1, tout en laissant les bits restants inchangés, en une seule
opération atomique.
La fonction 0x18 (Read FIFI queue) permet au client de demander la lecture d'une file
d'attente FIFO à partir du serveur. La file d'attente FIFO doit être stockée dans la zone de
mémoire des "holding registers" du serveur et se compose d'un premier registre contenant le
nombre d'éléments de la file d'attente (registre de comptage de file d'attente), suivi des
valeurs de chaque élément de la file d'attente dans les registres suivants ( registres de
données de file d'attente). Le client indique simplement dans l'APDU de demande l'adresse
du registre de comptage de file d'attente, et le serveur répondra avec la valeur contenue
dans ce registre de comptage de file d'attente, suivie de la valeur de chaque registre de
données de file d'attente, jusqu'à un maximum de 31 registres de données.
8
équipements se connectant sur une liaison série et de nombreux serveurs Modbus
disponibles dans le commerce ne supportent pas certaines ou toutes ces fonctions.
Avec la fonction 0x07 (Read exception status), le client peut lire le statut d'exception
d'un équipement spécifique codé sur 8 bits. La fonction 0x08 (Diagnostic) est utilisée pour
obtenir des informations de diagnostic du serveur ou pour faire exécuter des routines
d'autodiagnostic par le serveur qui ne devraient pas affecter le fonctionnement normal du
serveur. La fonction est suivie d'un code de sous-fonction indiquant quelles informations de
diagnostic sont demandées (bus message count, communication error count, etc.), ou quelle
routine de diagnostic devrait être exécutée (restart communication, force listen only mode,
etc.).
Avec la fonction 0x0B (Get communication event counter), le client peut obtenir un
statut ainsi qu'un nombre d'événements du compteur d'événements de communication du
serveur. Ce compteur d'événements est incrémenté une fois pour chaque message réussi.
La fonction 0x0C (Get Communication Event Log) renvoie les mêmes données que la
fonction 0x0B, plus le nombre de messages (nombre de messages traités depuis le dernier
redémarrage) et un champ de 64 octets d'événement. Ces octets d'événement contiennent
le statut des résultats des 64 derniers messages qui ont été envoyés ou reçus par le serveur.
Avec la fonction 0x11 (Report Slave ID), un client peut obtenir le statut de marche de
l'équipement serveur (marche/arrêt), un octet d'identification spécifique à l'équipement et
quelques 249 octets de données supplémentaires spécifiques à l'équipement.
La classe 1 définit un ensemble plus complet des fonctions les plus couramment utilisées :
9
Read discrete inputs (0x02)
Read input registers (0x04)
Write single coil (0x05)
Write single register (0x06)
Read exception status (0x07)
5 - Modbus série
Un réseau série Modbus comprend plusieurs équipements connectés à un support physique
(par exemple, un bus série). En raison de la nature partagée du support physique, un
mécanisme est nécessaire pour réguler l'accès au support. Pour cette raison, Modbus série
suit le modèle de communication maître/esclave (figure 3.5), le client Modbus devenant le
10
maître et les serveurs Modbus jouant le rôle d'esclaves. Le maître est chargé d'initier la
communication en envoyant des requêtes aux esclaves, une requête à la fois. Ceux-ci, à leur
tour, répondent au maître avec les données demandées. L'échange requête/réponse peut
être effectué de deux manières :
Mode unicast : le maître envoie une requête à un esclave spécifique. L'esclave traite
cette requête et répond au maître.
Mode broadcast : le maître envoie une requête à tous les esclaves. Les esclaves
traitent cette demande, mais ne répondent pas au maître.
Chaque réseau série Modbus ne peut avoir qu'un seul maître. Le nombre d'esclaves
est limité à 247. Un équipement peut être maître ou esclave, mais pas en même temps. Par
conséquent, un équipement peut changer de rôle chaque fois que cela est approprié. Dans
la pratique, les rôles sont généralement statiques car le protocole Modbus lui-même ne
spécifie pas comment le changement de rôle peut être géré.
5.a) Trames
Le dialogue requête/réponse est effectué à l'aide de requête et de réponse, qui sont
transmises dans des trames qui ont toujours la même structure (figure 3.6) :
Requête
11
Figure 3.6 Trame série Modbus
Dans les communications de type Modbus série, les trames échangées entre le
maître et les esclaves peuvent être transmises dans l'un des deux modes : RTU ou ASCII.
Chaque mode définit différentes façons de coder le contenu de la trame (c'est-à-dire, octets)
pour la transmission. Ce qui distingue le plus les deux modes, ce sont les trames plus petites
produites par le mode RTU. Par conséquent, pour le même débit en bauds, le mode RTU
produit un débit plus élevé. Il existe cependant des circonstances qui peuvent conduire à
choisir le mode ASCII. Celles-ci seront discutées ci-dessous.
Tous les équipements doivent implémenter le mode RTU, le mode ASCII étant
facultatif. Un équipement peut prendre en charge les deux modes, mais jamais
simultanément. Au sein d'un réseau, tous les équipements doivent utiliser le même mode de
transmission; la communication ne peut pas se produire autrement car les deux modes sont
incompatibles.
12
être interprétées comme une seule trame. Dans les deux cas, les données reçues seront mal
interprétées, ce qui entraînera des erreurs de communication. Pour éviter ce problème, la
transmission d'une trame doit répondre aux exigences temporelles suivantes (figure 3.8) :
Chaque trame doit être transmise, un caractère après l'autre avec un intervalle
d'inactivité minimal de 1,5 fois le temps de transmission d'un caractère.2 Si cet
intervalle est dépassé, le récepteur considère que la trame est incomplète et doit la
rejeter.
Les trames consécutives doivent être séparées par un intervalle de repos d'au moins
3,5 fois le temps de transmission d'un caractère.
Le processus de codage est le suivant : chaque octet de 8 bits est divisé en deux quartets
de 4 bits chacun. Un quartet contient les 4 bits les plus significatifs de l'octet, et l'autre les 4
bits les moins significatifs. Chaque quartet est ensuite codé en utilisant sa représentation
hexadécimale sur l'alphabet ASCII. Par exemple, un octet de valeur 0xA1 (ou 161 en
décimal) est transmis sous la forme des caractères "A" suivi de "1". Le caractère "A" est
2
Temps nécessaire à la transmission de 1,5 × 11 bits.
13
envoyé comme octet de valeur 0x41 qui est la représentation ASCII du caractère "A". De
même, le caractère "1" est transmis en tant que sa valeur ASCII de 0x31.
Les exigences de contrôle de parité sont les mêmes que celles du mode RTU.
D'après la discussion, il est facile de comprendre que le mode ASCII est plus simple
à implémenter et ne pose aucune exigence temporelle particulière. Cependant, le prix à
payer est le doublement de la taille de la trame par rapport au mode RTU.
3
Chaque caractère ASCII est codé sur 7 bits.
14
5.d) Détection d'erreur
Les mécanismes de détection des erreurs sont situés à deux niveaux, à savoir le niveau des
caractères et le niveau des trames.
Tous les équipements doivent prendre en charge l'interface RS485, tandis que le
RS232 est en option. Les deux modes de transmission (RTU et ASCII) peuvent être utilisés
sur l'un ou l'autre type d'interface. De plus, tous les équipements d'un réseau doivent avoir la
même configuration, y compris les paramètres suivants : mode de transmission (RTU ou
ASCII), type de parité (pair, impair ou pas de parité) et débit en bauds (bits/s). Tous les
équipements doivent prendre en charge des débits de 9,6 et 19,2 kbps, ce dernier étant la
valeur par défaut.
15