Rapport du projet des réseaux

locaux industriels

Traitant comme sujet :

Le protocole DeviceNet

Encadré par :
Réalisé par :
 Pr. Guerbaoui
 BELAMAMMAR Maroua
 LAOUIDI Maryam

Année universitaire :

2023/2024
1
2
Table des matières :
Liste des figures : ..............................................................................................................................4
Liste des tableaux : ...........................................................................................................................5
Introduction générale : .....................................................................................................................6
Chapitre I : Les réseaux locaux industriels :....................................................................................7
Introduction : ................................................................................................................................7
a. Architecture OSI et RLI ....................................................................................................8
A. Aspects physiques ................................................................................................................ 10
a. La topologie : ................................................................................................................... 10
b. Le support physique : ...................................................................................................... 11
Chapitre II : Protocole DeviceNet : ................................................................................................ 12
A. Définition du protocole : ..................................................................................................... 12
B. Caractéristiques spécifiques au réseau DeviceNet : ........................................................... 15
 Les avantages et les inconvénients : ................................................................................ 16
 Domaine d’application : .................................................................................................. 17
 Echange de données :....................................................................................................... 17
 Les différents paramètres utilisés par le protocole : ....................................................... 18
C. Description des trames échangées :..................................................................................... 18
 Les messages explicites : .................................................................................................. 19
 Les réponses explicites :................................................................................................... 21
 Réponse d’erreur Explicite : ........................................................................................... 22
 Messages E/S :.................................................................................................................. 24
 La relation entre DeviceNet et CAN : ............................................................................. 25
 Control Area Network (CAN) : ....................................................................................... 25
D. Application sur le protocole DeviceNet : ............................................................................ 32
Conclusion générale : .................................................................................................................. 34

3
Liste des figures :
Figure 1 : Communication industrielle .................................................................................................7
Figure 2 : Architecture globale d'un RLI ...............................................................................................8
Figure 3 : Couches du modèle OSI .......................................................................................................9
Figure 4 : Modèle OSI réduit ............................................................................................................. 10
Figure 5 : Adressage DeviceNet ......................................................................................................... 13
Figure 6 : Couches OSI du protocole DeviceNet ................................................................................. 15
Figure 7 : Topologie unique DeviceNet .............................................................................................. 15
Figure 8 : Mappage PLC E/S ............................................................................................................... 18
Figure 9 : Requête explicite ............................................................................................................... 19
Figure 10 : Connexions d'E/S DeviceNet ............................................................................................ 24
Figure 11 : CAN avec la norme ISO 11898 .......................................................................................... 26
Figure 12 : Couche physique du réseau CAN...................................................................................... 26
Figure 13 : Arbitrage par compétition ............................................................................................... 28
Figure 14 : Trames CAN ..................................................................................................................... 29
Figure 15 : Codage NRZ ..................................................................................................................... 30
Figure 16 : Trame de données CAN et le bit stuffing .......................................................................... 30
Figure 17 : Compteur d'erreur et état d'un nœud .............................................................................. 31
Figure 18 : Application du protocole DeviceNet................................................................................. 32

4
Liste des tableaux :
Tableau 1 : Principales spécifications DeviceNet ............................................................................... 12
Tableau 2 : Caractéristiques de l'implémentation d'un nœud esclave DeviceNet ............................... 14
Tableau 3 : Caractéristiques de l'implémentation d'un nœud maitre DeviceNet ................................ 14
Tableau 4 : Les performances d'une implémentation DeviceNet ....................................................... 16
Tableau 5 : Identification DeviceNet.................................................................................................. 16
Tableau 6 : Les combinaisons des identifiants CAN............................................................................ 19
Tableau 7 : Le débit en fonction de la longueur ................................................................................. 27

5
Introduction générale :

Les Réseaux Locaux Industriels (RLI) sont des systèmes de communication spécialement
conçus pour répondre aux besoins de l'automatisation industrielle. Ils facilitent l'échange
d'informations entre les équipements et les systèmes de contrôle dans un environnement
industriel. L'un des protocoles couramment utilisés dans les RLI est DeviceNet.

DeviceNet est un protocole de communication développé par Rockwell Automation, visant à

simplifier la connexion et le contrôle des dispositifs industriels. Il repose sur la technologie
CAN (Controller Area Network) et offre une solution efficace pour interconnecter divers
équipements tels que capteurs, actionneurs et contrôleurs. Ce protocole favorise une
communication rapide et fiable, améliorant ainsi l'efficacité des processus industriels.

Dans le cadre de votre projet, explorer en détail le protocole DeviceNet serait essentiel. Cela
implique de comprendre son fonctionnement, ses spécifications techniques, et comment il peut
être mis en œuvre pour répondre aux besoins spécifiques de votre application industrielle.

DeviceNet est un protocole de communication industriel largement utilisé dans le domaine de

l'automatisation et du contrôle. Développé par l'Open DeviceNet Vendor Association (ODVA),
il offre une plateforme standardisée pour connecter et échanger des données entre différents
équipements et périphériques au sein d'un réseau industriel. En facilitant la communication
entre des dispositifs variés tels que capteurs, actionneurs et automates programmables,
DeviceNet améliore l'efficacité des systèmes de contrôle tout en offrant une flexibilité accrue
dans la conception des solutions d'automatisation. Cette introduction vise à souligner
l'importance de DeviceNet dans le panorama industriel moderne et à mettre en avant ses
avantages en termes d'intégration, de performance et de fiabilité.

6
Chapitre I : Les réseaux locaux industriels :
Introduction :

L'histoire des réseaux locaux industriels remonte à la fin des années 70, avec l'apparition
des équipements industriels numériques intelligents et des réseaux informatiques de bureaux.
Leur apparition est venue répondre,
Premièrement, à la demande croissante de productivité dans le domaine industriel par
l'automatisation de la communication entre les différents équipements industriels (de contrôle
et de mesure) de façon à éliminer les pertes de temps et les risques d'erreurs dus aux
interventions humaines.
Deuxièmement, au besoin d'interconnexion des équipements industriels informatisés
hétérogènes qui ont été introduits dans le milieu industriel d'une manière anarchique, c'est-à-
dire en résolvant chaque problème à part sans prendre en compte l'intégrité de tout le système
industriel.
Les réseaux locaux industriels ont été donc introduits petit à petit dans les systèmes
automatisés, à des stades divers selon les domaines d'application. Ils sont nés avec le
développement de l'électronique et des matériels numériques programmables. L'apparition des
régulateurs numériques et des automates programmables a conduit les offreurs à mettre sur le
marché des réseaux pour les interconnecter et rapatrier à moindre coût de câblage les
informations nécessaires à la conduite par les opérateurs dans les salles de commande.

Figure 1 : Communication industrielle

I. Architecture d’un réseau industriel :

Un réseau local industriel, en une première approximation, est un réseau local utilisé dans
une usine ou tout système de production pour connecter diverses machines afin d'assurer la

7
commande, la surveillance, la supervision, la conduite, la maintenance, le suivi de produit, la
gestion, en un mot, l'exploitation de l'installation de production.

Figure 2 : Architecture globale d'un RLI

Néanmoins, à chaque niveau d'abstraction, dans un environnement industriel, correspond

un réseau permettant de relier ses différents éléments. Entre deux niveaux différents il doit y
avoir une passerelle si les deux réseaux sont hétérogènes.
On distingue donc trois types de réseaux :
Les réseaux de terrain connectent les capteurs, les actionneurs et les dispositifs comme les
automates, les régulateurs et plus généralement tout matériel supportant des processus
d'application ayant besoin d'avoir accès aux équipements de terrain. Ils doivent offrir au
minimum les mêmes services que les systèmes d'entrées/sorties industrielles, mais d'autres très
importants (de synchronisation par exemple) seront aussi définis pour faciliter la distribution
des applications.
Les réseaux d'atelier (ou de cellule) connectent, dans une cellule ou un atelier, les dispositifs
de commande de robots, de machines-outils, de contrôle de la qualité (lasers, machines à
mesurer). Ces réseaux se rencontrent essentiellement dans les industries manufacturières.

a. Architecture OSI et RLI

Le modèle OSI constitue un cadre de référence pour l'interconnexion de systèmes ouverts
hétérogènes. Il s'agit d'un modèle pour élaborer des normes d'interconnexion et de coopération

8
de systèmes répartis. Il est construit selon une structure en sept couches qui correspondent
chacune à un type de préoccupation ou à un type de problème à résoudre pour pouvoir
communiquer. L'idée de base de la structure en couches est, comme dans d'autres domaines, de
pouvoir à chaque interface ignorer le plus possible ce qui se passe en dessous.
Le modèle est applicable à toutes les catégories de réseaux. Nous rappelons brièvement le
rôle de chaque couche. Tous les détails peuvent être trouvés dans de nombreux ouvrages. Les
sept couches initiales du modèle sont rappelées par la figure 1. Les couches 1,2, 3 et 4 se
préoccupent du transport d'informations et masquent aux couches supérieures les problèmes
liés à la communication d'informations entre des équipements distants. Les couches 5, 6 et 7
fournissent des services d'accès à la communication pour différents types d'applications.

Figure 3 : Couches du modèle OSI

 La couche physique adapte les signaux numériques au support de transmission.

 La couche liaison de données fiabilise les échanges de données entre deux stations.
 La couche réseau assure la recherche d'un chemin et l'acheminement des données entre
les stations terminales dans un réseau maillé.
 La couche transport assure le contrôle de bout en bout entre les stations terminales.
 La couche session synchronise et gère les échanges pour le compte de la couche
présentation.
 La couche présentation permet d'accepter des syntaxes différentes pour les données
échangées entre les couches application.
 La couche application donne aux processus d'application le moyen d'accéder à
l'environnement OSI. Elle n'a pas de limite supérieure, c'est-à-dire que l'on peut toujours
ajouter des services supplémentaires construits sur des services existant déjà.

9
 Figure 4 : Modèle OSI réduit

Dans La couche application sont implémentés les applications sur les machines, les stations
opérateur de contrôle, et les interfaces nécessaires à la communication avec des machines
intelligentes et les ordinateurs dans l'usine.
La couche liaison permet de corriger les erreurs de transmission et de fiabiliser la
communication à travers les acquittements, trois protocoles sont proposés :
LLCI : sans connexion et sans acquittement par exemple pour les cas des messages courts
périodiques.
LLC2 : avec connexion lourd pour les communications industrielles.
LLC3 : sans connexion et avec acquittement, convient par exemple pour les
communications temps réel avec un degré de fiabilité important tel que le test de
fonctionnement d'un appareil.

A. Aspects physiques
Les propriétés importantes de la couche physique sont :
- La topologie.
- Le support physique.
a. La topologie :
Les topologies connues dans les réseaux sont :
Bus :
La topologie Réseau en bus est représentée par un câblage unique des unités
réseaux. Il a également un faible coût de déploiement et la défaillance d'un
nœud (ordinateur) ne scinde pas le réseau en deux sous-réseaux. Ces unités
sont reliées de façon passive par dérivation électrique ou optique.

10
Anneau :
Un réseau a une topologie en anneau quand toutes ses stations sont
connectées en chaine les unes aux autres par une liaison bipoint de la
dernière à la première. Chaque station joue le rôle de station
intermédiaire. Chaque station qui reçoit une trame, l'interprète et la
réémet à la station suivante de la boucle si c'est nécessaire. La
défaillance d'un hôte rompt la structure d'un réseau en anneau si la
communication est unidirectionnelle ; en pratique un réseau en anneau
est souvent composé de 2 anneaux contrarotatifs.

Etoile :
La topologie Réseau en étoile aussi appelée Hub and spoke est la
topologie la plus courante actuellement. Omniprésente, elle est aussi très
souple en matière de gestion et de dépannage d'un réseau : la panne d'un
nœud ne perturbe pas le fonctionnement global du réseau.

b. Le support physique :

La paire torsadée : C’est la solution la plus simple à mettre en

œuvre, et la moins chère. Elle est utilisée avec les standards
suivants :
– RS-232 : C’est une liaison point à point par connecteur SUB- D 25
broches. Elle permet des distances ne dépassant pas 15 mètres pour un débit
maximum de 20 Kbps.
– RS-422A : C’est un bus multipoint full duplex (bidirectionnel simultané) sur 4 fils
présente une bonne immunité aux parasites et peut atteindre une distance de 1200 m à 100 Kbps.
Elle utilise un mode différentiel avec 2 fils en émission et 2 fils en réception.
– RS-485 : c’est un bus multipoint half duplex sur 2 fils, qui a les mêmes caractéristiques
que RS422A mais sur 2 fils.
Le câble Coaxial : Il se compose d’un conducteur en cuivre,
entouré d’un écran mis à la terre et entre les deux une couche
isolante de matériau plastique. Il a des excellentes propriétés
électriques et se prête aux transmissions à grande vitesse.

Fibre Optique : Câble en cuivre qui transmet des signaux

lumineux. Il convient pour les environnements industriels
agressifs, la transmission sûre et les longues distances.

11
Chapitre II : Protocole DeviceNet :
A. Définition du protocole :
Crée en 1994 par Rockwell Automation (Allen Bradley), DeviceNet couvre les bus de terrain
et les bus de capteurs/actionneurs. Il est capable de gérer simultanément des E/S distribuées et
des équipements intelligents (variateurs de vitesse...), aux PLC. Les applications se situent
principalement dans les secteurs de l'automobile, la métallurgie, l'agro-alimentaire. DeviceNet
permet d'interconnecter jusqu'à 64 stations et propose 3 vitesses de transmission avec une
longueur de bus comprise entre 100 et 500m. Le support est un câble 4 fils (2 pour la
communication, 2 pour l'alimentation 24V, 8A).
DeviceNet fait appel à la technologie CAN pour la transmission des données. Sur DeviceNet,
les débits de transmission disponibles sont de 125, 250 ou 500 K bauds. Le protocole divise
l’identifiant CAN en 4 groupes de messages et leur alloue des tâches basées sur le principe
client-serveur. La procédure est orientée connexion. Cela signifie qu’avant de pouvoir échanger
quelque information que ce soit, il faut impérativement qu’une connexion soit établie entre 2
nœuds. Chaque équipement DeviceNet possède donc pour cela soit un Unconnected Message
Manager (UCMM pour connexions multiples ou connexions sans port de communication), soit
un port non-connexe. Ces deux types réservent des fonctions au moyen de certains identifiants
CAN selon l’adresse équipement. Cet identifiant permet d’ouvrir le dénommé « canal explicite
» qui permet exclusivement un échange entre les nœuds ayant la même priorité. Des
informations sont ensuite échangées via ce canal sur la connexion d’E/S à établir.
Tableau 1 : Principales spécifications DeviceNet

La couche application utilise les échanges type Producteur/Consommateur. En 1995 ce groupe

transfert la technologie à l’association ODVA (Open DeviceNet Vendor Association). Cette
dernière est chargée de garantir les spécifications, promouvoir, rependre et approuver les
configurations du réseau. C’est un système ouvert et sans licence. Voici comment est présenté
le descriptif du protocole en deux volumes.

Volume 1 : Le protocole de communication et la couche applicative.

CAN : La couche de liaison de données.
La couche physique.
Volume 2 : Description de profils des équipements.

12
DeviceNet connecte tout type d’équipements : Les plus simples tels que des capteurs et des
actionneurs ainsi que les plus complexes tels que des PLC. L’adresse de données (I/O data
format) comporte quatre parties : Mode Address (MAC ID), Class, Instance et Attribute. Cela
nous indique la nature de la commande.
Mode Address [0…63]
Class ID [1…255]
Instance ID [0…255]
Attribute ID [1…255]

Les variables dans un nœud communiquent en utilisant une clé (Path). Elle est composée par
une classe ID, une instance ID et un attribute ID. La figure 16 représente l’adressage DeviceNet.
L’attribut 1 peut représenter par exemple la position du clapet d’une vanne 683. Un réseau
DeviceNet avec ses équipements actifs est représenté : l’équipement est identifié avec le MAC
ID #4 (vanne MKS 683 par exemple).

Figure 5 : Adressage DeviceNet

MAC ID représente chaque nœud dans le réseau.

Class ID représente chaque classe d’objet.
Instance ID représente une instance (objet) spécifique de la classe.
Attribute ID représente un attribut de la classe ou l’objet.

DeviceNet est capable de gérer simultanément des communications clientserveur (master-

slave) et producteur/consommateur (peer to peer). Tous les équipements esclaves se trouvent
sur un seul bus. Ce qui élimine considérablement la quantité de câbles utilisés par rapport à une
connectique standard.
Voici dans les tableaux 2 et 3 les caractéristiques succinctes de l’implémentation des nœuds
esclave et maitre qui servent à une mise en place rapide du protocole.

13
 Tableau 2 : Caractéristiques de l'implémentation d'un nœud esclave DeviceNet

Tableau 3 : Caractéristiques de l'implémentation d'un nœud maitre DeviceNet

En tenant compte du modèle OSI, on constate que le protocole DeviceNet ne couvre qu’une
partie de la couche physique et la totalité de la couche applicative. Les spécifications du
protocole CAN seront développées, car c’est la base du DeviceNet.
La couche 1 est principalement spécifique à DeviceNet (avec sa connectique et l’alimentation
du bus 24VDC). La partie de la couche 1 proche de la couche 2 et la totalité de la couche
suivante appartient au protocole CAN avec ses principales spécificités tel que sa détection
d’erreurs et son moyen d’accès par priorité qui constitue la force. Ces deux fonctions
garantissent une fiabilité de transfert de données en temps réel et le déterminisme de DeviceNet.
La couche 7 est exclusivement applicative, elle est constituée de la sémantique CIP commune
à plusieurs protocoles.

14
 Figure 6 : Couches OSI du protocole DeviceNet

B. Caractéristiques spécifiques au réseau DeviceNet :

Ce protocole n’utilise qu’une seule topologie avec des spécifications limitant la longueur du
bus et des dérivations par rapport aux nombres des sous-ensembles pris en charge et la fiabilité
du transfert des données. Le câblage du réseau doit respecter la spécification de l’ODVA :
Topologie d’un réseau DeviceNet : le Trunkline est le bus proprement dit, c’est par ce canal
commun que tous les messages transitent. Le Dropline est le lien entre l’équipement et le bus.
Les RT 121 Ohms se sont les résistances de terminaison qui assurent l’adaptation en impédance
optimale de la ligne de transmission (cf. l’annexe E). Si elles ne sont pas présentes ou si
l’impédance est différente il aura désadaptation de la ligne ce qui entraine une perte des
données. Les spécifications des types de câble à utiliser et de la longueur à respecter
apparaissent sur le CD : The DeviceNet Spécifications. L’alimentation (Power Supplie) 24VDC
est présente dans tout le réseau.

Figure 7 : Topologie unique DeviceNet

La vitesse de transfert de données varie en fonction de la longueur des câbles et de leur

positionnement sur le réseau.

Voici un exemple montrant les performances d’une implémentation DeviceNet (1 Maud, mode
polling) :

15
 Tableau 4 : Les performances d'une implémentation DeviceNet

Ce bus de terrain possède une Connection ID (identifiant du protocole CAN), qui permet de
hiérarchiser les priorités des messages. L’état des entrées et des sorties ont toujours la plus forte
priorité. Ceci est réalisé grâce à un mécanisme électrique par lequel les états dominants écrasent
les états récessifs. L’identifiant ayant la valeur binaire la plus petite aura la priorité la plus
élevée. C’est la spécificité de ces bus. Voici la classification par des groupes de priorités :
Tableau 5. Dans les Identity Usage on constate que les Messages Group 2 sont les plus utilisés.
Tableau 5 : Identification DeviceNet

 Les avantages et les inconvénients :

Avantages de DeviceNet :
 Simplicité d'Installation : DeviceNet utilise un câblage simple, ce qui facilite son
installation et réduit les coûts associés.
 Gestion des Périphériques : Il permet de gérer efficacement un grand nombre de
périphériques sur un seul réseau, simplifiant ainsi la configuration et la maintenance.
 Communication Rapide : Le protocole CAN sous-jacent offre une communication rapide
et fiable entre les différents équipements industriels.
 Standard Ouvert : DeviceNet est un standard ouvert, favorisant l'interopérabilité entre
les équipements de différents fabricants.

Inconvénients de DeviceNet :
 Bande Passante Limitée : Le débit de données de DeviceNet peut être limité par rapport
à d'autres protocoles plus récents, ce qui peut être un inconvénient dans les applications
nécessitant une transmission de données très rapide.

16
  Longueur de Câble Limitée : La longueur totale du câble dans un réseau DeviceNet est
limitée, ce qui peut restreindre la portée des installations.
 Débit Fixe : DeviceNet a un débit de données fixe, ce qui signifie qu'il peut ne pas être
la meilleure option pour des applications nécessitant une variabilité dans la vitesse de
transmission.
 Technologie Plus Ancienne : Avec l'évolution des technologies, DeviceNet peut
sembler quelque peu obsolète par rapport à des solutions plus récentes offrant des
fonctionnalités avancées.
 Le choix de DeviceNet dépend souvent des besoins spécifiques d'une application
industrielle et des compromis acceptables en termes de performances et de coûts.

 Domaine d’application :
DeviceNet trouve des applications dans divers domaines de l'automatisation industrielle,
notamment :
 Fabrication : Utilisé pour connecter et contrôler une variété d'équipements et de
machines sur une ligne de production.
 Automobile : Intégré dans les systèmes de contrôle des véhicules, il facilite la
communication entre les différents composants électroniques.
 Emballage : Employé pour coordonner les opérations des machines d'emballage et
assurer une intégration efficace dans les lignes de production.
 Traitement : Appliqué dans les installations de traitement, comme les usines chimiques,
pour la surveillance et le contrôle des équipements.
 Logistique : Utilisé dans les systèmes de gestion d'entrepôt pour la coordination des
équipements automatisés tels que les convoyeurs et les robots.
 Énergie : Intégré dans les installations de production d'énergie pour la surveillance et le
contrôle des équipements liés à la génération et à la distribution d'énergie.
 Alimentaire et Boissons : Employé dans les lignes de production pour assurer la
communication entre les différentes étapes du processus de fabrication.

 Echange de données :
Le processus de lecture des entrées et d’écriture des sorties (dans un PLC 32 bits par exemple)
se nomme échange de données (I/O data exchange). Les données E/S de chaque équipement
sont « mappées » sur une zone de mémoire du PLC. Le scrutateur DeviceNet Rockwell
Automation permet la configuration automatique ou manuelle. La table de mappage contient
90 registres de 32 bits. Cette architecture favorise l’augmentation de la vitesse de transfert de
données. Dans la figure 9 le schéma Mappage PLC/IO nous montre un exemple d’emplacement
mémoire configuré dans le PLC. Sur les deux premières lignes du tableau (32 bits chaque case)
sont affectées à l’équipement 1 (Slave 1) et les deux dernières lignes du tableau à l’équipement
4. Ces emplacements dans la table restent inchangés une fois la configuration effectuée. Le
schéma « Câblage conventionnel » nous expose un câblage fil à fil entre un automate et un
équipement où chaque entrée et sortie correspond à une E/S de l’automate. Ce câblage n’utilise
pas de protocole donc il n’a pas tous ses avantages.

17
 Figure 8 : Mappage PLC E/S

 Les différents paramètres utilisés par le protocole :

 Bit-Strobe Command : C’est un message E/S envoyé par le maître. Il fournit un bit de
donnée à chacun des esclaves du réseau avec un intervalle de temps fixe.
 Bit-Strobe Response : Il est transmis au maître après réception du Bit-Strobe Command.
L’esclave a la possibilité d’envoyer au moins 8 octets de données au maître.
 Change-of-State/Cyclic : Il peut être envoyé soit par le maître soit par l’esclave. Il sera
reçu uniquement par le nœud concerné qui retournera par la suite un message ACK.
 Poll Command : C’est un message E/S envoyé par le maître et dirigé vers un seul et unique
nœud. Le message peut contenir jusqu’à 256 octets et il utilise un intervalle de temps
prédéfini.
 Poll Response : C’est le message de retour envoyé par l’esclave après avoir reçu le
message Poll Command par le maître. Le message peut contenir jusqu’à 256 octets.
 Explicit Request : C’est le message envoyé par le maître à un nœud spécifique. Il est utilisé
pour demander des données (lecture ou l’écriture de données) et la réinitialisation de
l’équipement esclave. Ils peuvent être demandés par le maître à tout moment.
 Explicit Response : Le message de retour envoyé par l’esclave après réception du message
Explicit Request. Il est utilisé pour retourner les résultats du message Explicit Request.
Poll Command et Poll Response, ce sont les paramètres les plus utilisés.

C. Description des trames échangées :

Lors d’une connexion, les messages explicites et les E/S Poll sont constitués au moins de deux
segments CAN : Le CAN Identifier Field et le CAN Data Field. Le seul segment propre à
DeviceNet est défini par le Predefined Master/Slave Connection Set. Ce sont des attributs
prédéfinis et ils ne sont pas modifiables. Les tableaux mettent en évidence toutes les
combinaisons possibles des identifiants CAN et des données CAN.

18
 Tableau 6 : Les combinaisons des identifiants CAN

 Les messages explicites :

Le protocole des messages DeviceNet est représenté en base hexadécimal (base 16). Les
messages explicites utilisent différents formats de requête/réponse qui permettent un accès
direct à tout attribut. Les messages suivants illustrent une requête (constructeur de
l’équipement : Vendor ID) et l’interprétation de la réponse du réseau. Voici les messages situés
dans le contexte suivant :
Représentation des messages explicites
Les trames ne sont pas fragmentées
L’adresse du noeud esclave est le 05
L’adresse du noeud maitre est le 01
Les espacements sont représentés uniquement par souci de clarté, ils n’apparaissent pas dans la
trame.

Figure 9 : Requête explicite

CAN Identifier Field : La valeur décimale est 42Chex. Cet identifiant représente : Le message
ID du groupe 2 (bits 10 et 9), l’adresse de destination du noeud (bits 8 à 3) et le message type
ID du message explicit (bit 2 à 0).

19
CAN Data Field :
Message Header : Avec 01hex. Les bits 7 et 6 représentent respectivement la fragmentation (bit
à 0 = non fragmenté) et le XID (Placeholder) avec une valeur fixe de 0. L’adresse du noeud
source (le maitre) ce sont les bits restants.

Message body :
Service code : Le bit 7 est celui de la requête et le reste de bits représentent le Get Attribute
Single du service ID.

Le class code : Identity Object, l’instance ID et l’attribute ID : Vendor Identification,

représentent le paramètre recherché.

20
  Les réponses explicites :
En tenant compte du message de requête voici la réponse sans erreur :

CAN Identifier Field : La valeur décimale est 42Bhex. Cet identifiant représente : Le message
ID du groupe 2 (bits 10 et 9), l’adresse du noeud source (bits 8 à 3) et le message type ID du
message explicit (bits 2 à 0).

CAN Data Field :

Message Header : Avec 01hex. Les bits 7 et 6 représentent respectivement la fragmentation (bit
à 0 = non fragmenté) et le XID (placeholder) avec une valeur fixe de 0. L’adresse de destination
du noeud (le maitre) ce sont les bits restants.

21
Message body :
Service code : Le bit 7 est la réponse et le reste de bits représentent le Get Attribute Single du
Service ID. 8Ehex est la réponse à ce service ID.

Le class code, l’instance ID et l’attribute ID ne constituent pas le message de réponse.

Data : Ce sont les informations de réponse à la requête : Vendor ID (UNIT=16 bits). Le
Vendor ID des équipements MKS est 36.

 Réponse d’erreur Explicite :

C’est la réponse avec une erreur à la requête du même message explicit.

22
CAN Identifier Field : La valeur décimale est 42Bhex. Cet identifiant représente : Le message
ID du groupe 2 (bits 10 et 9), l’adresse du noeud source (bits 8 à 3) et le message type ID du
message explicit (bits 2 à 0).

CAN Data Field :

Message Header : Avec 01hex. Les bits 7 et 6 représentent respectivement la fragmentation (bit
à 0 = non fragmenté) et le XID (Placeholder) avec une valeur fixe de 0. L’adresse de destination
du noeud (le maitre) ce sont les bits restants.

Message body :
Service code : Le bit 7 est la réponse et le reste de bits représentent le signalement d’erreur du
service ID. 14hex est la réponse à ce Service ID.

23
Le class code, l’instance ID et l’attribute ID ne constituent pas le message de réponse.
General error code : C’est la réponse générique à l’erreur (désignée par l’ODVA). L’erreur
08hex correspond à un service inexistant dans le noeud.
Additionnal error code : C’est l’erreur spécifique d’un Object Class de la jauge MKS. Si le
message ne comporte pas d’erreur prédéfinie la valeur FFhex est envoyée par défaut.

 Messages E/S :
Les connexions d'E/S fournissent des voies de communication dédiées et personnalisées entre
une application de production et une ou plusieurs applications de consommation. Un message
d'E/S est composé d'un identifiant de connexion et de données d'E/S associées.

Figure 10 : Connexions d'E/S DeviceNet

Les principaux types des messages d’E/S sont :

• Polled
• Bit de strobe
• Cyclique

24
  La relation entre DeviceNet et CAN :
Devicenet et le protocole CAN (Controller Area Network) sont interconnectés, car DeviceNet
utilise le CAN comme base de communication. Voici comment ils sont liés :
Protocole de Communication : DeviceNet utilise le protocole CAN comme base pour établir la
communication entre les différents périphériques et équipements industriels sur le réseau. Le
CAN offre une communication robuste et fiable, adaptée à l'environnement industriel.
Couche Physique : Le CAN définit la couche physique et la couche liaison de données du
modèle OSI (Open System Interconnection), et DeviceNet utilise ces couches pour transmettre
les données sur le réseau.
Accès Multiple : Le CAN utilise une méthode d'accès multiple appelée CSMA/CA (Carrier
Sense Multiple Access with Collision Avoidance), qui est également utilisée par DeviceNet
pour permettre aux différents nœuds du réseau de partager le canal de communication de
manière efficace.
Bitrate et Arbitrage : DeviceNet spécifie le débit binaire (bitrate) et l'arbitrage des messages en
utilisant les principes fondamentaux du CAN. Cela garantit une synchronisation appropriée et
une communication cohérente entre les dispositifs connectés.
En résumé, DeviceNet s'appuie sur le protocole CAN pour établir une communication fiable
dans les environnements industriels. La combinaison de DeviceNet et du CAN permet une
intégration efficace des équipements sur un réseau industriel, offrant ainsi une solution de
communication standardisée et interopérable.

 Control Area Network (CAN) :

A l’origine, le protocole CAN a été développé par la société Robert BOSCH Gmbh en 1983
pour l’industrie automobile européenne avec pour ambition de remplacer le câblage
relativement coûteux des automobiles par un câble de réseau beaucoup moins onéreux. Le
protocole a été officiellement lancé en 1986 et les premiers contrôleurs CAN, produits par Intel
et Phillips, ont été commercialisés en 1987. Le protocole CAN se distingue par un temps de
réaction extrêmement rapide et une fiabilité de haut niveau, caractéristiques indispensables pour
assurer, par exemple, le déclenchement du système ABS ou des airbags. A partir de ce
protocole, une norme de communication a été développée pour une application en milieu
industriel et notamment dans les automatismes.
Le protocole CAN (Control Area Network) est un protocole de communication série qui
supporte des systèmes temps réel avec un haut niveau de fiabilité. Ses domaines d’application
s’étendent des réseaux moyens débits aux réseaux de multiplexages faibles coûts. Il est avant
tout à classer dans la catégorie des réseaux de terrain utilisé dans l'industrie pour remplacer la
boucle analogique 4-20mA.

25
 Figure 11 : CAN avec la norme ISO 11898

La figure 11 nous montre la couche physique de ce protocole qui est la même sur DeviceNet :
le niveau récessif « 1 » et le niveau dominant « 0 » avec les tensions correspondantes ; CAN H
(high) et CAN L (low) sont les lignes de transmission différentielles où tous les messages
transitent, DeviceNet utile deux fils supplémentaires pour que l’alimentation 24VDC.
Avec le bus CAN, les stations ayant les mêmes droits (organes de commande, capteurs ou
actionneurs) sont reliées par un bus série. Le protocole CAN de base leur permet d'échanger
2048 variables. Ce protocole, ainsi que les paramètres électriques de la ligne de transmission,
sont fixés par la norme 11898. La transmission physique s'effectue avec une paire torsadée, par
liaison infrarouge, par liaison hertzienne ou par fibre optique.

Figure 12 : Couche physique du réseau CAN

La figure 12 représente (par rapport à la figure 18) plus en détail les composants contenus des
nœuds CAN pris en charge par le réseau.

26
A la différence du faisceau de câbles, le réseau détecte et corrige, grâce à son protocole, les
erreurs de transmissions induites par les radiations électromagnétiques. L'organisation en réseau
apporte aussi une configuration aisée du système et la possibilité d'établir un diagnostic central.
Elle permet à chaque station de communiquer avec les autres sans charger le calculateur des
organes de commande.
i. Principe de fonctionnement
Du type multi-maître, orienté messages courts, le bus CAN est bien adapté à la scrutation de
variables émises par des stations déportées. La norme ISO 11898 spécifie un débit maximum
de 1Mbit/s. La longueur maximum du bus est déterminée par la charge capacitive et le débit.
Les configurations recommandées sont les suivantes :
Tableau 7 : Le débit en fonction de la longueur

Le protocole est basé sur le principe de diffusion générale : lors de transmission, aucune station
n'est adressée en particulier, mais le contenu de chaque message est explicité par une
identification reçu de façon univoque par tous les abonnés. Grâce à cet identificateur, les
stations, qui sont en permanence à l'écoute du réseau, reconnaissent et traitent les messages qui
les concernent ; elles ignorent simplement les autres. L'identificateur indique aussi la priorité
du message, qui détermine l'assignation du bus lorsque plusieurs stations émettrices sont en
concurrence. En version de base, c'est un nombre de 11 bits, ce qui permet de définir jusqu'à
2048 messages plus ou moins prioritaires sur le réseau. Chaque message peut contenir jusqu'à
8 octets de données, ce qui correspond par exemple à l'état de 64 capteurs. L'adressage par le
contenu assure une grande flexibilité de configuration. Il est possible d'ajouter des stations
réceptrices à un réseau CAN sans modifier la configuration des autres stations.
ii. Principe de l'arbitrage :
Afin d'être traitées en temps réel, les données doivent être transmises rapidement. Cela suppose
non seulement une voie physique de transmission atteignant jusqu'à 1 Mbit/s, mais encore exige
une assignation rapide du bus dans les cas de conflits, lorsque plusieurs stations souhaitent
transmettre simultanément des messages.
L'urgence des informations échangées sur le bus peuvent être très diverses : une valeur variant
rapidement, comme l'état d'un capteur ou l'asservissement d'un moteur, doit être transmis plus
souvent avec un retard moindre que d'autres valeurs comme la température du moteur, qui
évolue lentement. Sur le réseau CAN, l'identificateur de chaque message, qui est un mot de 11
bits (format standard) ou 29 bits (format étendu), détermine sa priorité. Les priorités sont
attribuées lors de l'analyse conceptuelle du réseau, au moyen de valeur binaire, et ne peuvent
donner lieu à aucune modification dynamique.

27
Le procédé d'attribution du bus est basé sur le principe de l'arbitrage bit à bit, selon lequel les
noeuds en compétition, émettant simultanément sur le bus, comparent bit à bit l'identificateur
de leur message avec celui des messages concurrents. Les stations de priorité moins élevées
perdront la compétition face à celle qui a la priorité la plus élevée.
Les stations sont câblées sur le bus par le principe du « OU câblé », en cas de conflit c'est à dire
émission simultanée, la valeur 0 écrase la valeur 1. On appelle donc l'état dominant l'état logique
0, et l'état récessif l'état logique 1. Lors de l'arbitrage bit à bit, dès qu'une station émettrice se
trouve en état récessif et détecte un état dominant, elle perd la compétition et arrête d'émettre.
Tous les perdants deviennent automatiquement des récepteurs du message, et ne tentent à
nouveau d'émettre que lorsque le bus se libère. Illustration ci-dessous : figure 13.

Figure 13 : Arbitrage par compétition

iii. Formats de trames :

La norme CAN définit deux formats de protocole : Standard (Version2.0 A) et Extended
(Version2.0 B) voir la figure 21. Spécification publiée par Bosch en 1991. La différence
résulte seulement dans la longueur de l'identificateur (ID) qui est de 11 bits de base et 18
bits supplémentaires en mode Extended. Cette extension permet l'augmentation du
nombre de variables échangées, et le nombre de stations sur le réseau. Le nombre d'octets
de données échangées à chaque trame reste inchangé.

28
 Figure 14 : Trames CAN

Une trame est composée des champs suivants :

 1 bit SOF (Start Of Trame)
 11 bits dans la zone d'arbitrage (CAN Identifier ou Message ID)
 1 bit RTR (Remote Transmission Request) : détermine s'il s'agit d'une trame de données
ou d'une trame de requête.
 1 bit IDE qui établit la distinction entre format standard (état dominant) et format étendu
(état récessif)
 1 bit réservé pour une utilisation future
 4 bit DLC (Data Lenght Code) : nombre d'octets contenus dans la zone de données
 Zone de données comprise entre 0 et 8 octets
 15 bits CRC (Cyclic Redundancy check Code) : Ces bit sont recalculés à la réception et
comparés aux bits reçus. S'il y a une différence, un bit d’erreur CRC est déclaré.
 La zone ACK est composée d'un bit ACK Slot à l'état récessif ainsi qu'un bit séparateur
: delimiter bit. Le premier bit doit être forcé à l’état dominant par les stations ayant bien
reçu cette trame.
 7 bits dans la zone EOF (End Of Frame) : Ils permettent d'identifier la fin de la trame.
 3 bits d’intermission : ce sont des bits récessifs qui notifient la libération du bus juste
après l’EOF ;
Les contrôleurs CAN qui admettent le format étendu peuvent aussi émettre et recevoir des
messages au format standard. En revanche, dès que l'on utilise sur le réseau des contrôleurs ne
maitrisant que le format standard, les messages étendus seront mal interprétés.
iv. Codage utilisé :
La succession de bits transitant sur le bus est codé avec la méthode du NRZ (Non Return To
Zero).
Pendant la durée totale du bit, le niveau de tension de la ligne est maintenu, c'est à dire que
pendant toute la durée durant laquelle un bit est généré, sa valeur reste constante qu'elle soit
dominante ou récessive.

29
 Figure 15 : Codage NRZ

v. Détection des erreurs :

La trame du protocole CAN intègre plusieurs mécanismes de détection d’erreur. Afin de
sécuriser la transmission des messages on utilise la méthode dite de Bit-Stuffing (bit de
transparence). Voir l’exemple sur la figure 22. Cette méthode consiste, dès que l’on a émis 5
bits de même polarité sur le bus, à insérer un bit de polarité contraire pour casser des chaînes
trop importantes de bits identiques. On obtient ainsi dans le message un plus grand nombre de
transitions ce qui permet de faciliter la synchronisation en réception par les noeuds. Cette
technique est uniquement active sur les champs de SOF, d’arbitrage, de contrôle, de Cyclic
Redundancy check Code (délimiteur exclu). Pour un fonctionnement correct de tout le réseau,
cette technique doit être implémentée aussi bien à la réception qu’à l’émission.
De plus, comme tous les noeuds de réseau surveillent simultanément le bus, ils détectent des
différences entre les bits reçus et les bits émis. Dès qu'une erreur est détectée, la transmission
en cours est interrompue par l'émission d'un indicateur d'erreur : Error Flag. L'émetteur peut
donc recommencer à émettre son message.
Tout ce système de gestion des erreurs est complètement transparent pour le développeur et
l'utilisateur. Le système est capable de gérer automatiquement ses conflits et ses erreurs en
émettant des trames d'erreurs pour renseigner l'émetteur du message sur le type de faute qu'il a
commis. Une station est capable de faire la distinction entre les perturbations temporaires et les
défauts permanents. Les stations en défaut permanent sont déconnectées automatiquement du
réseau.

Figure 16 : Trame de données CAN et le bit stuffing

30
Ce système de gestion d'erreur fait toute la puissance du réseau CAN, certains constructeurs
démontrent que la probabilité d'erreur résiduelle reste inférieure à 4,6 10-11. Cela veut dire que
le système détecte une erreur pour 1000 ans de fonctionnement.
Recouvrement des erreurs :
Le recouvrement des erreurs est assuré par la retransmission automatique de la trame incriminée
jusqu'à ce que l’émission de cette trame s’effectue sans erreur. La validité du message est
acquise s’il n’y a aucune erreur depuis le SOF (Start Of Frame) jusqu'à la fin de trame.
Si l’émetteur n’arrive pas à émettre sa trame correctement, il essaye de nouveau de l’émettre
jusqu'à ce que son compteur d’erreur passe en mode d’erreur passive.
La gestion des modes d’erreur :
Suivant le nombre d’erreurs qu’un noeud comptabilise, l’état du mode de ce noeud peut différer.
Un compteur mémorise le nombre d’erreurs rencontrées lors de la transmission des trames sur
le bus. Deux compteurs séparés régissent respectivement le nombre d’erreurs en émission et en
réception. Il se nomme :
- Transmit Error Counter pour l’émission
- Receive Error Counter pour la réception
Lorsque le nombre d’erreur devient trop important et que le gestionnaire est déjà en erreur
passive, le noeud se met en Bus Offet et se déconnecte du bus. Il ne reçoit ni émet à ce moment-
là aucune trame circulant sur le bus CAN. L’erreur de confinement fait la différence entre la
perturbation de courte durée et les dysfonctionnements permanents.
Le passage dans les différents modes s’effectue suivant la valeur des compteurs comme le
montre la figure 16.

Figure 17 : Compteur d'erreur et état d'un nœud

31
La structure du protocole du bus CAN possède implicitement les principales propriétés
suivantes :
- hiérarchisation des messages.
- garantie des temps de latence.
- souplesse de configuration.
- réception de multiples sources avec synchronisation temporelle.
- fonctionnement multi maître.
- détections et signalisations d’erreurs.
- retransmission automatique des messages altérés dès que le bus est de nouveau au repos.
- distinction d’erreurs : d’ordre temporaire ou de non-fonctionnalité permanente au niveau d’un
noeud.
- déconnexion automatique des nœuds défectueux.
En étudiant la norme BOSCH, on se rend compte que le protocole CAN ne couvre seulement
que deux des sept couches du modèle d'interconnexion des systèmes ouverts OSI de l'ISO.

D. Application sur le protocole DeviceNet :

Figure 18 : Application du protocole DeviceNet

DeviceNet Safety offre des avantages significatifs en termes de sécurité et d'intégration. Son
contrôleur autonome permet une intégration rapide dans les circuits de sécurité existants, avec
la possibilité d'étendre ces circuits sur d'autres machines. Le contrôleur peut gérer jusqu'à 16
nœuds DeviceNet Safety, offrant une flexibilité pour différentes configurations. La surveillance
et le diagnostic du système sont simplifiés grâce au maître DeviceNet, facilitant la maintenance
préventive. Le contrôleur propose une solution compacte avec 16 entrées de sécurité et 8 sorties

32
statiques, conforme à la norme IEC 61131-2. Son boîtier offre un accès aisé aux borniers, et le
diagnostic avancé facilite le dépannage. Le logiciel de configuration simplifie l'installation en
permettant une sélection facile des composants et l'affectation d'étiquettes. La programmabilité
des circuits de sécurité et l'extensibilité des E/S via le réseau DeviceNet modifient
considérablement la conception des systèmes de sécurité, offrant une flexibilité accrue et une
utilisation plus efficace des ressources existantes.

33
Conclusion générale :

En conclusion approfondie, DeviceNet émerge comme un pilier central dans l'écosystème de

l'automatisation industrielle, offrant une solution normalisée et puissante pour la
communication entre les équipements. La flexibilité de ce protocole, développé par l'ODVA,
se manifeste dans sa capacité à interconnecter une gamme diversifiée de dispositifs, allant des
capteurs aux actionneurs, en passant par les automates programmables.

La contribution significative de DeviceNet réside dans sa capacité à rationaliser les opérations

industrielles, en éliminant les barrières de communication entre les différents composants d'un
réseau. Cela se traduit par une optimisation des processus, une réduction des temps d'arrêt et
une amélioration globale de l'efficacité opérationnelle.

La norme ouverte de DeviceNet favorise également l'interopérabilité, permettant aux

utilisateurs de choisir parmi une multitude de fournisseurs d'équipements compatibles. Cette
caractéristique non seulement accroît la flexibilité dans la conception des systèmes
d'automatisation, mais également assure une évolutivité et une pérennité des investissements.

En regardant vers l'avenir, DeviceNet continuera à évoluer pour répondre aux défis
technologiques émergents, tout en maintenant sa réputation de norme fiable et robuste. En
somme, en tant que catalyseur essentiel de l'efficacité industrielle, DeviceNet demeure un choix
incontournable pour ceux qui cherchent à optimiser leurs processus grâce à une connectivité
fiable et standardisée.

34