Table des matières

Chapitre III Le protocole Modbus ...................................................................................................... 2

1- Introduction ............................................................................................................................. 2
2- Interaction et modèles de données Modbus .......................................................................... 2
3- Architecture du protocole Modbus ......................................................................................... 4
4- Couche application Modbus .................................................................................................... 6
4.a) Fonctions d'accès aux données ........................................................................................... 6
4.b) Fonctions de diagnostic ....................................................................................................... 8
4.c) Classes d'implémentation ................................................................................................... 9
4.d) Gestion des erreurs ........................................................................................................... 10
5- Modbus série ......................................................................................................................... 10
5.a) Trames ............................................................................................................................... 11
5.b) Mode RTU .......................................................................................................................... 12
5.c) Mode ASCII ........................................................................................................................ 13
5.d) Détection d'erreur ............................................................................................................. 15
5.e) Couche physique ............................................................................................................... 15

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.

Bien qu'initialement un protocole propriétaire contrôlé uniquement par Modicon, il est

depuis 2004 contrôlé par une communauté d'utilisateurs et de fournisseurs d'équipements
d'automatisation, connue sous le nom de Modbus-IDA. Cette organisation à but non lucratif
supervise l'évolution du protocole et cherche à stimuler son adoption en continuant à
distribuer ouvertement les spécifications du protocole et en fournissant une infrastructure
pour la certification des équipements.

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.

2 - Interaction et modèles de données Modbus

Le protocole de communication Modbus fournit un moyen par lequel un équipement peut lire
et écrire des données dans des zones de mémoire situées sur un autre équipement distant.
L'exemple typique d'un équipement distant est une RTU (remote terminal unit) fournissant
une interface physique (entrées et sorties) à un processus industriel, avec peu ou pas de
capacité de traitement, tandis que l'équipement prenant l'initiative de lire et d'écrire des
données est généralement un PLC. Ces deux équipements interagissent via le protocole
Modbus à l'aide du modèle d'interaction client-serveur (figure 3.1). Le client (PLC) prend
l'initiative de demander au serveur (RTU) d'écrire et de lire les données présentes dans la
RTU. Le serveur répond simplement à ces requêtes, sans jamais prendre l'initiative de
démarrer un échange de données.
Requête
Client Serveur

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

Un client peut adresser des requêtes à plusieurs serveurs Modbus distincts,

généralement un à la fois. De même, le serveur peut répondre aux demandes provenant de
plusieurs clients. Le fait que le serveur soit ou non capable de traiter des demandes
simultanées provenant de plusieurs clients dépend du serveur, bien que celles-ci soient
généralement traitées l'une après l'autre. L'organisation des zones mémoire sur le serveur
sur lequel le client peut écrire ou lire est définie par le protocole Modbus lui-même. Il existe
quatre zones de mémoire distinctes (Tableau 3.1); deux d'entre elles sont organisées en
registres de 16 bits, tandis que les deux autres sont composés de tableaux de bits simples.
De même, deux des zones de mémoire fournissent des autorisations d'accès en lecture et
en écriture, tandis que les deux autres ne peuvent être qu'êtres lues.

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.

Un exemple serait un variateur de vitesse qui contrôle la vitesse de rotation d'un

moteur électrique. Lorsqu'il agit en tant que serveur Modbus, il peut mapper la zone
mémoire "holding registers" sur la zone où le variateur stocke ses paramètres de
configuration (tension maximale et minimale du moteur, vitesse du moteur, etc.), et la zone
mémoire "input registers" aux registres d'état internes du variateur (vitesse actuelle, tension
de sortie actuelle, etc.).

Un autre exemple serait un terminal graphique HMI (human-machine interface), qui

affiche graphiquement une représentation de la configuration actuelle d'un processus
industriel et permet à un opérateur de modifier les paramètres de fonctionnement à l'aide de
boutons et de cadrans spécifiques. Le terminal HMI, agissant en tant que client Modbus,
obtient les valeurs de données correspondant à la configuration du processus industriel du
PLC, qui agit comme serveur Modbus. CE PLC peut utiliser la zone mémoire "holding
registers" pour stocker l'état actuel d'une variable continue du processus sous contrôle (par
exemple, le volume de liquide dans un réservoir) et la zone mémoire "coils" pour stocker les
drapeaux indiquant les boutons à l'écran sur lesquels l'opérateur appuie en ce moment.

Nom de la zone Plage d'adresses Tailles registres Autorisations

mémoire d'accès
Input registers 1-65536 16 Read
Holding registers 1-65536 16 Read/write
Discrete inputs 1-65536 1 Read
Coils 1-65536 1 Read/write

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.

3 - Architecture du protocole Modbus

Le protocole Modbus est organisé comme un protocole à deux couches (figure 3.2).

La couche supérieure, appelée "Modbus application layer", définit les fonctions ou

services qu'un client Modbus peut demander à un serveur Modbus, et comment ces
requêtes sont codées sur un message ou un APDU (application layer protocol data unit). Elle
définit également comment les serveurs doivent répondre à chaque fonction, et les actions à
entreprendre au nom du client. Cette couche est expliquée plus en détail à la section 4.

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).

Figure 3.3 Exemple de réseau Modbus

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.

4.a) Fonctions d'accès aux données

Le protocole Modbus définit une liste d'un grand nombre de fonctions. Les fonctions les plus
utilisées sont celles destinées à accéder aux zones mémoire (Tableau 3.2).

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.

Code fonction (F) Données requête Requête

Code fonction (F) Données réponse Réponse
Code fonction exception Code exception Réponse exception
Figure 3.4 Format général des trames

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

A - Starting bit/register address

Xh - High byte of 16 bit value X C - Number (count) of referenced bit/register
Xl - Low byte of 16 bit value X B - Number of remaining bytes in frame
XR - Paramètres de lecture D - Data values
XW - Paramètres d'écriture MA - AND mask
MO - OR Mask

Figure 3.5 Format des fonctions d'accès aux données

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.

Pour chaque fonction, le format de l'APDU de la requête envoyée par le client et

l'APDU de la réponse respective du serveur, peuvent être trouvés sur la figure 3.5. Notez
que dans les fonctions accédant aux zones mémoire de format bit (c'est-à-dire les fonctions
0x01, 0x02, 0x05, 0x0F), les bits sont envoyés groupés par octet. Par exemple, une fonction
lisant ou écrivant 20 bits se traduira par l'état des 16 premiers bits groupés en 2 octets, et les
4 bits restants envoyés sur les bits les moins significatifs du troisième octet de données.

Le protocole Modbus comprend deux fonctions supplémentaires pour l'accès aux

données. Ces fonctions (0x14 pour la lecture et 0x15 pour l'écriture) sont désignées dans les
documents de base de la spécification Modbus comme "Read File Record" et "Write File
Record". Un "file" contient 10 000 "records" (adressés de 0 à 9 999), chaque "record" étant
un élément de 16 bits. Chaque "file" est référencé par son numéro, compris entre 0 et 65
535. Notez que la mémoire référencée par ces fichiers est indépendante des zones de
mémoire définies dans le Tableau 3.1.

4.b) Fonctions de diagnostic

Le deuxième grand groupe de fonctions Modbus permet au client d'obtenir des informations
de diagnostic du serveur (Tableau 3.3). Ces fonctions ne sont disponibles que sur les

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 spécification Modbus comprend une fonction supplémentaire, 0x2B, avec deux

sous-fonctions. Une sous-fonction (0x0E) permet au client d'obtenir l'identification du
périphérique (obligatoire: nom du fournisseur, code produit, révision majeure et mineure;
facultatif: URL du fournisseur, nom du produit, nom du modèle, nom de l'application
utilisateur) le tout au format de chaîne ASCII. La deuxième sous-fonction peut être utilisée
pour "tunneler" d'autres protocoles de communication à l'intérieur d'une connexion Modbus.

Nom fonction Code fonction (Hex) Codes d'erreur de réponse possibles

Read exception status 0x07 01, 04
Diagnostic 0x08 01, 03, 04
Get communication event counter 0x0B 01, 04
Get communication event log 0x0C 01, 04
Report slave ID 0x11 01, 04
Tableau 3.3 Codes fonction Modbus de diagnostic

4.c) Classes d'implémentation

Les équipements serveur et client Modbus sont classés en classes, en fonction des
fonctionnalités ci-dessus implémentées.

La classe 0 comprend un ensemble minimal utile de fonctions :

 Read holding registers (0x03)

 Read multiple registers (0x03)

La classe 1 définit un ensemble plus complet des fonctions les plus couramment utilisées :

 Read coils (0x01)

9
  Read discrete inputs (0x02)
 Read input registers (0x04)
 Write single coil (0x05)
 Write single register (0x06)
 Read exception status (0x07)

Les équipements de classe 2 prennent en charge toutes les fonctions de transmission de

données :

 Write multiple coils (0x0F)

 Read file record (0x14)
 Write file record (0x15)
 Mask write register (0x16)
 Read/write multiple registers (0x17)
 Read FIFO queue (0x18)

4.d) Gestion des erreurs

La vérification des erreurs commence dès que le serveur reçoit une requête. Sur réception
d'une requête, il analyse la validité du code fonction, de l'adresse des données et des
valeurs de données (dans cet ordre) et, lors de la première erreur rencontrée, répondra avec
un message d'exception avec les codes d'erreur 1, 2 ou 3, respectivement (Tableau 3.4).
Après avoir réussi ces premiers tests, le serveur lance l'exécution de la fonction demandée.
Si la fonction ne peut être exécutée, un message d’exception est transmis avec un code
d’exception égal à 4, 5, ou 6 suivant le type de problème rencontré. Si la fonction est
entièrement exécutée, le serveur transmet une réponse Modbus positive, c’est à dire que le
même code fonction est renvoyé au client et l’équipement serveur repasse dans l’état attente
réception requête.

Code (Hex) Description Commentaires

0x01 Fonction illégale
0x02 Adresse de données illégale
0x03 Valeur de données illégale
0x04 Station esclave en panne
0x05 Acquittement Peu utilisé. Indique que l'esclave
répondra plus tard à la demande.
0x06 Station esclave occupée
0x08 Erreur de parité mémoire Utilisé uniquement dans les codes
fonction 0x14 et 0x15.
0x0A Chemin d'accès à la passerelle non Utilisé uniquement par les passerelles.
disponible
0x0B La passerelle cible ne répond pas Utilisé uniquement par les passerelles.
Tableau 3.4 Codes d'exception Modbus

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.

Le maître ne démarre un échange requête/réponse qu'une fois l'échange précédent

terminé.

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) :

 Adresse : ce champ contient l'adresse de l'esclave. Dans une trame de requête, il

identifie le périphérique de destination de la requête, tandis que dans une trame de
réponse, il identifie l'expéditeur de la requête. Chaque esclave a une adresse unique
comprise entre 1 et 247. L'adresse 0 est utilisée (par le maître) pour diffuser des
messages. La plage 248–255 est réservée.
 Modbus APDU: Ce champ est le PDU de la couche application (section 4).
 CRC (Cyclic redundancy check) ou LRC (longitudinal redundancy check) : permet de
contrôler la validité de l’ensemble du message. Le contenu dépend du mode de
transmission (RTU ou ASCII) utilisé. Pour plus de détails, voir la section 5.d.

Requête

-----Broadcast mode Réseau Modbus

Unicast mode

Figure 3.5 Échange requête/Réponse

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.

5.b) Mode RTU

Le mode RTU utilise une approche asynchrone pour la transmission de données. Chaque
octet, dans une trame, est transmis à l'aide d'un caractère à 11 bits (figure 3.7) :

 1 bit de start (ST), utilisé pour la synchronisation initiale

 8 bits, les données codées en binaire avec le bit le moins significatif envoyé en
premier
 1 bit de parité (PT), utilisé pour la détection d'erreurs
 1 bit de stop (SP), pour assurer un temps d'inactivité minimum entre les
transmissions de caractères consécutives

Tous les équipements doivent prendre en charge la méthode de contrôle de parité

paire, mais l'utilisateur peut choisir n'importe quelle autre méthode (paire, impaire ou sans
parité) sur les équipements qui les prennent en charge. Cependant, tous les équipements du
même réseau doivent tous être configurés pour utiliser la même méthode. Si la méthode
sans parité est utilisée, le nombre de bits de stop doit être égal à 2. Cela garantit qu'un octet
sera toujours codé sur 11 bits.

L'absence de délimiteurs de trame (en-tête ou fin) peut entraîner des erreurs de

synchronisation lors de la réception de trame, c'est-à-dire que le récepteur peut avoir des
difficultés à identifier le début ou la fin de chaque trame. Pour surmonter cela, il devient
nécessaire que l'intervalle de temps entre les caractères consécutifs (dans la même trame)
ne dépasse pas une certaine valeur; sinon le caractère suivant pourrait être facilement
interprété par le récepteur comme le début d'une nouvelle trame. De la même manière, si
des trames consécutives sont séparées par un très petit intervalle de temps, elles pourraient

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.

Figure 3.7 Transmission de trame RTU

Figure 3.8 Exigences temporelles du mode RTU

À partir de cette description, il est facile de comprendre que certaines précautions

doivent être prises lors de la mise en œuvre d'un driver RTU, en particulier en ce qui
concerne la précision des temporisations utilisées. Bien qu'efficace, le mode RTU nécessite
un contrôle serré du timing.

5.c) Mode ASCII

Le mode ASCII utilise également une transmission asynchrone. Dans ce cas, cependant,
chaque octet est transmis sous forme de deux caractères ASCII (figure 3.9).

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.

Chaque caractère ASCII est transmis sur 10 bits comme suit :

 1 bit de start (ST)

 7 bits de données,3 le caractère ASCII ("0" - "9", "A" - "F") avec le bit le moins
significatif envoyé en premier
 1 bit de parité (PT)
 1 bit de stop (SP)

Les exigences de contrôle de parité sont les mêmes que celles du mode RTU.

Contrairement au mode RTU, une trame transmise en mode ASCII a un en-tête et

une fin. L'en-tête identifie le début d'une trame et est représenté par le caractère ASCII ":"
(0x3A). La fin identifie la fin de la trame et comprend deux caractères ASCII : CR (retour
chariot - 0x0D) et LF (saut de ligne - 0x0A), transmis dans cet ordre.

L'utilisation d'en-têtes de message et de fin de message facilite le processus de

réception, car le récepteur n'a qu'à attendre le caractère ":" pour détecter le début d'une
trame. Inversement, la fin d'une trame est détectée lorsque la séquence "CR" "LF" se
produit. Étant donné que ce mode ne spécifie pas d'intervalle de temps maximum entre les
caractères consécutifs, cela implique que cet intervalle pourrait théoriquement prendre
n'importe quelle valeur. Cependant, cela pourrait conduire à une situation dans laquelle le
récepteur se bloquerait, par exemple, lorsque l'expéditeur se plante pendant une
transmission de trame, après quoi le récepteur attendrait indéfiniment les caractères
restants. Afin d'éviter ces situations, le récepteur doit implémenter un mécanisme de
temporisation. Lorsqu'une temporisation se produit, les données reçues sont rejetées et le
récepteur attend la trame suivante. Cependant, il est possible d'utiliser d'autres valeurs en
fonction de la topologie du réseau.

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.

Figure 3.9 Transmission de trame 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.

Au niveau des caractères, une méthode de contrôle de parité est utilisée.

L'expéditeur calcule la parité de chaque caractère à l'aide de la méthode de parité choisie
(parité paire, impaire ou pas de parité) et définit le bit de parité en conséquence. Le
récepteur, en utilisant la même méthode que l'expéditeur, calcule le bit de parité attendu et le
compare avec le bit de parité reçu. S'ils sont différents, une erreur s'est produite et la trame
entière est rejetée. Il est facile de voir que la capacité de détection d'erreur de cette méthode
est assez limitée. Par exemple, lorsque deux bits d'un caractère sont inversés (en raison
d'une erreur de transmission), l'erreur n'est pas détectée.

La détection des erreurs au niveau de la trame utilise un CRC (cyclic redundancy

check) en mode RTU ou LRC (longitudinal redundancy check) en mode ASCII. Bien que ces
méthodes soient conceptuellement différentes, la méthodologie de leur utilisation est la
même. L'expéditeur calcule la valeur du CRC ou du LRC en utilisant un algorithme prédéfini
qui est appliqué au contenu de la trame : Adresse + champs APDU. Cette valeur est ensuite
ajoutée à la trame. Le récepteur calcule le CRC ou le LRC en utilisant le même algorithme et
compare les résultats calculés avec ceux reçus. S'ils sont différents, cela veut dire que la
trame contient des erreurs et doit donc être rejetée. La valeur du CRC est calculée par une
division polynomiale de la trame en utilisant X16 + X15 + X2 + 1 comme polynôme générateur.
Il produit une valeur sur 16 bits, transmise avec l'octet inférieur en premier. La valeur du LRC
est calculée en utilisant une somme modulo-2 (somme XOR) de tous les octets de la trame
et produit une valeur de 8 bits. Une comparaison entre les deux méthodes montre que le
CRC a une capacité de détection d'erreur plus élevée. Les valeurs CRC et LRC sont
transmises en utilisant la même méthodologie utilisée pour les caractères restants.

5.e) Couche physique

Une communication Modbus série peut s’effectuer via les supports physiques suivants :
RS485 [5] et RS232 [6]. Le RS485 consiste en un réseau multipoint capable de prendre en
charge plusieurs équipements (généralement 32 équipements par segment de réseau).
Plusieurs segments peuvent être connectés en utilisant des répéteurs, augmentant ainsi le
nombre maximum d'équipements dans le réseau. Il prend en charge 1 maître (à la fois) et
jusqu'à 247 esclaves, et il peut être utilisé pour de plus grandes distances (jusqu'à 1000 m)
avec des débits en bauds élevés. Le RS232 est une solution point à point avec seulement 1
maître et 1 esclave. Il est utilisé pour de courtes distances (<20 m) avec des vitesses de
transmission faibles à moyennes.

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