bus can et applications -...

République Algérienne Démocratique Et Populaire

Ministère De l’Enseignement Supérieur Et De La Recherche Scientifique

Université Larbi Ben M’hidi de Oum El Bouaghi

Faculté Des Sciences Et Sciences Appliquées

Filière Génie électrique

Mémoire de fin d’étude en vue de l’obtention du diplôme de

Master en Informatique Industrielle

Thème

Soutenu Publiquement A Oum El Bouaghi

Le : 10/06/2015

Par :

Abbes BOUGUEZMIR

Dirigé Par :

Mr. Khaled MENDACI *

Année universitaire 2014/2015

Bus CAN et applications

Remerciements

On tiens tout d’abord à remercier Monsieur Mendaci khaled , qui nous a tout

particulièrement proposé d’effectuer un projet de fin d’étude, pour lequel il a fait

montre d’une disponibilité de tous les instants et qui nous a fait profiter de son large

expérience et nos maîtres de pour ses conseils et confiance, pour m’avoir motivé (sans le

vouloir à poursuivre mes études vers une master .

Nous remercions les membres de jury, qui nous on fait l’honneur de participer

au jugement de ce travail.

Par ailleurs, nos remerciements vont à l’ensemble de nos professeurs du génie

Electrique, qu’ils veuillent bien trouver ici l’expression de nos sentiments les plus

respectueux.

Nous tenons aussi à remercier vivement tous la famille et tous ceux qui nous on

aidé de près ou de loin à élaborer ce projet. À savoir les collègues de notre promotion et

tout nos amis.

Bouguezmir abbes

2014-2015

SOMMAIRE

Introduction Générale ......................................................................................................... 3

Chapitre I Introduction aux réseaux informatiques et industriels

I.1. Introduction ................................................................................................................... 6 I.2. Les réseaux informatiques ............................................................................................. 6 I.3. Technologies des réseaux ................................................................................................ 8

I.3.1. Topologies des réseaux ........................................................................................... 8 a- Topologie de bus ................................................................................................. 9 b- Topologie en anneau ........................................................................................... 9 c- Topologie en étoile .............................................................................................. 9 d- Topologie en étoile étendue ................................................................................ 9

e- Topologie hiérarchique ....................................................................................... 9 f- Topologie maillée .............................................................................................. 10

I.3.2. Protocole de communication ................................................................................. 10

I.3.3. La notion de couches ............................................................................................. 11 I.4. Réseau local.................................................................................................................. 13 I.5. Réseau local industriel ................................................................................................. 13 I.6. Différence entre un réseau informatique et réseau industriel ....................................... 13 I.7. Les types de réseaux locaux industriels ....................................................................... 14

I.7.1. Les réseaux de terrain ............................................................................................ 14 I.7.2. Les réseaux de cellule ........................................................................................... 14 I.7.3. Les réseaux de salle de commande ....................................................................... 14

I.7.4. Les réseaux d‟usine ............................................................................................... 14 I.8. Pyramide CIM ............................................................................................................. 15

I.9. Rôle des réseaux industriels ......................................................................................... 16 I.10. Présentation rapide de quelques RLI .......................................................................... 17

I.10.1. Interbus ................................................................................................................ 17 I.10.2. Profibus ............................................................................................................... 17 I.10.3. LON ..................................................................................................................... 18

I.10.4. AS-Interface ........................................................................................................ 19 I.10.5. WorldFIP ............................................................................................................. 20

I.10.6. Interface SERCOS .............................................................................................. 20 I.10.7. FlexRay ............................................................................................................... 21 I.10.8. CAN (Control Area Network) ............................................................................. 21

I.11. Avantages et inconvénients des réseaux industriels ................................................... 21

I.11.1. Les avantages ...................................................................................................... 21

I.11.2. Inconvénients ...................................................................................................... 22

I.12. Conclusion .................................................................................................................. 22

Chapitre II Présentation du Bus CAN

II.1. Introduction ................................................................................................................. 23 II.2. Le Multiplexage .......................................................................................................... 23 II.3. Origines et utilisations du réseau CAN ....................................................................... 23

II.4. Protocole CAN ............................................................................................................ 25 II.5. CAN dans le modèle ISO/OSI .................................................................................... 26

II.5.1. La sous-couche MAC .......................................................................................... 26 II.5.2. La sous-couche LLC ............................................................................................ 27

II.5.3. La couche physique.............................................................................................. 27

II.6. Caractéristiques Physiques Du Bus CAN ................................................................. 28 II.7. Définitions des règles de fonctionnement ................................................................ 30

II.7.1. Nœud .................................................................................................................... 30 II.7.2. Valeurs du bus ..................................................................................................... 31

Sommaire

II.7.3. Message ............................................................................................................... 31

II.7.4. Routage des informations .................................................................................... 31 II.7.5. Trame de données et de requête ........................................................................... 31 II.7.6. Débit (bit/s) .......................................................................................................... 31 II.7.7. Priorités ................................................................................................................ 31 II.7.8. Demande d‟une trame de données ....................................................................... 31

II.7.9. Fonctionnement multi-maître .............................................................................. 32 II.7.10. Arbitrage ............................................................................................................ 32 II.7.11. Canal de liaison simple ...................................................................................... 32 II.7.12. Acquittement ...................................................................................................... 32 II.7.13. Sécurité de transmission .................................................................................... 32

II.7.14. Signalement des erreurs et temps de recouvrement des erreurs ........................ 33 II.7.15. Erreurs de confinement ...................................................................................... 33

II.7.16. Points de connexion ........................................................................................... 33

II.7.17. Mode Sleep (sommeil) et Mode Wake up (réveil)............................................. 33 II.7.18. Méthode de BitStufing ....................................................................................... 33

II.8. Protocole de niveau MAC ........................................................................................... 34 II.8.1. Identificateurs ...................................................................................................... 34 II.8.2. Arbitrage bit à bit ................................................................................................. 35

II.8.3. Types d‟échanges d‟objets identifiés ................................................................... 36 II.9. Types de trames ........................................................................................................... 37

II.9.1. Trame De Données .............................................................................................. 37

a- Champ d‟arbitrage ............................................................................................. 38 b- Champ de contrôle ............................................................................................ 38

c- Champ de données ............................................................................................ 39 d- Champ de CRC.................................................................................................. 40

e- Champ d‟acquittement ...................................................................................... 41 f- Champ de fin de trame....................................................................................... 42

II.9.2. Trame De Requête ............................................................................................... 42

II.9.3. Les trames d‟erreurs ............................................................................................. 43 II.9.3. 1. Traitement Des Erreurs ................................................................................. 44

a- Le Bit Error ....................................................................................................... 44 b- L‟erreur de Stuffing (Stuff Error)...................................................................... 45 c- L‟erreur de Cyclic Redundancy Code (CRC Error) .......................................... 45 d- L‟erreur d‟Acknowledge Délimiter ................................................................... 45

e- L‟erreur de Slot Acknowledge (Acknowledgment Error)................................. 45

II.9.3. 2. Recouvrement des erreurs ............................................................................. 46

II.9.3. 3. Les modes d‟erreurs ...................................................................................... 46 a- Mode d‟erreur active ......................................................................................... 46 b- Mode d‟erreur passive ....................................................................................... 46 c- Mode Bus Off .................................................................................................... 46 II.9.3. 4. La gestion des modes d‟erreur ..................................................................... 46

II.9.3. 5. Les règles de passages dans les modes ......................................................... 47 a- Le compteur de réception est incrémenté de 1 si .............................................. 47 b- Le compteur de réception est incrémenté de 8 si .............................................. 47 c- Le compteur de transmission est incrémenté de 8 si ......................................... 47 d- Les compteurs d‟émission et de réception s‟incrémentent de 8 si .................... 48

e- Le compteur de réception est décrémenté de 1 si.............................................. 48 f- Le compteur d‟émission est décrémenté de 1 si ................................................... 48

II.9.4. Trame de surcharge .............................................................................................. 48 II.9.4.1. Période d‟intertrame...................................................................................... 49

a- Le champ d‟intermission ................................................................................... 49

b- Le champ de Bus Idle ........................................................................................ 49 c- Le champ de suspension de transmission .......................................................... 49 d- Autres modes ..................................................................................................... 49

II.10. Codage de ligne.......................................................................................................... 50 II.11. Le nominal bit time ................................................................................................... 50

II.12. Description des différents segments .......................................................................... 51 II.12.1. le segment de synchronisation ........................................................................... 51 II.12.2. Le segment de propagation ................................................................................ 51 II.12.3. Les segments « buffer phase1 » et « buffer phase2 » ........................................ 52 II.12.4. Le point d‟échantillonnage ou sample point ...................................................... 52

II.12.5. Durée des différents segments et notion de Time Quantum .............................. 52 a- Le Time Quantum ............................................................................................. 52

b- La durée des différents segments : .................................................................... 53

Chapitre III Applications Sur Bus CAN

III.1. Introduction ................................................................................................................ 55 III.2. Contrôleur CAN ......................................................................................................... 55 III.3. Résistance de terminaison de bus ............................................................................... 55

III.3.1. A quoi servent les résistances de terminaison ? ................................................. 55

III.3.2. Est-ce qu‟elles sont obligatoires ? ...................................................................... 56 III.4. Première application ................................................................................................... 56

III.4.1. Description de la platine de communication (Hardware) .................................... 56

III.4.2. Présentation des composants utilisés ................................................................... 58 a- Le microcontrôleur PIC16F877A..................................................................... 58

b- Le MCP2515 ..................................................................................................... 61 c- Transmetteur CAN ........................................................................................... 61

d- Afficheur LCD .................................................................................................. 62 e- Capteur de température LM35 ......................................................................... 63

III.4.3. Manipulation et software ..................................................................................... 63

III.5. Le compilateur Mikroc pour Pic ................................................................................. 66 III.5.1 Quelques fonctions utilisées dans le programme ............................................... 67

III.6. Deuxième application ................................................................................................ 68 III.6.1 Introduction ........................................................................................................ 68 III.6.2. Présentation Du Système .................................................................................... 69 III.6.3. Objectif principal ............................................................................................... 71

III.7. Réalisation .................................................................................................................. 71

III.8. Conclusion .................................................................................................................. 73

Conclusion général ............................................................................................................ 74 Bibliographie ....................................................................................................................... 75 Web graphie ......................................................................................................................... 75 Résumé ................................................................................................................................ 77

Figure 1.1 : Classification des réseau informatiques en fonction de leur taille .......................... 6

Figure 1.2 : Les topologies physique .......................................................................................... 8

Figure 1.3 : Les 7 couches du modèle OSI de l‟ISO ................................................................ 11

Figure 1.4 : A chaque niveau correspond un bus ou un réseau. ............................................... 15

Figure 1.5 : Pyramide CIM ....................................................................................................... 16

Figure 1.6 : Carte d'interface Interbus - Anybus-S ................................................................... 17

Figure 1.7 : le réseau profibus .................................................................................................. 18

Figure 1.8: Exempl de reseau LON ......................................................................................... 19

Figure 1.9 : Exemple de AS interface ..................................................................................... 19

Figure 1.10: interface SERCOS.............................................................................................. 20

Figure 2.1: Représentation du model ........................................................................................ 26

Figure 2.2 : Architecture CAN. ................................................................................................ 27

Figure 2.3: Topologie en bus du réseau CAN .......................................................................... 28

Figure 2.4 : Niveaux de tension du bus CAN low speed .......................................................... 29

Figure 2.5: Niveaux de tension du bus CAN high speed ......................................................... 30

Figure 2.6 : Technique de Bit-Stuffing ..................................................................................... 34

Figure 2.7 : Principe d‟arbitrage du réseau CAN. .................................................................... 36

Figure 2.8: Format de la trame CAN. ....................................................................................... 38

Figure 2.9: Champ d‟arbitrage dans le bus CAN. ................................................................... 38

Figure 2.10: Champ de contrôle dans le bus CAN. ................................................................. 39

Figure 2.11: Champ de CRC dans le bus CAN. ..................................................................... 40

Figure 2.12: Champ d‟acquittement dans le bus CAN. ........................................................... 41

Figure 2.13: Format de la trame de Requête . .......................................................................... 42

Figure 2.14 : Construction de la trame d'erreur ........................................................................ 43

Figure 2.15: Trame d'erreur active ........................................................................................... 43

Figure 2.16 : Trame d'erreur passive ........................................................................................ 44

Figure 2.17: Sources d'erreur dans la trame CAN .................................................................... 45

Figure 2.18: Compteur d'erreur et état d'un nœud .................................................................... 47

Figure 2. 19 : Trame de surcharge ............................................................................................ 48

Figure 2.20 : Période d'intertrame ............................................................................................ 49

Figure 2.21 : Codage NRZ du bus CAN .................................................................................. 50

Figure 2.22 : Décomposition du nominal Bit Time .................................................................. 51

Figure 2.23: Construction du Time Quantum ........................................................................... 52

Figure 2.24: Durée des différents segments ............................................................................. 53

Figure 2.25: L‟interface du logiciel « CANCALCULATOR » ............................................... 54

Figure 3.1: Réseau CAN Spi Réalisé Avec 3 Nœuds ............................................................. 56

Figure 3.2: schéma d‟interconnexion du trois cart au bus can ................................................ 57

Figure 3.3: PIC16F877A ......................................................................................................... 58

Figure 3.4: le microcontrolleur et ces differents organes ...................................................... 58

Figure 3.5: Diagrammes De Broche pic 16F877A .................................................................. 59

Figure 3.6: MCP 2515 et Diagrammes De Broche .................................................................. 61

Figure 3.7: MCP 2551 et Diagrammes De Broche .................................................................. 61

Figure 3.8: Afficheur LCD QC1602A V2.0 et son brochage .................................................. 62

Figure 3.9: Capteur De Température LM35dz ........................................................................ 63

Figure 3.10: La Communication CAN .................................................................................... 64

Figure 3.11: Filtrage De Messages Dans Le Bus CAN ............................................................ 65

Figure 3.12: organigramme de fonctionnemt de l‟application can .......................................... 65

Figure 3.13: les libreries CAN et CAN SPI DE MikroC ........................................................ 66

Figure 3.14: Réseau CAN Réalisé Avec 2 Nœuds « mesurer la température » ..................... 69

Liste des Figures

Figure 3.15: Exemple Réseau CAN dans l‟automobile .......................................................... 70

Figure 3.16: Réseau CAN avec interface spi pour contrôler la température ........................... 71

Figure 3.17: Alimentation stabilisée utilisée dans le projet. .................................................... 71

Figure 3.18: Organigramme de fonctionnent de l‟application Dans Le Bus CAN ................. 72

Figure 3.19: schéma d‟interconnexion des deux cartes au bus CAN ...................................... 73

Tableau 2.1 : Les 2 types de bus CAN ..................................................................................... 29

Tableau 2.2 : Codage des bits DLC suivant la taille des données en octets. ............................ 39

Tableau 2.3 : La durée des différents segments........................................................................ 53

Tableau 3.1 : fonction de chaque broche de l‟afficheur LCD et sa connexion ....................... 62

Liste des Tableaux

API Automate Programmable Industrial

ASICS Application Specific Integrated Circuits

AS-INTERFACE Actuator Sensor Interface

CAN Controller Area Network

CFAO Conception Et Fabrication Assistées Par Ordinateur

CIA Can In Automation

CIM Computer Integrated Manufacturing

CMRR Common Mode Rejection Ratio

CPU Central Processing Unit

CRC Cyclic Redundancy Code

CSMA/CR Carrier Sense Multiple Access With Collision Resolution

DLC Data Length Code

EOF End Of Fram

FIP Factory Instrumentation Protocol

FSK Frequency-Shift Keying

IEEE Institute Of Electrical And Electronics Engineers

IP Internet Protocol

ISO International Standarization Organization

LAN Local Area Network

LLC Contrôle De Liaison Logique

LON Local Operating Network

MAC Contrôle D'accès Au Médium

MAN Metropolitan Area Network

MAP Manufacturing Automation Protocol

MDI Medium Dependent Interface

MODBUS/RTU Modbus Remote Terminal Unit

MPI Multi Point Interface - Siemens

NRZ Non Return To Zero

OSI Open System Interconnections

PAN Personal Area Network

PHASE_SEG1 Le Segment De Phase Buffer N1

PHASE_SEG1 Le Segment De Phase Buffer N2

Abréviations

http://fr.wikipedia.org/wiki/Modbus

PLS Physical Signalling

PMA Physical Medium Attachment

PROFIBUS Process Field Bus

PROFIBUS-DP Decentralised Peripheral) (Périphérie Décentralisée

PROFIBUS-PA Process Automation

PROP_SEG Le Segment De Propagation

RDL Resestance De Débutligne

RFL Resestance De Fin Ligne

RLI Réseau Local Industriel

RTR Remote Transmision Request

SCADA Supervisory Control And Data Acquisition

SERCOS Serial Real-Time Communications System

SOF Start Of Fram

SYNC_SEG Le Segment De Synchronisation

TDMA Time-Division Multiple Access

TQ Time Quantum

VAN Véhicul Area Network

WAN Wide Area Network

Introduction

Générale

Introduction Générale

3


Les réseaux locaux industriels ont été 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.

C'est ainsi qu'est né le réseau de Westinghouse (Jeumont- Schneider en France) dans les

années 70. Ce réseau était essentiellement utilisé dans les processus continus, les premiers

à être automatisés et à innover dans les nouvelles technologies de l'automatique et de

l'informatique industrielle. Puis est né le réseau MODBUS de Gould Modicon, pour

coordonner les activités sises sur plusieurs automates. Dans les processus continus, des

calculateurs dits d'optimisation étaient utilisés de longue date pour envoyer des consignes

sous forme d'aides aux opérateurs. Il est apparu utile de les connecter d'une part aux

stations de travail des opérateurs et d'autre part aux équipements qui pilotent les machines

de production. Le grand développement des réseaux locaux industriels date du début des

années 80. Le projet MAP nait aux Etats Unis, la notion de réseau de terrain émerge sous

le nom de réseau ou bus d'instrumentation en 1982. [1]

L'automatisation, puis l'informatisation des systèmes de production ont montré que

pour l'amélioration de la productivité et de la diversité de la production, il ne suffisait pas

de maîtriser la gestion de production, ou d'avoir une machine-outil à commande numérique

sophistiquée, ou encore un système de contrôle-commande évolué et quelques capteurs et

actionneurs autour. Encore faut-il faire communiquer tous ces éléments constitutifs d'un

système de production dans sa globalité. Faire communiquer c'est permettre d'échanger des

informations de natures différentes et ce parfois nécessairement en temps réel.

Un nouvel outil informatique apparaît alors, avec sa problématique scientifique : le

réseau local industriel. Son rôle est donc de faire dialoguer des équipements nombreux et

divers, en intégrant une caractéristique importante, celle de fournir des services contraints

par le temps. Ces réseaux locaux industriels, parfois appelés abusivement réseaux de

terrain, s'inscrivent donc à différents niveaux au sein de la pyramide CIM classique , qui

En plus de la transmission de variables numériques, analogiques ou binaires issues

d'acquisitions de capteurs ou destinées à l'application sur des actionneurs, ces réseaux sont


4

de par l'émergence des technologies de communication (industrielles notamment) donne

lieu à une organisation de fonctions autour de réseaux

En plus de la transmission de variables numériques, analogiques ou binaires issues

d'acquisitions de capteurs ou destinées à l'application sur des actionneurs, ces réseaux sont

amenés à transmettre des informations de plus haut niveau telles que des fichiers ou des

requêtes paramétrées issus par exemple d'un superviseur et destinés à un coordinateur de

cellule. Ceci est induit par la décentralisation des fonctions classiques d'un système de

contrôle-commande, que sont la commande locale, la coordination, la surveillance et la

supervision (décentralisation facilitée par l'émergence des équipements intelligents).

Les réseaux sont donc amenés à véhiculer des données de natures et tailles

différentes, et surtout dont les contraintes temporelles de transfert sont différentes.

Echanges périodiques temps-réel et apériodiques cohabitent donc sur de nombreux réseaux

La diversité des domaines industriels (l'industrie dans son ensemble) laisse

apparaître des besoins, des exigences et des intérêts divers. Derrière le terme industrie on

peut s‟imaginer une usine de production de véhicules, une usine agro-alimentaire, un site

de production d'énergie, etc. Toutes sont concernées par le phénomène des bus de terrain.

Cependant, l‟approche des bus de terrain doit tenir compte de leurs différences.

Ceci dit, l'utilisation d'un bus de terrain ne se limite pas à l'industrie au sens système de

production mais s'applique également au niveau du "produit" lui-même.

L'idée de ce projet n'est pas totalement nouvelle, en effet il existe sur l‟industrie

plusieurs modèles de réseau comme Bit Bus , CAN bus , LON , Inter bus, ect …

Mais l‟originalité de notre étude est d‟essayer de comprendre le principe de

fonctionnement et de rendre la réalisation d‟un réseau CAN possible .Nous chercherons

donc dans ce projet ; comment réaliser un réseau CAN entre deux Nœuds, en suite trois

Nœuds .

Nous allons crieras un réseau CAN via microcontrôleur PIC, la première étape

c‟est de réussir une communication entre deux PIC de même type en half-deplex ou full-

duplex , En suite adapter un troisième nœud dès que possible .

Une dernière application semblable au système existant sur automobile sera étudiée

où la synchronisation entre deux nœud sera étudiée; le premier sert à l‟acquisition de

température alors que le deuxième nœud affiche la grandeur mesurée.


5

Un tel système peut être piloté numériquement à l'aide d'un microcontrôleur qui

peut être développé en langage machine (assembleur) ou en un langage évolué (comme

Mikro C) .

Le premier chapitre en une étude théorique des différentes réseaux de terrain en

particuliers le réseau CAN.

Par la suite une bonne partie sera consacrée dans le deuxième chapitre à présenter

le réseau CAN en détail , afin de connaître ses différentes caractéristiques qui auront une

influence directe sur la réalisation de notre montage.

Dans le troisième chapitre nous allons tenter de réaliser quelque prototypes

pratiques de communication via bus CAN en s‟ appuyer sur les caractéristiques soft et hard

disponibles . la démarche se veut avant tout progressive , nous partirons donc d‟un

montage de base ou un allumage successif des LEDS avec décalage et permutation entre

différents nœuds sera présenté, puis nous allons essayer de l‟améliorer pour s‟approcher à

une application réelle , ou un système d‟acquisition et d‟affichage entre deux nœuds sera

présenté .

En fin nous terminerons par une conclusion générale pour synthétiser les résultats

obtenus de ce travail et présenter les perspectives.

CHAPITRE I

Introduction Aux

Réseaux Informatiques

Et Industriels


6

I.1. Introduction

On appelle réseau un ensemble de moyens qui permettent la communication entre

des processus d'application ou tâches répartis sur des matériels informatiques de tout type.

Cet ensemble est constitué d'au moins un support de transmission pour l'acheminement des

signaux, et de protocoles de communication selon une architecture en couches conforme

ou non au modèle OSI (Open System Interconnections) ,On parle parfois de système de

communication pour désigner le mot réseau.

On dit souvent qu'un réseau connecte des machines, ce qui est une réalité, mais en

fait il permet surtout la communication entre les tâches qui s'exécutent sur les machines.

I.2. Les réseaux informatiques

Les réseaux informatiques sont nés du besoin de relier des terminaux distants à un

site central puis des ordinateurs entre eux et enfin des machines terminales, telles que des

stations de travail ou des serveurs. Dans un premier temps, ces communications étaient

destinées au transport de données informatiques. Aujourd'hui, l'intégration de la parole

téléphonique et de la vidéo sur ces réseaux informatique devient naturelle, même si cela ne

va pas sans difficulté.

On compte généralement quatre catégories de réseaux informatiques, différenciées

par la distance maximale séparant les points les plus éloignés du réseau :

RESEAUX

PERSONNEL

PAN

RESEAUX

LOCAUX

LAN

RESEAUX METROPOLITAINS

MAN

RESEAUX

ETENDUS

WAN

100KM10KM1KM100M10M1M

Figure 1.1 : Classification des réseau informatiques en fonction de leur taille

- La plus petite taille de réseaux définit les PAN ( Personal Area Network). Ces

réseaux personnels interconnectent sur quelques mètres les équipements personnels tels

que GSM, portable, organiseurs, etc., d'un même utilisateur.


7

- Les réseaux locaux, également appelés LAN ( Local Area Network ).

Correspondent par leur taille aux réseaux intra entreprise. Ils servent au transport de toutes

les informations numériques de l'entreprise. En règle générale, les bâtiments à câbler

s'étendent sur plusieurs centaines de mètres. Les débits de ces réseaux vont aujourd'hui de

quelques mégabits à plusieurs centaines de mégabits par seconde.

- Les réseaux métropolitains, ou MAN ( Métropolitan Area Network ), permettent

l'interconnexion des entreprises ou éventuellement des particuliers sur un réseau spécialisé

à haut débit qui est géré à l'échelle d'une métropole. Ils doivent être capables

d'interconnecter les réseaux locaux des différentes entreprises pour leur donner la

possibilité de dialoguer avec l'extérieur.

- Les réseaux étendus, ou WAN ( Wide Area Network ), sont destinés, comme leur

nom l'indique, à transporter des données numériques sur des distances à l'échelle d'un pays,

voir d'un continent ou de plusieurs continents. Le réseau est soit terrestre, et il utilise en ce

cas des infrastructures au niveau du sol, essentiellement de grands réseaux de fibre optique,

soit hertzien, comme les réseaux satellite.

les techniques utilisées par ces réseaux informatiques proviennent toutes du transfert de

paquets, comme le relais de trames, Ethernet, les réseaux IP, etc.

une caractéristique essentielle de ces réseaux informatiques, qui les différentie

totalement des autres catégories de réseaux, provient de la gestion et du contrôle du réseau

qui sont effectués par les équipements terminaux. Par exemple, pour qu'il n'y ait pas

d'embouteillage de paquets dans le réseau, l'équipement terminal doit se réguler lui-même

pour ne pas inonder le réseau de paquets. Pour se réguler, l'équipement terminal mesure le

temps de réponse aller-retour. Si ce temps de réponse grandit trop, le terminal ralentit son

débit. On peut traduire cette fonction par le fait que l'intelligence du réseau se trouve dans

les machines terminales, c.à.d. dans les machines commercialisées par l'industrie

informatique, d'où leur nom de réseau informatique. L'intérieur de réseau est généralement

des plus simple, constitué de nœuds de transfert élémentaires et de lignes de

communication. Le coût du réseau est surtout représenté par les équipements terminaux,

qui possèdent toute la puissance nécessaire pour réaliser, contrôler et maintenir les

communications.

Les réseaux informatiques forment un environnent asynchrone. Les données

arrivent aux récepteurs à des instants qui ne sont pas définis à l'avance, et les paquets

peuvent mettre un temps plus ou moins long à parvenir à leur destinataire en fonction de la

saturation du réseau. Cette caractéristique explique la difficulté de faire passer de la parole


8

téléphonique dans ce type de réseau, puisque cette application, fortement synchrone,

nécessite de remettre au combiné téléphonique des octets à des instants précis.

Aujourd'hui, le principal réseau informatique est représenté par internet. Le réseau

internent transporte des paquets dits IP (Internet Protocol), qui ont une structure précise.

Plutôt que de parler de réseau de réseau Internet, nous préférons parler de réseau IP, qui

marque une plus grande généralité.

Les réseaux IP sont des réseaux qui transportent des paquets IP d'une machine terminale à

une autre. En un certain sens, Internet est un réseau IP particulier. D'autres réseaux, comme

les réseaux intranet, transportent également des paquets IP, mais avec des caractéristiques

différentes d'Internet.

I.3. Technologies des réseaux

I.3.1. Topologies des réseaux

Figure 1.2 : Les topologies physique

la topologie d‟un réseau constitue l‟organisation ou la relation des périphériques

réseau et les interconnexions existant entre eux. Les topologies réseau peuvent être

observées au niveau physique et au niveau logique.

La topologie physique constitue l‟organisation des nœuds et les connexions

physiques établies entre eux.


9

La représentation de la manière dont le support est utilisé pour interconnecter les

périphériques est la topologie physique. Une topologie logique constitue la manière dont

un réseau transfère les trames d‟un nœud à l‟autre. Cette organisation consiste en

connexions virtuelles établies entre les nœuds d‟un réseau quel que soit leur agencement

physique. Ces chemins de signaux logiques sont définis par les protocoles de couche

liaison de données. La topologie logique d‟un réseau lorsqu‟elle contrôle l‟accès des

données aux supports. C‟est la topologie logique qui influence le type de trame réseau et de

contrôle d‟accès au support utilisé.

La topologie physique ou câblée d‟un réseau diffère généralement de la topologie

logique.

La topologie logique d‟un réseau est étroitement liée au mécanisme utilisé pour

gérer l‟accès au réseau. Les méthodes d‟accès fournissent les procédures permettant de

gérer l‟accès au réseau de sorte que toutes les stations de travail puissent accéder au réseau.

Lorsque plusieurs entités partagent le même support, un mécanisme doit être mis en place

pour contrôler l‟accès à ce support. Les méthodes d‟accès sont appliquées aux réseaux pour

réguler l‟accès aux supports.

Les topologies physiques généralement utilisées dans les réseaux :

a- Topologie de bus

Une topologie de bus fait appel à un câble de Backbone unique qui est terminé aux

deux extrémités. Tous les hôtes se connectent directement à ce Backbone.

b- Topologie en anneau

Dans une topologie en anneau, chaque hôte est connecté à son voisin. Le dernier

hôte se connecte au premier. Cette topologie crée un anneau physique de câble.

c- Topologie en étoile

Dans une topologie en étoile, tous les câbles sont raccordés à un point central.

d- Topologie en étoile étendue

Une topologie en étoile étendue relie des étoiles individuelles en connectant les

concentrateurs ou les commutateurs. Cette topologie peut étendre la portée et la couverture

du réseau.

e- Topologie hiérarchique

Une topologie hiérarchique est similaire à une topologie en étoile étendue.

Cependant, plutôt que de lier les concentrateurs ou commutateurs ensemble, le système est

lié à un ordinateur qui contrôle le trafic sur la topologie.


10

f- Topologie maillée

On implémente une topologie maillée afin de garantir une protection maximale

contre l‟interruption de service. Par exemple, une topologie maillée représente une solution

idéale pour les systèmes de contrôle en réseau d‟une centrale nucléaire. Comme vous

pouvez le voir dans le schéma, chaque hôte possède ses propres connexions à tous les

autres hôtes. Bien qu‟Internet emprunte de multiples chemins pour atteindre un

emplacement, il n‟adopte pas une topologie complètement maillée.

I.3.2. Protocole de communication

Un protocole de communication est une spécification de plusieurs règles pour un

type de communication particulier. Initialement, on nommait protocole, ce qui est utilisé

pour communiquer sur une même couche d‟abstraction entre deux équipements différents.

Par extension de langage, on utilise parfois ce mot aussi aujourd‟hui pour désigner les

règles de communication entre deux couches sur un même équipement. Le modèle OSI

(Open System Interconnexion) a été créé par l‟ISO ( internastional Standarization

Organization) qui a édité la norme ISO 7498 dans le but d‟offrir une base commune à la

description de tout réseau informatique. Dans ce modèle, l‟ensemble des protocoles d‟un

réseau est décomposé en 7 parties appelées couches OSI, numérotées de 1 à 7. Les couches

OSI respectent les principes suivants :

chaque couche supporte un protocole indépendamment des autres couches.

chaque couche procure des services à la couche immédiatement supérieure.

chaque couche requiert les services de la couche immédiatement inférieure.

la couche 1 décrit le médium (le support de communication).

la couche 7 procure des services à l‟utilisateur ou à une application.

Lors d‟une communication, l‟utilisateur d‟un réseau utilise les services de la couche 7 via

un programme. Cette couche met en forme et enrichit l‟information qu‟elle reçoit du

programme en respectant son protocole. Puis, elle l‟envoie à la couche inférieure lors

d‟une demande de service. À chaque couche, l‟information subit des mises en forme et des

ajouts en fonction des protocoles utilisés. Enfin, elle est envoyée sur le médium et reçue

par un autre noeud du réseau. Elle parcourt toutes les couches de ce noeud dans l‟autre

sens pour finir au programme du correspondant, dépouillée des différents ajouts liés aux

protocoles. Les sept couches initiales du modèle sont rappelées par la Figure 1.3


11

Figure 1.3 : Les 7 couches du modèle OSI de l’ISO

I.3.3. La notion de couches

Le modèle OSI (Open System Interconnections) propose une organisation en sept

couches pour les réseaux. Rappel succinct des différentes couches :

1. La couche 1 (couche physique) : Elle décrit les règles mécaniques et électriques

d'accès au média (représentation physique des données, encodage, vitesse et type de

transmission, type de média et topologie (maillage).

2. La couche 2 (la liaison de données) : Elle détecte et corrige les erreurs de

transmission,établit les connexions logiques entre les entités.

3. La couche 3 (le réseau) : Elle définit les mécanismes du routage c'est à dire de

transfert des paquets d'information d'une station à l'autre (possède un répertoire des

adresses des points du réseau, gère l'adresse réseau de son système, définit en

collaboration avec les autres nœuds les circuits de dialogue utilisés, établit la

relation entre la destination des données et les liaisons de son système).


12

4. La couche 4 (le transport) : C'est la frontière entre le monde de la transmission

(couches 1, 2 et 3) et celui de l'application (couches 5, 6 et 7). Elle définit les

protocoles permettant de garantir les transferts de messages "longs" avec un

maximum de sécurité (détection de perte d'information, segmentation des

messages, contrôle des erreurs, contrôle de flux).

5. La couche 5 (la session) : Elle offre les moyens d'organiser et de synchroniser le

dialogue entre abonnés.

6. La couche 6 (la représentation) : Elle présente les données dans un format

reconnaissable par l'application (conversion de codes ou de formats de données,

sélection de la syntaxe, compression et cryptage des données).

7. La couche 7 (l'application) : Son rôle est de fournir aux applications résidentes

tous les moyens de dialogue. Il s'agit par exemple d'une interface utilisateur.

Le modèle OSI gère les grands réseaux à commutation de paquets. Le temps n'a pas

été pris en compte. Pour les réseaux locaux, la notion de temps réel est un point très

important. La couche physique est indispensable à la communication. La couche liaison de

données aussi pour la détection des erreurs. Les couches réseaux et transport ont été

définies pour gérer les problèmes des paquets qui transitent par des stations intermédiaires

: elles n'ont plus lieu d'être pour les RLI car toutes les stations sont interconnectées. La

couche session permet l'échange d'une grande quantité d'information, ce qui n'est pas le cas

pour les RLI. La couche présentation peut être figée et non dynamique ce qui la rend

transparente. La couche application reste évidemment nécessaire.

Il en résulte un modèle ( IEEE 802 ) à trois couches :

Physique .

Liaison : - MAC (contrôle d'accès au médium) : Règle les accès au support de

communication(aléatoire CSMA/CD, par consultation, jeton).

- LLC (contrôle de liaison logique) : utilise la couche de contrôle

d'accès au médium pour offrir à l'utilisateur des services tels

que l'émission et la réception de trames, l'établissement et la

fermeture des connexions logiques, la détection des erreurs de

séquencement de trames et le contrôle de flux.

Application .


13

I.4. Réseau local

On appelle réseau local un réseau qui couvre une zone géographique limitée, par

opposition aux réseaux publics ou longue distance.

Parmi les réseaux locaux, on distingue souvent les réseaux locaux d'entreprise et les

réseaux locaux industriels. Ils diffèrent essentiellement par les contraintes d'environnement

(temps et sûreté de fonctionnement) et par certains services et protocoles mis en œuvre

pour tenir compte des différences de besoins des applications qui les utilisent.

I.5. Réseau local industriel

Un réseau local industriel est en première approximation un réseau local utilisé

dans une usine ou tout système de production pour connecter diverses machines afin

d'assurer la 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 ; entend ces

dernières année l‟utilisation d‟un système dit SCADA (Supervisory Control and data

Aquisation )

Mais l'aspect connexion de machines, même s'il est fondamental, n'est pas le seul à

considérer. Ce sont surtout les processus d'application répartis sur les machines qui sont

mis en relation par les réseaux. Et ce sont ces types de relations qui dicteront le choix d'un

réseau plutôt que d'un autre. Les besoins en communication sont alors très diversifiés selon

les matériels connectés et les applications qu'ils supportent, ce qui explique que les réseaux

locaux industriels sont nombreux et variés. Il est évident que le trafic entre des capteurs,

des actionneurs et des automates n'est pas le même qu'entre un système de CFAO et un

contrôleur de cellule de fabrication. Les besoins diffèrent selon des critères comme la taille

des données à transmettre, les contraintes de temps associées, les coûts acceptables de

connexion, les technologies qu'il est possible de mettre en oeuvre. Il sera donc nécessaire

d'étudier globalement les architectures des systèmes automatisés pour analyser en détail les

divers types de communication et classer les réseaux locaux industriels. Pour satisfaire tous

ces besoins, de très divers protocoles ont été définis depuis une quinzaine d'années,

certains ont été normalisés, d'autres sont devenus des standards de fait, d'autres enfin sont

purement privés. [2]

I.6. Différence entre un réseau informatique et réseau industriel

Un réseau industriel joue le même rôle qu'un réseau normal . Le but premier est

toujours de transmettre des informations entre plusieurs machines. Lorsque l'on parle de

réseaux, on sous-entend généralement que les machines sont des ordinateurs. Lorsque l'on


14

parle de réseaux industriels, il s'agit de faire communiquer des machines qui ne sont plus

seulement des ordinateurs. On fait communiquer des appareils différents tels que des

ordinateurs, des automates programmables, des appareils de mesures, des équipements

spécifiques (fours, commandes numériques, ascenseurs, ...).

Le qualificatif d'industriel pour un réseau sous-entend également un environnement

particulier. L'environnement d'un réseau industriel est en général un environnement

perturbé. C'est environnement est souvent pollué par des ondes électromagnétiques

provenant des différents appareils (moteurs, courants forts, champs magnétiques,...).

Tous ces phénomènes sont à prendre en compte dans la couche 1 du modèle OSI.

I.7. Les types de réseaux locaux industriels

I.7.1. 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 industriels, mais d‟autres très importants, de

synchronisation par exemple, seront aussi définis pour faciliter la distribution des

applications.

I.7.2. Les réseaux de cellule

Parfois appelés réseaux intermédiaires, 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.

I.7.3. Les réseaux de salle de commande

Dans les processus continus, ramènent aux opérateurs les informations qui leur sont

nécessaires pour conduire le processus et qui leur permette de fixer les points de consigne,

ou divers paramètres pour les régulateurs et automates. Ils connectent des automates, des

systèmes numériques de contrôle-commande, des systèmes de supervision, etc.

I.7.4. Les réseaux d’usine

Irriguent l‟ensemble de l‟usine, interconnectant des ateliers, des cellules avec les

bureaux d‟études ou des méthodes, avec les services administratifs, commerciaux et

financiers de l‟entreprise.


15

Figure 1.4 : A chaque niveau correspond un bus ou un réseau.

I.8. Pyramide CIM

La pyramide du CIM est une représentation conceptuelle, qui comporte 4 niveaux

auxquels correspondent des niveaux de décision. Plus on s'élève décision/d'abstraction est

important, plus la visibilité est globale et plus les horizons et cycles opérationnels

s'allongent. [ 3]


16

Un niveau supérieur décide ce qu'un niveau inférieur exécute .

Niveau 3 : la gestion des produits et des stocks, la gestion des approvisionnements,

la gestion des clients, des commandes et de la facturation .

Niveau 2 : la localisation des produits en stocks, les mouvements physiques et la

gestion des lots (géré par le système de gestion d'entrepôt) .

Niveau 1 : les automatismes

Niveau 0 : les capteurs et actionneurs.

Figure 1.5 : Pyramide CIM

(C.I.M.: Computer Integrated Manufacturing)

I.9. Rôle des réseaux industriels

L‟un des rôles du réseau de terrain est de fournir l‟outil de communication

. On demande à un réseau de terrain :

De simplifier la réalisation d‟un automatisme et lui permettre d‟évoluer tout en

améliorant ou, au moins en conservant, la qualité de service actuelle (fonctions

de régulation et de contrôle du procédé, sûreté de fonctionnement, accessibilité

aux variables du procédé, ...).

De faciliter l‟emploi des capteurs et actionneurs “intelligents”, qui permettent

d‟améliorer la maintenabilité du Système Automatisé de Production et, en


17

conséquence, de permettre l‟échange d‟informations nécessaires à leur télé-

paramétrage, leur télé réglage, leur télé forçage,

D‟améliorer la disponibilité de l‟installation en permettant d‟accéder aux

différentes informations nécessaires (maintenance, télédiagnostic, gestion

industrielle,..).

I.10. Présentation rapide de quelques RLI

Parmi les réseaux de terrain existant on trouve :

I.10.1. Interbus

Interbus est un système performant et facile à mettre en œuvre pour des

applications standard d'API avec des entrées/sorties numériques. La carte maître Interbus

se comporte comme une carte d'entrées/sorties internes et ne nécessite pas de

programmation Interbus, avec l'apparition d'interbus-Loop, constitue une solution courante

pour l'automatisation de processe

La quatrième génération d'InterBus met à disposition des utilisateurs des caractéristiques

étendues dont les plus importantes sont les suivantes :

Possibilité de 62 canaux de paramètre pour les données complexes.

Structures en arbre jusqu'à 16 niveaux.

Communication transversale entre deux abonnés (communication esclave/esclave).

Prétraitement des données pour diminuer la charge de la commande centrale.

Utilisation en mode synchrone.

Figure 1.6 : Exemple de Carte d'interface Interbus

I.10.2. Profibus

Profibus (Process Field Bus) est le nom d'un type de bus de terrain propriétaire et

de son protocole, inter-automates et de supervision. Il est devenu peu à peu une norme de

communication dans le monde de l'industrie ces dix dernières années, mais son usage tend

à disparaître au profit d'autres bus de terrain ou de réseaux .


18

Le bus Profibus-DP (Decentralised Peripheral) (périphérie décentralisée) est utilisé

pour la commande déterministe dite "temps réel" de capteurs et d'actionneurs par une

commande centrale, par exemple par un programmable réalisant des fonctions

d'automatisme et de régulation. Il est utilisé aussi pour la connexion d'une « intelligence

distribuée », c'est-à-dire la mise en communication de plusieurs automates les uns avec les

autres .

Le bus Profibus-PA (Process Automation) est utilisé, dans le cadre de l'ingénierie

de procédé, pour relier des équipements de mesure à un système de pilotage

(automatisme, régulation, supervision) de procédé par l'intermédiaire d'une paire de

conducteurs portant également l'alimentation de l'instrumentation (vanne de régulation,

capteurs, etc.).Siemens étant propriétaire de ce protocole, il est logique que la majorité des

automates qu'il propose dispose nativement d'une interface Profibus-DP pour le dialogue

avec le PC de programmation, supportant aussi le protocole MPI ( Multi Point Interface ).

Mise à part sa fonction servant à lier le PC de programmation à la CPU, le Profibus-DP

peut servir de liaison entre un maître (par exemple la CPU) et ses esclaves (ET,

Micromaster, IM...). [ 4]

.

Figure 1.7 : Le réseau profibus

I.10.3. LON

LON (Local Operating Network) est un système de communication développé par la

société américaine Echelon pour les applications réparties telles que l'automatisation des

bâtiments, la productique, le stockage, le convoyage ainsi que pour l'alimentation en eau,

gaz et électricité. LON ne peut être directement assimilé au niveau capteur/ actionneur ni

aux niveaux de communication supérieur. Au contraire, il a pour objectif de répartir les

tâches de commande en petites tâches à exécuter sous forme décentralisée, de manière

similaire à l'esprit client-serveur. Des décisions doivent être prises directement dans les

noeuds du réseau, sans autres systèmes de bus ou composants, et sans par exemple, affecter

http://fr.wikipedia.org/wiki/D%C3%A9terministe

http://fr.wikipedia.org/wiki/Syst%C3%A8me_temps_r%C3%A9el

http://fr.wikipedia.org/wiki/Capteur

http://fr.wikipedia.org/wiki/Actionneur


19

la charge des ordinateurs supérieurs. Ce type de communication est aussi appelé système

« d'automatisation intelligente décentralisée ». LON supporte, au niveau du réseau, la

répartition et la gestion de variables

Figure 1.8: Exemple de réseau LON

I.10.4. AS-Interface

AS-Interface (Actuator Sensor Interface) est le fruit d'un développement commun

de onze fabricants de capteurs/actionneurs, de système de commande et de deux instituts

universitaires. L'objectif de ce développement était de mettre à disposition un système

simple, sûr, rapide et de remplacer par une paire non blindée le câblage traditionnel au

niveau terrain. L'Association AS-Internatinal assure la diffusion du bus et regroupe les

membres et les utilisateurs.

Figure 1.9 : Exemple de AS interface


20

I.10.5. WorldFIP

Le réseau FIP ( Factory Instrumentation Protocol ) est l'aboutissement d'un travail de

développement franco-italien. La promotion et une part d'assistance technique de ce réseau

de terrain sont effectuées par l'organisation WorldFIP, qui cherche à diffuser

internationalement ce réseau. WorldFIP offre un réseau flexible au sein duquel aussi bien

la transmission périodique des données numériques d'entrées-sorties que des

communications apériodiques d'information de haut niveau (transmission de paramètres,

par exemple) sont possibles.

Un débit de transmission élevé est réalisable sur WorldFIP même sur de longues

distances. Les possibilités du trafic périodique font de WorldFIP un réseau déterministe qui

garantit la cohérence temporelle de l'information ; notons que des mécanismes sophistiqués

dits de « rafraîchissement » et de « promptitude » permettent de détecter la viabilité

d'information.

I.10.6. Interface SERCOS

SERCOS (Serial Real-time Communications System) est un standard de communication

international pour la commande de mouvement (CEI 61491). Ce réseau est destiné aux

communications série à grande vitesse de données en boucle fermée normalisées, en temps

réel, sur un câble en fibre optique immunisé aux bruits. Nous accompagnons SERCOS

avec des modules d'axe d'interface qui fournissent la connectivité des variateurs SERCOS

et la commande de l'automate ControlLogix.

Figure 1.10: interface SERCOS


21

I.10.7. FlexRay

FlexRay est un système de communication par bus, Standardisé par un consortium

regroupant des constructeurs automobiles (BMW, Daimler, Volkswagen, General Motors),

des équipementiers automobiles (Robert Bosch GmbH, Delphi, ...) et des fondeurs de

silicium (Freescale, NXP, ...), il a été développé pour les besoins spécifiques de

l'automobile ou de l'aéronautique. Le consortium s'est dissous en 2009. FlexRay est

désormais un ensemble de normes ISO, 17458-1 à 17458-5.

I.10.8. CAN (Control Area Network)

Créé pour les applications automobiles. Il sera étudié plus en détail par la suite.

(Dans le deuxième chapitre ) C'est un réseau multi-maîtres de type producteur-

consommateur. Chaque message envoyé sur le réseau est repéré par un identificateur.

Plusieurs stations peuvent lire le même message. L'accès au bus repose sur un arbitrage de

type CSMA/CR (Carrier Sense Multiple Access with Collision Resolution).

Comme il existe aussi autre réseaux : Bitbus, ARCNET, Modbus Plus, Modbus/jbus.. etc.

I.11. Avantages et inconvénients des réseaux industriels

I.11.1. Les avantages

Principal avantage : Réduction des coûts

- Réduction des coûts Initiaux

- Réduction massive du câblage : 1 seul câble en général pour tous les équipements

au lieu d'un par équipement .

- Possibilité de réutiliser le câblage analogique existant dans certains cas .

- Réduction du temps d'installation.

- Réduction du matériel nécessaire à l'installation.

- Réduction des coûts de Maintenance

- Complexité moindre donc moins de maintenance (fiabilité accrue).

- Maintenance plus aisée : temps de dépannage réduit, localisation des pannes

possibles grâce à des diagnostics en ligne («on line») donc à distance.

- Outils de test dédiés (analyseur...).

- Flexibilité pour l'extension du bus de terrain et pour les nouveaux raccordements.

- Performances Globales Accrues

- Précision : communications numériques : la donnée numérique transférée est sans

erreur de distorsion, de réflexion... contrairement à un signal analogique .


22

- Les données et mesures sont généralement disponibles à tous les équipements de

terrain.

- Communications possibles entre 2 équipements sans passer par le système de

supervision.

- La structure distribuée permet de faire résider des algorithmes de contrôle au

niveau de chaque équipement de terrain (chaque noeud).

- Accès à des variables multiples pour un nœud .

- Autres Avantages

- Interopérabilité importante grâce au souci de standardisation (système ouvert)

aux niveaux hard et soft.

- Choix pour l'utilisateur final : prix, performances, qualité...

- Le standard profite à l'utilisateur et non pas au vendeur.

- Possibilité de connexion d'équipements de différents fournisseurs respectant le

même standard.

- Echange de données par des mécanismes standard (protocoles).

- Modélisation objet des équipements et de leur fonctionnalité : modèle de bloc

fonctionnel aidant l'utilisateur à créer et superviser son bus de terrain.

I.11.2. Inconvénients

- Sécurité des informations.

- Demande une étude préalable pour des performances optimales et pour le choix

du réseau (Topologie, Vitesse, standard ou Propriétaire…….) .

- Coût direct du prix du Bus de Terrain.

Le réseau de terrain doit également s'intégrer avec les réseaux et langages de niveau

supérieur, dans le cadre du concept CIM , Nous avons choisi de présenter le réseau CAN

qui répond à ces contraintes industrielles et semblent bien adaptés pour interconnecter des

instruments intelligents dans le contexte de notre application .

I.12. Conclusion

nous avons pu expliquer quelques notions à savoir :

les réseaux informatiques et industriels

les déférents types de réseaux

quelque notions des réseaux de terrain

CHAPITRE II

Présentation

Du

Bus CAN


23

II.1. Introduction

Aujourd‟hui, l‟efficacité et la robustesse de protocole CAN l‟ont amène à être

utilisé dans de nombreuses applications industrielles, en particulier celles nécessitant un

débit important jusqu’ à 1 Mbits/s avec un très faible taux d’erreur.

Le CAN est aussi devenu un standard international reconnu par l‟ISO.

De nombreux contrôleurs CAN sont aujourd‟hui disponibles chez la plupart des fabricants,

qui proposent aussi des versions de leurs microcontrôleurs avec des contrôleurs CAN

intègres. De nombreux packages de développement existent aussi sur le marche.

II.2. Le Multiplexage

Le multiplexage consiste à faire circuler les informations entre divers équipements

électriques en diminuant le nombre de fils qui relient ces derniers entre eux. Cette

technique élimine le besoin de câbler des lignes dédiées pour chaque information à faire

transiter (connexion point-à-point). Le circuit électrique véhiculant les informations

provenant de tous les capteurs est appelé un BUS.

L'introduction des bus multiplexés (principalement le CAN) dans les véhicules avait

donc pour objectif de réduire la quantité de câbles dans les véhicules. Cela a surtout permis

l'explosion du nombre de calculateurs et capteurs distribués dans tout le véhicule et des

prestations correspondantes (baisse de consommation, dépollution, sécurité active/passive,

confort, détection des pannes…), tout en n'augmentant pas trop les longueurs câblées.

En effet, dès qu'un système (voiture, avion, réseau téléphonique…) atteint un certain

niveau de complexité, l'approche point-à-point devient impossible du fait de l'immense

quantité de câblage à installer et de son coût. [5]

II.3. Origines et utilisations du réseau CAN

Pour satisfaire des exigences de plus en plus importantes du client en matière de

sécurité et de confort, et pour se conformer aux lois de réduction de la pollution et de la

consommation de plus en plus drastiques, l‟industrie automobile a développé de nombreux

systèmes électroniques : systèmes anti-patinage, contrôle électronique du moteur et de l‟air

climatisé , fermeture centralisée des portes, etc. La complexité de ces systèmes et la

nécessité d‟échanger des données entre eux signifient de plus en plus de câbles. A côté du

coût très important de ce câblage, la place qui lui est nécessaire pouvait le rendre tout


24

simplement impossible à installer. Enfin, le nombre croissant de connexions et de câbles

posait de sérieux problèmes de fiabilité et de réparation.

La société Robert Bosch GmbH ( Allemagne ), un important équipementier

automobile, a fourni une solution dans les années 1980 avec le bus CAN ( Controller Area

Network ). L‟entreprise allemande a défini le protocole et a autorisé de nombreux autres

fabricants à développer des composants compatibles CAN.

CAN est pensé et réalisé pour répondre à des impératifs de robustesse, de fiabilité,

de simplicité et d‟économie liés aux productions de masse de l‟industrie automobile. CAN

possède donc toutes les qualités pour séduire beaucoup d‟industriels, soucieux de retrouver

dans leurs installations ou leurs équipements, la fiabilité, la robustesse et le faible coût d‟un

système de communication normalisé et éprouvé.

CAN est un réseau de communication série qui supporte efficacement le contrôle

en temps réel de systèmes distribués tels qu‟on peut en trouver dans les automobiles, et

ceci avec un très haut niveau d‟intégrité au niveau des données. Avec le protocole CAN,

les contrôleurs, capteurs et actionneurs communiquent entres eux à une vitesse pouvant

aller jusqu‟à 1 Mbits/s.

CAN est utilisé surtout pour la mise en réseau des organes de commande du

moteur, de la boîte à vitesse, de la suspension et des freins . Il s‟agit là d‟applications

temps réel et critiques. Pour la mise en réseau des organes dits de carrosserie et de confort

(commande des feux, des lève-vitres, de la climatisation, du verrouillage central, réglage

de sièges et de rétroviseur), les constructeurs peuvent faire appel à CAN ou à d‟autres

réseaux de terrain comme VAN ( Vehicul Area Network ).

Les contrôleurs CAN sont physiquement petits, peu coûteux et entièrement

intégrés. Ils sont utilisables à des débits importants, en temps réel et dans des

environnements difficiles. C‟est pourquoi les contrôleurs CAN ont été utilisés dans

d‟autres secteurs que l‟automobile et des applications utilisant CAN sont aujourd‟hui

disponibles dans l‟industrie, le bâtiment, l‟agriculture, la marine, le matériel médical, les

machines textiles, etc.

Les fondeurs de silicium, tels que Philips, Intel, NEC et Siemens, proposent

aujourd‟hui des composants et des contrôleurs CAN. La disponibilité d‟outils

d‟accompagnement tels que les analyseurs de réseau, les simulateurs de modules et les

générateurs d‟erreurs- facilitent le développement et la mise en œuvre des applications

basées sur CAN.


25

Le CiA (CAN in Automation), créé à l‟initiative des fournisseurs et utilisateurs

allemands, est un club chargé de promouvoir le transfert d‟une technologie automobile

vers le monde industriel. Le CiA regroupe notamment des utilisateurs, des fabricants de

semi-conducteurs, des fabricants d‟automates programmables ou de cartes industrielles.

Des services de niveau application (niveau 7 du modèle OSI) orientés systèmes

d‟automatismes industriels et s‟appuyant sur CAN sont disponibles aujourd‟hui :

Device Net (de Allen Bradley), SDS (de Honeywell), CAL (de Philips), etc. [6]

II.4. Protocole CAN

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é. La norme ISO

11898 spécifie un débit maximum de 1Mbits/s. La longueur maximum du bus est

déterminée par la charge capacitive et le débit (de 20 kbps sur 1 km à 1Mbps sur 40 m). La

structure du protocole du bus CAN possède implicitement les principales propriétés

suivantes :

Souplesse de configuration .

Fonctionnement multi maître .

Détections et signalisations d'erreurs .

Retransmission automatique des messages altérés .

Déconnexion automatique des nœuds défectueux .

Le protocole CAN ne couvre que 2 (ou 3) des 7 couches du modèle OSI : les couches

Physique et Liaison et éventuellement la couche Application.

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çue par tous les abonnés. Grâce à cet identificateur, les

nœuds, qui sont en permanence à l'écoute du réseau, reconnaissent et traitent les messages

qui les concernent . Elles ignorent simplement les autres.


26

Figure 2.1: Représentation du model

II.5. CAN dans le modèle ISO/OSI

CAN est un réseau compatible au modèle de référence ISO/OSI ( ISO : International

Standardization Organization, OSI : Open Systems Interconnection ). CAN a été

normalisé par l‟ISO dans les normes 11898 pour les applications à haute vitesse (jusqu‟à 1

Mb/s) et ISO 11519 pour les applications à basse vitesse (jusqu‟à 125 kb/s). Comme le

montre la Figure 2.2 . CAN (à l‟image de la quasi-totalité des réseaux locaux industriels) a

une architecture en trois couches ; les couches 3 à 6 du modèle OSI sont vides dans les

architectures fondées sur CAN. Les spécifications CAN s‟intéressent essentiellement aux

Couches MAC et physique.

II.5.1. La sous-couche MAC

Représente le noyau du protocole CAN. Elle a pour fonction de présenter les messages

reçus en provenance de la sous couche LLC et d'accepter les messages devant être transmis

vers la sous-couche LLC. Elle est responsable des fonctions suivantes :

La mise en trame du message.

L'arbitrage.

L'acquittement.

La détection des erreurs.

La signalisation des erreurs.


27

II.5.2. La sous-couche LLC

S'occupe quant à elle :

Du filtrage des messages.

De la notification de surcharge (overload).

De la procédure de recouvrement des erreurs.

COUCHE APPLICATION

COUCHE LIAISON DE DONNEES

Contrôle de liaison logique

Filtrage d‟acceptation de trames

Notification de surcharge

Gestion de recouvrement d‟erreur

Contrôle d„accès au medium (MAC)

Encapsulation / décapsidation de données

Codage de trames (stuffing / destuffing)

Gestion d‟accès au medium

détection d‟erreur

Signalisation d‟erreur

Acquittement

Sérialisation / désérialisation

COUCHE PHYSIQUE

Signalisation physique

Codage et décodage de bit

Timing de bit

Synchronisation

Attachement au médium

Caractéristique de transceiver

Interface dépendant du médium

Connecteurs

A spécifier

l’utilisateur

Spécification du

Réseau CAN

Implanté en

logiciel

Embarqué ou non

Implanté dans

le silicium

BUS

Figure 2.2 : Architecture CAN.

II.5.3. La couche physique

Définit le signal transmis et a pour rôle d'assurer le transfert physique des bits entre les

différents nœuds en accord avec toutes les propriétés (électriques et électroniques) du

système. Cette couche s'occupe :

De gérer la représentation du bit (codage, timing. . . ).


28

De gérer la synchronisation bit.

De définir les niveaux électriques des signaux.

De définir le support de transmission.

Remarque :

La couche 7 (Application) peut être implémentée sous forme d'un protocole

supplémentaire ( CANOpen par exemple ).

II.6. Caractéristiques Physiques Du Bus CAN

Généralement, CAN utilise comme support de transmission une paire torsadée

blindée ou non blindée. Les nœuds sont reliés entre eux par l‟intermédiaire d‟un bus série

équipé de terminateurs de lignes (résistances de terminaison). Les interfaces physiques sont

de type différentiel en mode tension, proche du principe de la liaison RS485. La Figure 2.3

montre un exemple de raccordement au bus CAN.La norme CAN ne spécifie pas de

couche physique unique. Différentes implémentations sont donc possibles : fibre optique,

câble coaxial, infrarouge, etc. [7]

Figure 2.3: Topologie en bus du réseau CAN

Le CAN est un bus de terrain, soumis à des parasites importants. La transmission en paire

différentielle permet de s'affranchir de ces problèmes. Les montages différentiels ont en

plus un fort taux de réjection en mode commun CMRR. Pour les niveaux physiques sur le

bus, il est important de distinguer les deux types de transmission possibles :

transmission en bus CAN low speed,

transmission en bus CAN high speed.


29

Le tableau ci-dessous résume les principales différences entre les deux types de bus

notamment sur les débits supportés.

Parameters CAN low speed CAN high speed

Débit 125 kb/s 125 kb/s à 1 Mb/s

Nombre de nœuds sur le bus 2 à 20 2 à 30

Courant de sortie (mode émission) > 1 mA sur 2,2 kΩ 25 à 50 mA sur 60Ω

Niveau dominant CAN H = 4V

CAN L = 1V

VCAN H - VCAN L =

2V

Niveau récessif CAN H = 1,75V

CAN L = 3,25V

VCAN H - VCAN L =

2,5V

Caractéristique du câble 30 pF entre les câbles

de ligne

2*120Ω

Tensions d’alimentation 5V 5V

Tableau 2.1 : Les 2 types de bus CAN

Figure 2.4 : Niveaux de tension du bus CAN low speed

a- Cas de la norme ISO 11519 (basse vitesse)


30

Figure 2.5: Niveaux de tension du bus CAN high speed

b- Cas de la norme ISO 11898 (haute vitesse)

Parmi les multiples techniques de codage existantes (NRZ, NRZI, Manchester simple,

Manchester différentiel, etc.), CAN a retenu le code NRZ (Non Return to Zero) pour sa

simplicité. Avec le code NRZ, la valeur du signal reste constante pendant toute la durée

d‟un bit. Dans la norme ISO 11898 (haute vitesse), les noeuds détectent un bit récessif si la

différence de tension entre les lignes CAN_H et CAN_L est inférieure ou égale à 0,5 V. Ils

détectent un bit dominant si cette différence est supérieure ou égale à 0,9 V. La tension

nominale pour le bit dominant est 3,5 V pour la ligne CAN_H et 1,5 V pour la ligne

CAN_L. Dans la norme ISO 11519 (basse vitesse), les noeuds détectent un bit récessif si la

différence de tension entre CAN_L et CAN_H est de l‟ordre de 1,5 V. Ils détectent un bit

dominant si cette différence est de l‟ordre de - 3 V.

II.7. Définitions des règles de fonctionnement [5]

II.7.1. Nœud

Sous-ensemble relié à un réseau de communication et capable de communiquer sur

le réseau selon un protocole de communication ( ici le protocole CAN ). Chaque nœud peut

détecter des erreurs sur un message qui ne lui est pas destiné et en informer les autres

nœuds.


31

II.7.2. Valeurs du bus

Le bus peut avoir l'une des deux valeurs logiques complémentaires définies, non

pas en 0 et 1 comme d'habitude, mais sous la forme de bit nommé Dominant ou Récessif.

II.7.3. Message

Chaque information est véhiculée sur le bus à l'aide d'un message (trame de bits) de

format défini mais de longueur variable et limitée. Dès que le bus est libre, n'importe quel

nœud relié au réseau peut émettre un nouveau message.

II.7.4. Routage des informations

Des nœuds peuvent être ajoutés au réseau sans qu'il n'y ait rien à modifier tant au

niveau logiciel que matériel. Chaque message possède un identificateur (identifier) qui

n'indique pas la destination du message mais la signification des données du message.

Ainsi tous les nœuds reçoivent le message, et chacun est capable de savoir grâce au

système de filtrage de message si ce dernier lui est destiné ou non.

II.7.5. Trame de données et de requête

Une trame de données transporte, comme son nom l'indique, des données. Une

trame de requête est émise par un nœud désirant recevoir une trame de données (dans ce

cas l'identificateur est le même pour les deux trames).

II.7.6. Débit (bit/s)

Le débit peut varier entre différents systèmes, mais il doit être fixe et uniforme au

sein d'un même système.

II.7.7. Priorités

En cas de demandes de prise du bus simultanées les identificateurs de chaque message

permettent aussi de définir quel message est prioritaire sur tel autre.

II.7.8. Demande d’une trame de données

un nœud peut demander à un autre nœud d‟envoyer une trame de données, et pour

cela il envoie lui-même une trame de requête. La trame de données correspondant à la

trame de requête initiale possède le même identificateur.


32

II.7.9. Fonctionnement multi-maître

Lorsque le bus est libre, chaque nœud peut décider d'envoyer un message. Seul le

message de plus haute priorité prend possession du bus.

II.7.10. Arbitrage

Le problème de l'arbitrage résulte du fonctionnement multi maître. Si deux nœuds

ou plus tentent d'émettre un message sur un bus libre il faut régler les confits d'accès. On

effectué alors un arbitrage bit à bit non destructif tout au long du contenu de

l'identificateur. Ce mécanisme garantit qu'il n'y aura ni perte de temps, ni perte

d'informations. Dans le cas de deux identificateurs des trames de requête et de données

identiques, la trame de données gagne le bus. Lorsqu'un bit récessif est envoyé et qu'un bit

dominant est observé sur le bus, l'unité considérée perd l'arbitrage, doit se taire et ne plus

envoyer aucun bit.

II.7.11. Canal de liaison simple

Le bus consiste en un simple canal bidirectionnel qui transporte les bits. À partir

des données transportées, il est possible de récupérer des informations de

resynchronisation.

II.7.12. Acquittement

Tous les récepteurs vérifient la validité d'un message reçu, et dans le cas d'un

message correct ils doivent acquitter en émettant un flag.

II.7.13. Sécurité de transmission

Dans le but d'obtenir la plus grande sécurité lors de transferts sur le bus, des

dispositifs de signalisation, de détection d'erreurs, et d'autotests ont été implémentés sur

chaque nœud d'un réseau CAN. On dispose ainsi d'un monitoring bus (vérification du bit

émis sur le bus), d'un CRC ( Cyclic Redundancy Check ), d'une procédure de contrôle de

l'architecture du message et d'une méthode de BitStufing.


33

II.7.14. Signalement des erreurs et temps de recouvrement des erreurs

Tous les messages entachés d'erreur(s) sont signalés au niveau de chaque nœud par

un flag. Les messages erronés ne sont pas pris en compte, et sont retransmis

automatiquement.

II.7.15. Erreurs de confinement

un nœud CAN doit être capable de faire les distinctions entre des perturbations de

courtes durées et des dysfonctionnements permanents. Les nœuds considérés comme

défectueux doivent passer en mode switched off en se déconnectant (électriquement) du

réseau.

II.7.16. Points de connexion

la liaison de communication série CAN est un bus sur lequel un nombre important

d‟unités peuvent être raccordées. En pratique le nombre total d‟unités sera déterminé par

les temps de retard (dus aux phénomènes de propagation) et/ou les valeurs des charges

électriques que ces unités présentent sur le bus.

II.7.17. Mode Sleep (sommeil) et Mode Wake up (réveil)

Afin de réduire la consommation d'énergie, chaque élément CAN peut se mettre en

Sleep mode. Dans ce mode il n'y a aucune activité interne au nœud CAN considéré et ses

drivers sont déconnectés du bus. La reprise de fonctionnement (mode Wake up) s'effectue

lorsqu'il y a une activité sur le bus ou par décision interne à l'élément CAN.

II.7.18. Méthode de BitStufing

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 nœuds. Cette technique est

uniquement active sur les champs de SOF, d'arbitrage, de contrôle, de CRC (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. [7]


34

Figure 2.6 : Technique de Bit-Stuffing

II.8. Protocole de niveau MAC

II.8.1. Identificateurs

Les trames de données (c‟est-à-dire les trames qui contiennent les messages

destinés à la couche application) transmises par un nœud sur le bus ne contiennent ni

adresse d‟un nœud destinataire, ni adresse du nœud source. Elles contiennent des

identificateurs d‟objets. Il y a un identificateur par trame. Par exemple, l‟identificateur

100 désigne un angle de volant d‟automobile et l‟identificateur 101 désigne la température

du moteur. Un identificateur est unique et spécifie, sans ambiguïté, l‟information (ou

l‟objet) qu‟une trame transporte. Les identificateurs sont donc attribués (par le concepteur

d‟application) aux objets selon l‟urgence et l‟importance de ces objets pour l‟ensemble de

l‟application. En général, les objets associés aux grandeurs issues des capteurs ou à

destination des actionneurs ont des identificateurs avec des valeurs faibles pour leur

permettre d‟être échangés en priorité en cas de conflit d‟accès au bus . En d‟autres termes,

l‟identificateur contenu dans une trame spécifie la priorité de cette trame en cas de conflit

d‟accès. Plus la valeur de l‟identificateur est faible, plus la trame est prioritaire.

Chaque nœud relié au réseau est producteur des valeurs d‟un ou de plusieurs objets

identifiés ou consommateur des valeurs d‟un ou de plusieurs objets identifiés. Un nœud

peut être à la fois producteur et consommateur de valeurs d‟objets identifiés.

Grâce à l‟identificateur contenu dans une trame, les nœuds connectés au réseau, et

qui sont en permanence à l‟écoute du bus, reconnaissent les objets qui les intéressent (ceux

qu‟ils consomment ou qu‟ils produisent) et traitent les trames ; tout nœud fait une copie de

la trame courante (s‟il est consommateur de l‟objet diffusé) ou envoie sa valeur (s‟il est


35

producteur de l‟objet diffusé). C‟est au niveau de la sous-couche Contrôle de liaison

logique que les messages reçus sont filtrés.

Les identificateurs sont codés sur 11 bits en version standard (CAN 2.0.A) et sur 29

bits en version étendue (CAN 2.0.B).

II.8.2. Arbitrage bit à bit

Dans un système typique, certains paramètres vont changer plus rapidement que

d‟autres. Ce sera par exemple la vitesse d‟un moteur d‟automobile, tandis qu‟un paramètre

plus lent pourra être la température de l‟habitacle. Il est donc naturel que les paramètres qui

varient le plus soient transmis le plus souvent et par conséquent doivent avoir une plus

grande priorité. Dans les applications temps réel, ceci nécessite non seulement une vitesse

de transmission importante, mais aussi un mécanisme d‟allocation du bus efficace qui soit

capable de traiter les cas où deux ou plusieurs nœuds cherchent à transmettre en même

temps. C‟est la raison pour laquelle, CAN intègre une méthode simple et efficace pour

arbitrer l‟accès au bus. Cette méthode est appelée CSMA/CR (“Carrier Sense, Multiple

Access with Collision Résolution”) et a la capacité de l‟arbitrage non destructif (dit “Non-

Destructive Bitwise Arbitration”).

Les caractéristiques électriques définies par la norme CAN, font que en cas de

conflit d‟accès (c‟est-à-dire quand deux ou plusieurs nœuds commencent à transmettre en

même temps), la valeur 0 écrase la valeur 1. Lors de l‟arbitrage, dès qu‟un nœud émetteur

détecte un bit à 0 sur le bus, alors qu‟il émet un bit à 1, il abandonne sa tentative d‟accès au

bus. L‟un après l‟autre, les nœuds en compétition abandonnent leur transmission au profit

du nœud le plus prioritaire (c‟est-à-dire celui qui transmet la trame ayant l‟identificateur le

plus petit). Tout se passe donc comme si la trame de plus haute priorité était la seule à être

transmise. Lorsqu‟un nœud perd l‟arbitrage, il devient automatiquement un récepteur de la

trame en cours de transmission. Les nœuds qui abandonnent tentent leur transmission plus

tard une fois que le nœud le plus prioritaire en cours termine sa transmission et après un

silence sur le bus équivalent à au moins 3 fois le temps de transmission d‟un bit.

Comme l‟arbitrage d‟accès se fait sur la base des identificateurs contenus dans les

trames, le choix de ces identificateurs est important pour le bon fonctionnement d‟une

application. Dans l‟exemple illustré par la Figure 2.7, trois nœuds tentent de transmettre en

même temps. Les deux premiers bits des identificateurs transmis sont identiques pour les

trois nœuds, par conséquent les nœuds ne peuvent être départagés qu‟à partir du troisième

bit. Le troisième bit vaut 1, pour le nœud 2, et vaut 0, pour les nœuds 1 et 3. Par

conséquent, le nœud 2 abandonne sa transmission au troisième bit. Ensuite, après un bit à 1


36

pour les deux nœuds restants, le nœud 1 abandonne, au cinquième bit, au profit du nœud 3

qui poursuit la transmission de sa trame jusqu‟à sa fin ( le nœud 3 a gagné la compétition

d‟accès au bus ). On dit aussi que CAN est un réseau multi-maîtres, car contrairement au

réseau FIP, il n‟y a pas de nœud privilégié (ou central ) qui attribue le droit d‟accès au

support de transmission. Chaque nœud a le droit d‟accéder au support dès qu‟il détecte

qu‟il est libre sans attendre l‟autorisation d‟un quiconque autre nœud. [9]

II.8.3. Types d’échanges d’objets identifiés

Selon les besoins de l‟application, les objets identifiés peuvent être échangés par les

nœuds de manière périodique, de manière sporadique ou sur demande d‟un consommateur.

Il faut noter que la transmission d‟une trame prend un certain temps (qui dépend

principalement du débit du réseau) et que des nœuds sont contraints d‟attendre avant de

voir leurs tentatives de transmission réussir. Pour un fonctionnement de l‟application sans

violation des contraintes de temps, un calcul minutieux doit être fait pour montrer que les

temps d‟attente avant transmission n‟affectent pas la validité des données échangées. Par

exemple, le temps d‟attente d‟une trame contenant la valeur d‟une température qui doit être

échangée toutes les P millisecondes doit être inférieur à P millisecondes. La phase pendant

laquelle le développeur d‟une application temps réel doit vérifier a priori le bon

fonctionnement de son application est dite phase d‟analyse d‟ordonnançabilité . Cette

phase est d‟une importance capitale pour les applications critiques (comme c‟est le cas des

applications embarquées dans l‟automobile). [7]

Figure 2.7 : Principe d’arbitrage du réseau CAN.


37

II.9. Types de trames

Il existe quatre types de trames pouvant être transmises sur un bus CAN :

- Trames de données : elles sont utilisées pour transporter des données (messages) de

l‟application (ou valeurs d‟objets) sur le bus. C‟est le producteur d‟un identificateur qui

émet des trames de données associées à cet identificateur.

- Trames de requête distante : elles sont utilisées par un noeud (un consommateur)

pour demander la transmission de trames de données par d‟autres noeuds (les

producteurs) avec le même identificateur. Le bit RTR (Remote Transmission Request)

permet de distinguer les trames de données des trames de requête. Le bit RTR est égal

à 0 pour une trame de données et à 1 pour une trame de requête. On notera que les

trames de données sont prioritaires par rapport aux trames de requête : quand un

producteur et un consommateur d‟un même objet entrent en conflit, c‟est la trame

émise par le producteur qui s‟impose, ce qui est normal puisque la trame du producteur

répond à la requête faite par le consommateur.

- Trames d’erreur : elles sont transmises par un noeud ayant détecté une erreur. Leur

format et utilisation seront détaillés par la suite .

- Trame de surcharge : elles sont utilisées pour demander un délai entre deux trames de

données ou de requête successives Les trames de données ou de requête sont séparées

des trames qui les précèdent (de quelque type qu‟elles soient) par un temps dit

intertrame (ce temps doit correspondre à au moins le temps de 3 bits). Les trames

d‟erreur ou de surcharge ne sont pas séparées des autres trames par un intertame.

II.9.1. Trame De Données

Une trame de données se décompose en 7 champs différents (Figure 2.8 ) :

le début de trame SOF (Start Of Frame), 1 bit dominant.

le champ d‟arbitrage, 12 bits.

le champ de contrôle, 6 bits.

le champ de données, 0 à 64 bits.

le champ de CRC ( Cyclic Redundancy Code ), 16 bits.

le champ d‟acquittement ( Acknoledge ), 2 bits.

le champ de fin de trame EOF ( End Of Frame ), 7 bits récessifs.


38

Figure 2.8: Format de la tram CAN.

Le début de trame n‟est effectif que si le bus était précédemment au repos. Tous les nœuds

du réseau doivent se resynchroniser sur le bit de SOF.

a- Champ d’arbitrage

Dans une trame standard, le champ d‟arbitrage est composé des 11 bits de

l‟identificateur ( Figure 2.9 ) et d‟un bit de RTR ( Remote Transmission Request ) qui est

dominant pour une trame de données et récessif pour une trame de requête.

On ne détaillera pas ici le champ d‟arbitrage pour une trame. Ceux qui désire voir plus de

détails sur ce point peuvent faire appel à la norme BOSCH. Pour l‟identificateur les bits

sont transmis dans l‟ordre, de ID_10 à ID_0 ( le moins significatif est ID_0 ). Par ailleurs

les 7 bits les plus significatifs (de ID_10 à ID_4) ne doivent pas tous être récessifs. Pour

des raisons de compatibilité avec des anciens circuits, les 4 derniers bits de l‟identificateur

( ID_3 à ID_0 ) ne sont pas utilisés, ce qui réduit le nombre de combinaisons possibles.

Figure 2.9: Champ d’arbitrage dans le bus CAN.

b- Champ de contrôle

Le champ de contrôle est composé de 6 bits ( Figure 2.10 ). Les deux premiers

( r1 dans une trame standard, et r0 ) sont des bits de réserve et leur rôle est d‟assurer des

compatibilités futures ascendantes ( par exemple avec les trames étendues ). Les quatre

derniers bits permettent de déterminer le nombre d‟octets de données contenus dans le


39

champ de données pour une trame de données ou bien le nombre d‟octets de données dont

a besoin un nœud du réseau lors d‟une trame de requête. Le nombre d‟octets de données ne

peut pas excéder la valeur de 8.

Taille des données en

octets

DLC (Data Length Code)

DLC3 DLC3 DLC3 DLC3

0 D D D D

1 D D D R

2 D D R D

3 D D R R

4 D R D D

5 D R D R

6 D R R D

7 D R R R

8 R D D D

D : Bit Dominant , R : Bit Récessif.

Tableau 2.2 : Codage des bits DLC suivant la taille des données en octets.

Figure 2.10: Champ de contrôle dans le bus CAN.

c- Champ de données

Le champ de données a une longueur qui peut varier de 0 à 64 bits (0 à 8 octets).

Cette longueur a été déterminée lors de l‟analyse du champ de contrôle. Dans le cas d‟une

trame de requête, le champ de données est vide.


40

d- Champ de CRC

Le champ de CRC est composé de 16 bits (Figure 2.11). La séquence CRC

calculée est contenue dans les 15 premiers bits tandis que le dernier bit est un délimiteur de

fin de champ de CRC (bit toujours récessif).

Ce champ de CRC permet de s‟assurer de la validité du message transmis, et tous

les récepteurs doivent s‟astreindre à ce procédé de vérification. Seuls les champs de SOF,

d‟arbitrage, de contrôle et de données sont utilisés pour le calcul de la séquence de CRC.

Les codes utilisés par les contrôleurs de bus CAN sont des codes linéaires de. De fait la

longueur maximale du début de trame ne doit pas excéder 215 bits pour une séquence de

CRC de 15 bits. Le nombre maximal d‟erreurs détectées dans la trame est de 5.

La séquence de CRC est calculée par la procédure suivante :

le flot de bits ( hors Bit-Stuffing ), constitué des bits depuis le début de la trame

jusqu‟à la fin du champ de données ( pour une trame de données ) ou bien la fin du

champ de contrôle ( pour une trame de requête ) est interprétée comme un

polynôme f(x) avec des coefficients 0 et 1 affectés à la présence, effective ou non,

de chaque bit. Le polynôme obtenu est alors multiplié par x15

complété pour l'ajout

du mot de CRC.

le polynôme ainsi formé est divisé ( modulo 2 ) par le polynôme générateur :

1)( 348101415 xxxxxxxg

La chaîne de bits correspondante à ce polynôme est : 1100010110011001.

Le reste de la division du polynôme f(x) par le polynôme générateur g(x) constitue

la séquence CRC de 15 bits.

Figure 2.11: Champ de CRC dans le bus CAN.

La réalisation du module de calcul de CRC est particulièrement aisée à l‟aide de registres à

décalages. La norme BOSCH propose le programme informatique correspondant à


41

l‟algorithme précédemment décrit :

CRC_REG=0 ;

REPEAT

CRC_NXT_BIT = (NXT_BIT) XOR (CRC_REG(14)) ;

CRC_REG(14:1) = CRC_REG(13:0) ;

CRC_REG(0) = 0 ;

IF CRC_NXT_BIT THEN

CRC_REG(14:0) = CRC_REG(14:0) XOR (4599hex) ;

ENDIF

UNTIL(CRC SEQUENCE starts or there is an ERROR condition)

e- Champ d’acquittement

Le champ d‟acquittement possède 2 bits ( Figure 2.12 ). La station émettrice de la

trame laisse le bus libre pendant 2 coups d‟horloge (ce qui correspond à l‟émission de deux

bits récessifs) et elle passe en mode réception pendant le premier coup d‟horloge.

Le premier bit correspond à l‟acquittement par l‟ensemble des nœuds ayant reçu le

message. Si aucune erreur n‟a été détectée par un nœud (après calcul du CRC), ce dernier

émet un bit dominant sinon il émet une trame d‟erreur. La station émettrice du message

originel doit alors être capable de réagir en fonction de l‟émission d‟un bit dominant ou

non par les autres stations sur le premier bit du champ d‟acquittement. Le second bit est un

bit délimiteur d‟acquittement qui doit toujours être récessif.

Figure 2.12: Champ d’acquittement dans le bus CAN.


42

f- Champ de fin de trame

Ce champ de fin de trame est constitué de 7 bits récessifs,ce qui déroge à la règle de

Bit-Stuffing. Ce champ étant fixe, il est nécessaire de désactiver le codage ( à l‟émission )

et le décodage ( à la réception ) suivant la règle du Bit-Stuffing.

II.9.2. Trame De Requête

Une trame de requête est constituée de la même manière qu‟une trame de données

sauf que le champ de données est vide ( Figure 2.13 ).

Dans le champ d‟arbitrage, le bit de RTR est récessif. Par conséquent si deux

nœuds émettent chacun une trame possédant le même identificateur (c‟est à dire qu‟un

nœud émet une trame de données et l‟autre une trame de requête), l‟arbitrage sur le bit de

RTR va donner la priorité à la trame de données.

Si un nœud a besoin d‟un certain nombre de données, il va émettre une trame de

requête dès que le bus sera libre en prenant soin d‟indiquer dans le champ de contrôle le

nombre d‟octets de données dont il a besoin.

Les règles de construction des autres divers champs d‟une trame de requête sont les

mêmes que dans le cas d‟une trame de données. [7]

Figure 2.13: Format de la tram de Requête .


43

II.9.3. Les trames d’erreurs

La trame d‟erreur est constituée de deux champs principaux :

- le drapeau d‟erreur,

- le délimiteur de champ.

Figure 2.14 montre de quelle manière est construite la trame d‟erreur.

Figure 2.14 : Construction de la trame d'erreur

Le champ des drapeaux peut être constitué de deux sortes de drapeaux :

- les drapeaux d‟erreur active (Active Error Flag),

- les drapeaux d‟erreur passive (Passive Error Flag).

a- La trame d’erreur active

Elle est formée de six bits dominant consécutifs pour le champ de drapeau suivi de

huit bits récessifs pour le délimiteur. Par construction, la trame d‟erreur brise la règle du

Bit-Stuffing. Les autres récepteurs vont donc se mettre à émettre des trames d‟erreurs

actives (s‟ils sont en mode d‟erreur active) à la fin du drapeau de la première station qui a

émis la trame d‟erreur. Toutes les stations vont donc émettre à tour de rôle la trame

d‟erreur. La dernière station aura en charge d‟émettre le champ d’Error Délimiter, les

autres champs ayant été remplacés par les bits dominants des drapeaux émis.

Figure 2.15: Trame d'erreur active


44

b- La trame d’erreur passive

La trame est formée de six bits récessifs pour le drapeau et de huit bits récessifs

pour le délimiteur. Le champ du drapeau brise de nouveau la règle du Bit-Stuffing et les

émetteurs envoient à tour de rôle le Passive Error Flag (s‟ils sont en mode d‟erreur

passive). Mais une trame d’Active Error Flag reste prioritaire sur une trame de Passive

Error Flag si elles sont envoyées en même temps. En effet, Les bits dominants de l’Active

Error Flag remplacent les bits récessifs du Passive Error Flag. La fin de la trame quant à

elle ne change pas puisqu‟elle est formée dans les deux cas de huit bits récessifs.

Figure 2.16 : Trame d'erreur passive

II.9.3. 1. Traitement Des Erreurs

Lors de l‟émission d‟une trame sur le bus, des erreurs de transmission peuvent

venir perturber le bon fonctionnement des différents utilisateurs du bus. L‟erreur peut venir

d‟un nœud, et empêcher le réseau de fonctionner correctement. Pour cela, des méthodes de

détection d‟erreurs de transmissions sont prévues par le protocole CAN, Les différents

types d‟erreurs sont :

a- Le Bit Error

Chaque fois qu‟un émetteur envoie un bit sur le bus, il vérifie en même temps si le niveau

émis sur le bus correspond à celui qu‟il désire envoyer en faisant une surveillance du bus.

Si le niveau ne correspond pas, il le signale par un Bit Error. Cependant, le Bit Error n‟est

pas signalé dans les cas suivants :

Aucune erreur de Bit Error n‟est signalée lorsqu‟un bit dominant est envoyé dans le champ

d‟arbitrage à la place d‟un bit récessif. Le bit dominant signifie simplement une perte

d‟arbitrage.

De même, pour un bit dominant lors de l’acknowledge slot, à la place d‟un bit récessif.


45

Un émetteur envoyant un flag d‟erreur passive (bit récessif) et recevant un bit dominant, ne

doit pas signaler un Bit Error.

b- L’erreur de Stuffing (Stuff Error)

Une erreur de Stuffing est détectée à chaque fois qu‟il y a 6 bits ou plus consécutifs

de même signe sur le bus. Cependant, une erreur de Stuffing ne doit être signalée que dans

les champs d‟identificateurs, de commande et de CRC. La règle du Bit-Stuffing ne

s‟appliquant plus après la fin du CRC.En aucun cas, une erreur de Bit-Stuffing ne doit être

signalée dans le champ de fin de trame ou dans le champ d‟acquittement.

c- L’erreur de Cyclic Redundancy Code (CRC Error)

Si la valeur du CRC calculée par le récepteur est différente de celle envoyée par

l‟émetteur, il y a erreur de CRC (CRC Error).

d- L’erreur d’Acknowledge Délimiter

Une erreur d’Acknowledge Delimiter est signalée lorsque le récepteur n‟observe pas

un bit récessif lors du champ de Acknowledge Delimiter. Il en est de même pour le CRC

Délimiter.

e- L’erreur de Slot Acknowledge (Acknowledgment Error)

Une erreur de Slot Acknowledge est signalée par l‟émetteur s‟il ne lit pas un bit

dominant lors du champ de slot acknowledge.

La Figure 2.14 résume les différents types d‟erreurs et leur validité suivant l‟endroit où

l‟on se trouve dans la trame.

Figure 2.17: Sources d'erreur dans la trame CAN


46

II.9.3. 2. 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.

II.9.3. 3. Les modes d’erreurs

a- Mode d’erreur active

Le gestionnaire de protocole est en mode d‟erreur active si le compteur de réception et le

compteur d‟émission ont une valeur inférieure à 127. Dans ce mode, le noeud émet des

trames d‟erreurs actives (Active Error Flag).

b- Mode d’erreur passive

Le gestionnaire de protocole est en mode d‟erreur passive si le compteur de réception ou le

compteur d‟émission est supérieur ou égal à 128 et inférieur à 255. Dans ce mode, le noeud

émet des trames d‟erreurs passives (Passive Error Flag).

c- Mode Bus Off

Le gestionnaire de protocole est en mode Bus Off si la valeur d'un des deux compteurs est

> 255. Le noeud est alors totalement déconnecté du bus (les drivers de lignes ne sont plus

actifs). Il sort de cet état de Bus Off avoir reçu 127 trames de onze bits récessifs.

II.9.3. 4. La gestion des modes d’erreur [9]

Suivant le nombre d‟erreur qu‟un nœud comptabilise, l‟état du mode de ce nœud

peut différer. Un compteur mémorise le nombre d‟erreur rencontré 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 nœud se met en Bus Off et se déconnecte du bus. Il ne reçoit ni émet à ce

moment là aucune trame circulant sur le bus CAN.Le passage dans les différents modes

s‟effectue suivant la valeur des compteurs comme le montre la Figure 2.18.


47

Error

active

Bus

Off

Error

Passive

Reset

128

128

TEC

REC

127

127

TEC

REC

255TEC

TEC : TRANSMITER ERROR CONTER

REC: RECEIVER ERROR CONTER

128 OCCURRENCES

DE 11 BITS RECESSIFS

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

II.9.3. 5. Les règles de passages dans les modes

L‟incrémentation et la décrémentation des compteurs ne se fait pas avec le même

rapport. En effet, le compteur s‟incrémente plus vite lorsqu'il y a une erreur qu‟il ne se

décrémente lorsque la trame reçue est correcte.

Les règles d‟incrémentation et de décrémentation des compteurs sont les suivantes :

a- Le compteur de réception est incrémenté de 1 si

- un récepteur détecte une erreur, le compteur d‟erreur de réception sera incrémenté de 1,

sauf si l‟erreur est un Bit Error durant un flag d‟erreur active ou un flag de surcharge.

b- Le compteur de réception est incrémenté de 8 si

- un récepteur reçoit un bit dominant juste après un flag d‟erreur.

- un récepteur voit un Bit Error tandis qu‟il reçoit un flag d‟erreur active ou un flag

de surcharge.

c- Le compteur de transmission est incrémenté de 8 si

un émetteur envoie un flag d‟erreur, son compteur d‟émission s‟incrémente de 8

sauf si l‟émetteur est en erreur passive et voit un Acknowledgment Error (il ne détecte

aucun bit dominant sur le champ d‟acknowledge ou lors de l‟envoie de la trame d‟erreur

passive) et également si l‟émetteur envoie un flag d‟erreur lors d‟une erreur de Bit-Stuffing

durant la période d‟arbitrage (détection d‟un bit dominant au lieu d‟un bit récessif situé

après le RTR).

- un émetteur voit un Bit Error tandis qu‟il émet un flag d‟erreur active ou un flag


48

de surcharge.

d- Les compteurs d’émission et de réception s’incrémentent de 8 si

Chaque nœud recevant sept bits dominants consécutifs après réception d’un Active

Error Flag, d‟un Passive Error Flag ou d‟un Overload Flag. Après détection de

quatorzième bit dominant consécutif (pour l’Active Error Flag ou l’Overload Flag) ou du

huitième bit dominant consécutif suivant le Passive Error Flag, et après toutes les suites de

huit bits dominants consécutifs.

e- Le compteur de réception est décrémenté de 1 si

le récepteur reçoit une trame sans erreur (jusqu‟au champ d’Acknowledge Slot) et

si la valeur du compteur est comprise entre 1 et 127. Si le compteur est à 0, sa valeur ne

change pas (pas d‟incrémentation). S'il est supérieur à 127, sa valeur est ramenée entre 119

et 127.

f- Le compteur d’émission est décrémenté de 1 si

la transmission d‟une trame se déroule sans erreur (jusqu‟au champ d’Acknowledge Slot).

Si la valeur du compteur est à 0, le compteur ne s‟incrémente pas.

II.9.4. Trame de surcharge

La trame de surcharge indique aux autres noeuds qu‟une station est surchargée. Elle est

formée de deux champs :

- le drapeau de surcharge (Overload Frame) avec six bits dominants,

- le délimiteur de surcharge (Overload Delimiter) avec huit bits récessifs.

La Figure 2. 19 représente la trame.

Figure 2. 19 : Trame de surcharge

Une trame de surcharge est émise sur le bus si :

- un bit dominant est détecté durant la période d‟intertrame.


49

- un récepteur n‟est pas prêt pour la réception d‟une nouvelle trame de donnée ou

de requête (retard sur le traitement des informations circulant sur le bus).

Dès qu‟une trame de surcharge est émise, les autres noeuds voient sur le bus une suite de

six bits dominants qui ne respectent pas la règle du Bit-Stuffing. Ils émettent à leur tour

une trame de surcharge. Seulement deux trames de surcharges consécutives sont autorisées

sur le bus (pas plus de 12 bits dominants consécutifs émis sur le bus).

II.9.4.1. Période d’intertrame

Elle sépare les trames de données ou de requêtes entre elles. Il s‟agit d‟une suite de

plusieurs bits récessifs.

a- Le champ d’intermission

Le champ d‟intermission est une suite de 3 bits récessifs consécutifs. Durant la

période d‟intermission, l‟émission de trame n‟est pas autorisée. Les gestionnaires de

protocole ne sont autorisés à signaler que les conditions de surcharge.

b- Le champ de Bus Idle

Le champ de Bus Idle est celui du bus quand il est au repos. Le niveau de repos est

le niveau récessif et aucune trame ne circule sur le bus.

c- Le champ de suspension de transmission

Le champ de suspension de transmission est émis par un noeud lorsque celui-ci envoie une

trame d‟erreur passive ,La Figure 2.20 représente les différents champs.

Figure 2.20 : Période d'intertrame

d- Autres modes

Pour la gestion de l‟énergie sur le bus, les drivers de ligne peuvent être désactivés lorsqu'il

n‟y a plus de trames sur le bus. Pour activer ces drivers sur le bus, la station devra observer

11 bits récessifs à la suite. La procédure ainsi décrite est la procédure de réveil appelée

Wake-up. Un identificateur a été réservé à cette fonction pour éviter de perdre un trop

grand nombre de trames lors de la reconnexion sur le bus.


50

Lors des démarrages d‟une station sur le bus, le Start-up se charge de connecter les drivers

de lignes et d‟observer la séquence voulue pour commencer à émettre ou à recevoir des

trames du bus.

II.10. Codage de ligne

Dans le protocole CAN le code de ligne (en bande de base) choisi pour la

transmission des données sur le bus est le code NRZ (Non Return to Zero). Figure 2.21

donne un exemple de codage.

11 0 1 0 1 0 1

dominant

récessif

Figure 2.21 : Codage NRZ du bus CAN

Remarque :

La règle du Bit-Stuffing ne modifie en aucun cas le procédé de codage de ligne.

Comme le montre Figure 2.21, les transitions des bits s‟effectuent sur chaque front

montant de l‟horloge. Dans le protocole CAN, une période d‟horloge correspond à ce que

l‟on appelle le Nominal Bit Time.

II.11. Le nominal bit time [8]

Le Nominal Bit Time représente en fait la durée du bit sur le bus. Cette durée est,

comme nous l‟avons vu, étroitement liée à la période de l‟horloge. Chaque station reliée

sur le bus doit être cadencée avec le même Nominal Bit Time pour pouvoir émettre et

recevoir correctement les données circulant sur le bus.

Ainsi, la durée du bit time de chaque circuit est construite à partir d‟un nombre déterminé

de périodes d‟horloge issue de l‟horloge interne de chaque circuit CAN.


51

La norme BOSCH décrit avec précision la composition de ce Nominal Bit Time qui est

divisé en plusieurs segments :

- le segment de synchronisation (SYNC_SEG)

- le segment de propagation (PROP_SEG)

- le segment de phase buffer n°1 (PHASE_SEG1)

- le segment de phase buffer n°2 (PHASE_SEG2).

La Figure 2.22 donne un aperçu de ces divers composants et de leur agencement.

SYNC_SEG

PROP_SEG

PHASE_SEG1

PHASE_SEG2

Nominal Bit Time

Sample point

Figure 2.22 : Décomposition du nominal Bit Time

En fait, le Nominal Bit Time, exprimé en s, correspond évidemment à l‟inverse du

débit sur le bus. Nous avons donc la formule suivante :

II.12. Description des différents segments

II.12.1. le segment de synchronisation

le segment de synchronisation est utilisé pour synchroniser les différents noeuds du

bus. Comme nous le verrons par la suite, une transition (de 0 à 1 ou de 1 à 0) doit

s‟effectuer dans ce segment pour permettre une resynchronisation des horloges des

différents noeuds en mode de réception de trames.

II.12.2. Le segment de propagation

le segment de propagation est utilisé pour compenser les phénomènes de temps de

propagation sur le bus. Par définition :

Durée_PROP_SEG=2*(t_propag_bus+t_retard_comparateurs+t_retard_drivers_lignes)


52

II.12.3. Les segments « buffer phase1 » et « buffer phase2 »

les segments « buffer phase1 » et « buffer phase2 » sont surtout utilisés pour

compenser les erreurs de phase détectées lors des transitions. Nous verrons aussi que ces

segments peuvent être plus courts ou plus longs à cause des phénomènes de

resynchronisation.

II.12.4. Le point d’échantillonnage ou sample point

le point d‟échantillonnage ou sample point est le point où la valeur du bit est lue sur

le bus. Il est situé à la fin du segment de « buffer phase1 » et constitue la seule valeur

mémorisée pour le niveau du bit. On s‟affranchit des phénomènes de propagation et

d‟oscillation des données sur le bus dans les segments précédents.

II.12.5. Durée des différents segments et notion de Time Quantum

a- Le Time Quantum

Le Time Quantum est une unité de temps qui est construite à partir de la période de

l‟oscillateur interne de chaque nœud. Les fréquences de fonctionnement du bus CAN

s‟étendant de 125 KHz à 1 MHz et celle des oscillateurs étant de plusieurs MHz, Le Time

Quantum représente plusieurs périodes d‟une horloge d‟oscillateur. La période d‟horloge

de l‟oscillateur est appelée minimum Time Quantum. La valeur du préscalaire « m »

détermine le rapport entre le Time Quantum et le Minimum Time Quantum :

TIME_QUANTUM = m * MINIMUM_ TIME_QUANTUM

La valeur de « m » peut varier de 1 à 32, La Figure 2.23 représente la construction

d‟un Time Quantum à partir d‟une période d‟horloge interne au circuit.

Figure 2.23: Construction du Time Quantum

Dans l’exemple ci-dessus, le facteur m est égal à 4.


53

b- La durée des différents segments :

Segment Durée en Time Quanta

Synchronisation - SYNC_SEG 1

Propagation - PROP_SEG 1 à 8

Buffer phase1 - PHASE_SEG1 1 à 8

Buffer phase1 - PHASE_SEG2 1 à 8

Tableau 2. 3 : La durée des différents segments

Le nombre de Time Quanta dans un Nominal Bit Time peut ainsi varier de 8 à 25.

La Figure 2.24 donne le nombre de Time Quanta possible par segment de Nominal Bit

Time. Le choix du nombre de Time Quanta pour chaque segment dépend de la fréquence

de l‟oscillateur. Un nombre important de Time Quanta par segment augmente la précision

de la synchronisation des différents nœuds sur le bus. [8]

Figure 2.24: Durée des différents segments

Dans les applications qui suivent dans le dernier chapitre, nous avons utilisé le logiciel

«CANCALCULATOR » pour déterminer les différents paramètres de la communication

CAN qui utilise les formules citées avant. Figure 2.25


54

Figure 2.25 : L’interface du logiciel « CANCALCULATOR »

Remarque

La librairie prenant en charge le bus CAN et ses circuits connexes comme le MCP2551

et le MCP2515 de Microchip n’est pas disponible dans ISIS-PROTEUS donc ce n’est

pas possible de simuler cette application par ce logiciel.

Chapitre III Réalisation de quelque applications Bus Can

CHAPITRE III

APPLICATIONS

SUR

RESEAU CAN


55

III.1. Introduction

Lorsque plusieurs périphériques se partagent le même bus, il convient de définir la façon

comment accéder à ce bus. Le protocole CAN décrit avec précision et en détail la connexion de

plusieurs dispositifs à un bus, c‟est un bus très répandu dans l‟industrie. Le protocole définit

principalement la préséance d‟accès au bus et résout le problème de collision au niveau matériel

dans le cas où plusieurs périphériques commenceraient à communiquer en même temps.

III.2. Contrôleur CAN

Le bus CAN étant un bus complexe, il est difficile de le mettre en œuvre de

manière totalement software. Les contrôleurs CAN permettent de gérer le bus de manière

hardware. On distingue deux types de contrôleurs :

Les contrôleurs reliés aux microcontrôleurs ou calculateurs par une liaison de type

SPI, comme le MCP2515 de chez Micro-chip pour microcontrôleur qui ne disposent

pas de contrôleur CAN intégré .

Les contrôleurs intégrés aux microcontrôleurs qui disposent donc, d‟un module CAN

avec les lignes TXCAN et RXCAN reportés sur les pins et destinés à être reliés au

transceiver CAN.

Pour notre application on va utiliser le microcontrôleur 16F877A en réalisant un réseau CAN

avec contrôleur CAN externe en exploitant l‟interface SPI .

III.3. Résistance de terminaison de bus

Les résistances de terminaison de Bus sont indispensables au bon fonctionnement de la

communication. Elles sont composées d‟une résistance de début de ligne (RDL) et d‟une

résistance de fin de ligne (RFL). Elles doivent être égales .

III.3.1. A quoi servent les résistances de terminaison ?

C‟est principalement une question d‟adaptation d‟impédance. Si vous envoyez des

signaux sur une ligne ouverte (i.e. sans résistance de terminaison), vous obteniez une réflexion

de votre signal qui va s‟y superposer et le dégrader. En gros, une ligne non adaptée, ça

correspond à parler à quelqu‟un à l‟autre bout d‟une pièce où il y a plein d‟écho. Avec le bout

CAN que fait l‟écho, le destinataire de ta parole ne pigera rien. Avec une bonne adaptation

d‟impédance, ça revient à la même situation mais dans une pièce capitonnée. Il n‟y a pas d‟écho,

ton interlocuteur te reçoit clairement. D‟ailleurs, il existe aussi une notion d‟impédance

acoustique pour caractériser ceci.


56

III.3.2. Est-ce qu’elles sont obligatoires ?

Oui c‟est en quelque sorte obligatoire ! En fait ça peut fonctionner sans, dans certaines

conditions, mais vous enlevez au bus CAN un élément important, sa robustesse.

III.4. Première application

Figure 3.1: Réseau CAN réalisé avec 3 nœuds

(en utilisant des contrôleurs externes et les interfaces SPI)

Une prototype a été réalisée( Figure 3.1) pour établir la communication entre les cartes via

Bus CAN. Nous allons donc expliquer le fonctionnement de cette application ainsi que justifier

le choix des composants.

III.4.1. Description de la platine de communication (Hardware)

L‟application est composée principalement de trois cartes qui représentent les Nœuds de

Bus CAN : « Nœud 1 », « Nœud 2 » et « Nœud 3 ».

Ces cartes communiquent à l‟aide d‟un bus CAN en utilisant l‟interface SPI. Toutefois le role de

l‟application est fondamental à la réalisation de l‟application suivante .

Chaque carte des trois cartes principales sont équipées d‟un PIC 16F877A, des LED ,

d‟un Transmetteur MCP 2551 , d‟un contrôleur CAN MCP 2515, des Résistances ,d‟un Crystal

10MHz, Potentiomètre 10KΩ ,des Capacité 22 pF ,d‟une entrée d‟ alimentation 5v et d‟un

connecteur pour afficheur LCD. Dans notre application l‟afficheur ne servent que pour les

information , la Fgure3.2 schématisé l‟interconnexion de ces trois cartes .


57

LED35

R15

LED37

LED36

LED34

LED33

LED32

LED25

LED24

+U21

+U20

+-C

10

+U19

R13

R12

R11

R10

+U18

+ -

C9

+ -C8

U17

+ -

C7

+ -C6

U16

+U15

PIC16F877A

RA5

RA4

RE1

RE0

RA3

RA0

MCLR

RA2

RA1

RE2

RC3

RC2

RD1

RD0

RC1

OSC1

VDD

RC0

OSC2

RD4

RC7

RD6

RD5

RC6

RD3

RD2

RC5

RC4

RD7

RB5

RB4

RB7

RB6

RB3

RB0

VSS

RB2

RB1

U14

MCP2515

CLKOUT

TX0RTS

TXCAN

RXCAN

TX1RTS

OSC1

VSS

TX2RTS

OSC2

CS

SO

VDD

RESET

SI

RX0BF

RX1BF

SCK

INT

U13

MCP2551Vss

TXD

RXD

Vdd

CANH

Rs

Vref

CANL

U12

R8

R7

LED16

LED15

LED14

LED13

LED12

LED11

+U11

+U10

+-

C5

+U9

R6

R5

R4

R3

+U8

+ -

C4

+ -C3

U7

+ -

C2

+ -C1

U6

+U5

PIC16F877A

RA5

RA4

RE1

RE0

RA3

RA0

MCLR

RA2

RA1

RE2

RC3

RC2

RD1

RD0

RC1

OSC1

VDD

RC0

OSC2

RD4

RC7

RD6

RD5

RC6

RD3

RD2

RC5

RC4

RD7

RB5

RB4

RB7

RB6

RB3

RB0

VSS

RB2

RB1

U4

MCP2515

CLKOUT

TX0RTS

TXCAN

RXCAN

TX1RTS

OSC1

VSS

TX2RTS

OSC2

CS

SO

VDD

RESET

SI

RX0BF

RX1BF

SCK

INT

U3

MCP2551Vss

TXD

RXD

Vdd

CANH

Rs

Vref

CANL

U1

LED10

LED5

LED6

LED7

LED4

LED3

LED2

10k

LED5

LED4

LED3

LED2

LED1

LED0

LED1

LED0

+VDD

+U2

+-

100nF

+VDD

100K

100K

100K

10k

+VDD

R2

+ -

22pF

+ -22pF

10MHz

+ -

22pF

+ -22pF

10MHz

+VDD

PIC16F877A

RA5

RA4

RE1

RE0

RA3

RA0

MCLR

RA2

RA1

RE2

RC3

RC2

RD1

RD0

RC1

OSC1

VDD

RC0

OSC2

RD4

RC7

RD6

RD5

RC6

RD3

RD2

RC5

RC4

RD7

RB5

RB4

RB7

RB6

RB3

RB0

VSS

RB2

RB1

R1

MCP2515

CLKOUT

TX0RTS

TXCAN

RXCAN

TX1RTS

OSC1

VSS

TX2RTS

OSC2

CS

SO

VDD

RESET

SI

RX0BF

RX1BF

SCK

INT

MCP2515_1

MCP2551Vss

TXD

RXD

Vdd

CANH

Rs

Vref

CANL

MCP2551_1

Node3

Node Controller

CAN Controller

Line driver

Node2

Node Controller

CAN Controller

Line driver

Node1

Node Controller

CAN Controller

Line driver

Figure 3.2: schéma d’interconnexion des trois cartes au bus CAN


58

III.4.2. Présentation des composants utilisés

a- Le microcontrôleur PIC16F877A

Figure 3.3: PIC16F877A

Un PIC16F877A (Figure 3.3) est un microcontrôleur, c'est à dire une unité de traitement de

l'information de type microprocesseur à laquelle on a ajouté des circuits internes permettant de

réaliser des montages sans nécessiter d'ajout de composants externes( Figure3.4). Il est un

composant électronique autonome composé par :

un microprocesseur.

une mémoire vive type mémoire RAM.

une mémoire morte type mémoire Flash.

Des interfaces d'entrées/sorties parallèles, séries.

D'interfaces d'entrées/sorties analogiques.

De Timers (registres compteurs de temps ou d'évènements.

Figure 3.4: Le microcontrôleur et ces différents organes.


59

Les Caractéristiques

Une fréquence de fonctionnement élevée, jusqu'à 20MHz.

Une mémoire vive de 368 octets.

Une mémoire morte EEPROM de 256 octets pour la

sauvegarde des données.

Une mémoire de type FLASH de 8 K mots (1mot = 14 bits)

Chien de garde WDT.

33lignes d'entrées /sorties. Chaque sortie peut sortir un courant maximum de 25

mA.

Temporisateurs:

TIMER0 : compteur 8 bits avec pré-diviseur.

TIMER1 : compteur 16 bits avec pré-diviseur

TIMER2 : compteur 8 bits avec pré-diviseur

Entrées de captures et de comparaison

Un convertisseur Analogique Numérique 10 bits avec 8 entrées multiplexées.

Une interface de communication série asynchrone et synchrone (USART/SCI).

Une tension d'alimentation entre 2 et 5.5 V

Une interface de communication série synchrone SSP ( synchronous Serial port)

qui peut être utilise en deux mode :SPI (serial peripheral interface ) ou I2C ( Inter

–intergrated circuit) .

Architecture Externe

Figure 3.5: Diagrammes de broche PIC16F877A


60

Le boîtier du PIC 16F877 décrit par la figure 3.5 comprend :

40 pins : 33 pins d'entrées/sorties,

4 pins pour l'alimentation,

2 pins pour l'oscillateur

1 pin pour le reset (MCLR).

La broche MCLR sert à initialiser le pic qui dispose de plusieurs sources de

RESET

Les broches VDD (Broche 11 et 32) et VSS (Broche 12 et 31) servent à alimenter

le PIC.

On remarque qu'on a 2 connections «VDD» et 2 connections «VSS» .

Les organes du PIC 16F877A utilises sont :

Le Port A

C‟est un port de six bits donc six entrées/sorties numérotées de RA0 à RA5 qui peuvent être

utilisées comme des entrées ou des sorties ou même avoir d‟autre fonction .

Les registres associés avec le port A sont :

Registre PORT A

Qui contient les données à manipuler que ce soit en entrée ou en sortie.

Registre TRISA:

Détermine le sens de manipulation des donnée

TRISA=0xFF : les lignes du PORTA sont configurées en entrées, et le driver de

sortie est placé en haute impédance.

TRISA=0x00 : les lignes du port sont configurées en sorties.

Module de conversion A/N:

Le convertisseur A/N convertit le signal analogique présent sur une de ses 8 entrées en son

équivalent numérique, codé sur 10 bits. Ses entrées sont réparties entre le port A( 5 entrées

analogiques ) et le port E qui dispose de 3 pins ( 3 entrées analogiques) . Les pattes AN2 et AN3

peuvent être utilisées comme références de tension ou comme entrées analogiques standard.

Les tensions de référence haute et basse peuvent être choisies par programmation parmi:

VDD ( broche RA3 ) pour VREF+ et VSS ( broche RA2 ) pour VREF-,On peut donc numériser

jusqu'à 8 signaux analogiques.

Le Port B et le port D

Ce sont des ports à huit bits, donc huit entrées/sorties numérotées de RB0 à RB7 et de RD0 à

RD7, qui peuvent être utilisées comme des entrées ou des sorties, ou même avoir d‟autres

fonctions comme la communication par port parallèle esclave PSP dans le cas du port D, ou la


61

génération d‟interruptions pour le cas du port B . Les registres associés avec ces deux ports sont :

les Registres PortB, PortD , et les Registres TRISB ,TRISD respectivement.

L’interface SPI

Une liaison SPI (Serial Peripheral Interface) est un bus de données série synchrone

baptisé ainsi par Motorola, qui opère en mode Full-duplex. Les circuits communiquent selon un

schéma maître-esclaves, où le maître s'occupe totalement de la communication. Plusieurs

esclaves peuvent coexister sur un même bus, dans ce cas, la sélection du destinataire se fait par

une ligne dédiée entre le maître et l'esclave appelée chip select.

b- Le MCP2515

est un Circuits intégrés de MICROCHIP , ce n'est pas un microcontrôleur , c'est juste un

contrôleur CAN avec interface SPI .

Figure 3.6 MCP 2515 et son diagrammes de broche

c- Transmetteur CAN

Le protocole CAN ne spécifie pas la couche physique, c‟est pourquoi la plupart

des Contrôleurs CAN ne possèdent pas de circuits permettant de les connecter à un bus, qu‟il soit

filaire, à fibre optique ou tout autre mode de transmission possible. Un transmetteur, tel que le

MCP2551 de Micro-chip, permet de faire l‟interface entre le contrôleur CAN et le bus physique.

Figure 3.7: MCP 2551 et diagrammes de broche


62

d- Afficheur LCD

Figure 3.8: Afficheur LCD QC1602A V2.0 et son brochage

Les afficheurs à cristaux liquides, autrement appelés afficheurs LCD (Liquide Crystal

Display), sont des modules compacts intelligents et nécessitent peu de composants externes

pour un bon fonctionnement. Ils consomment relativement peu (de 1 à 5 mA), sont

relativement bons marchés et s'utilisent avec beaucoup de facilité .

Table 3.1: Fonction de chaque broche de l’afficheur LCD et sa connexion


63

e- Capteur de température LM35

Figure 3.9: Capteur de température LM35dz

Le LM35 est un capteur à circuit intégré qui peut être utilisé pour mesurer la température

avec un signal électrique proportionnel à la température (en ° C)

Nous pouvez mesurer la température avec plus de précision que l'aide d'une thermistance. Le

circuit capteur est scellé et non soumis à l'oxydation, etc.

Le LM35 génère une tension de sortie plus élevée que les thermocouples et ne peut exiger

que la tension de sortie soit amplifiée. Il a une tension de sortie est proportionnelle à la

température Celsius. Le facteur d'échelle est 0.1V/°C . Le LM35 ne nécessite pas de calibration

externe ou de taille et maintient une précision de + / -0,4 °C à température ambiante et + / - 0,8 °

C sur une plage de 0 °C à +100 °C.Le capteur a une sensibilité de 10 mV /°C .Donc, si Vout est

1v, puis , la température = 100 ° C La tension de sortie varie linéairement avec la température.

III.4.3. Manipulation et software

Pour commencer, et afin de prendre en main la communication CAN via microcontrôleur PIC,

la première étape c‟est de réussir une communication entre deux microcontrôleur PIC de même

type. L‟un des deux microcontrôleur PIC fonctionne émetteur et l‟autre en récepteur ou même

avoir une communication en full-duplex , en suit Adapter plus Nœuds selon le besoin. [11]

Dans l‟application schématisée par la Figure 3.2, nous avons un réseau CAN constitué de

trois nœuds, où la communication sur le bus CAN est configurée de sorte que le premier

dispositif envoie des messages avec différents identifiants ID=0x20 et 0x21 pour solliciter les

nœuds 2 et 3 respectivement, tandis que le deuxième et le troisième dispositif envoient des

messages avec les identifiants ID=0x22 et 0x23 respectivement au noeud1. Donc, nous allons

aussi configurer les nœuds CAN de façon à ce que le deuxième nœud ne répond qu‟à des

messages entrants à ID =0x20, tandis que le troisième répond seulement à ceux qui ont un

ID=0x21. En conséquence, le premier dispositif est configuré pour recevoir des messages à


64

ID=0x22 depuis le deuxième nœud et ID=0x23 depuis le troisième nœud. Le filtrage des

messages est facile à implémenter grâce aux fonctions : CANSPISetMask et CANSPISetFilter

qui configure le module SPI du Microcontrôleur du et les registres du contrôleur CAN pour

masquer les bits indésirables des identifiants et filtrer les messages utiles. En général, le

protocole CAN n‟a pas besoin d‟un maître. Toutefois, pour faciliter la compréhension de cette

application tout en lui conservant son objectif général, nous autorisons seulement le premier

périphérique à initier la communication, les deux autres périphériques ne font que répondre, et

puis la communication sera dans les deux sens continuellement.

Figure 3.10 : La communication CAN

Si un message est envoyé, le nœud principal (nœud 1) laisse un temps de réponse suffisant au

nœud appelé. Dans le cas où un nœud distant ne répondrait pas dans le temps prévu, le maître

signale une erreur dans le message actuel et continue à appeler les autres nœuds, Dans le cas où

un nœud répondrait en même temps qu‟un autre, il y aurait une collision sur le bus. Le protocole

CAN prescrit dans ce cas que le nœud émettant le message ayant la plus basse priorité se retire

du bus, ce qui permet au nœud émettant un message à priorité plus élevée de continuer sa

transmission. Comme mentionné ci-dessus, nous utiliserons un module de communication SPI

interne du microcontrôleur pour transférer les données au bus CAN. L‟utilisation du module

interne SPI du microcontrôleur offre certains avantages: la possibilité de générer une interruption

pendant l‟envoi et la réception de données ; le module SPI opère indépendamment des autres

périphériques et est facile à mettre en œuvre. La librairie CAN SPI vous permet de paramétrer le

mode opératoire du bus CAN et des filtres du nœud, de lire les données depuis la mémoire

tampon du contrôleur CAN etc.

Dans cette application on utilise aussi des LEDs connectées au microcontrôleur et qui

indiquent si la communication sur le bus fonctionne correctement. Si le nœud 2 répond à l‟appel

du nœud1, les LEDs du PORTA des deux microcontrôleurs seront automatiquement allumées

avec décalage à gauche successif. Si le nœud 3 répond à l‟appel, les LEDs du PORTD des deux

microcontrôleurs seront allumées avec décalage à droite successif.


65

NŒUD 01

CAN BUS

NŒUD 02 NŒUD 03

0X20

0X200X230X22

0X21 0X22

0X21

0X23

Figure 3.11: Filtrage de messages dans le bus CAN

Si

Rx_ID=0x22

Lire le message Can

Initialiser le module CAN

Entrer le mode config

Mise à 1 des bit du Mask

Mettre le filtre B1 à la valeur 0X22


Entrer le mode normal

PORTA =Data[0]

Et affiche la valeur

Data[0]

Tx_ID = 0x21

Ecrire le message CAN

Si

Tx_ID>0x21

Initialiser la donne à envoyer

Data[0] = 0x40 avec

Tx_ID = 0x20


oui

No

PORTD =Data[0]

Tx_ID++

Tx_ID = 0x20


NŒUD 01

Si

Rx_ID=0x20

ou

Rx_ID=0x21

Lire le message Can

Initialiser le module CAN


Mise à 1 des bit du Mask




PORTA =Data[0]

Ou

PORTD =Data[0]

Allume la led

correspondante

Tx_ID = 0x22

RxTx_Data[0] << 1

Ou

Tx_ID = 0x23

RxTx_Data[0] >> 1

Initialiser la donne à recevoir

RxTx_Data[0] = 0x40 avec

Tx_ID = 0x22

Ou

Tx_ID = 0x23

lire le message CAN

oui

No

NŒUD 02 OU 03

RxTx_Data[0] == 0

Ou

RxTx_Data[0] == 128

RxTx_Data[0] = 1

Ou

RxTx_Data[0] = 0


Figure 3.12: Organigramme de fonctionnent de l’application CAN


66

III.5. Le compilateur Mikroc pour Pic

Le langage mikroC pour PIC a trouvé une large application pour le développement de

systèmes embarqués sur la base de microcontrôleur. Il assure une combinaison de

l'environnement de programmation avancée IDE ( Integrated Development Environment ) , et

d‟un vaste ensemble de bibliothèques pour le matériel, de la documentation complète et d‟un

grand nombre des exemples.

Le compilateur mikroC pour PIC bénéficie d'une prise en main très intuitive et d'une

ergonomie sans faille. Ses très nombreux outils intégrés (mode simulateur, terminal de

communication Ethernet, terminal de communication USB, gestionnaire pour afficheurs 7

segments, analyseur statistique, correcteur d'erreur, explorateur de code, mode Débug ICD...)

associé à sa capacité à pouvoir gérer la plupart des périphériques rencontrés dans l'industrie

(Bus I2C™, 1Wire™, SPI™, RS485, USB, gestion de cartes compact Flash et SD™/MMC™,

génération de signaux PWM, afficheurs LCD alphanumériques et graphiques, afficheurs

LEDs à 7 segments, Bus CAN™, etc...) en font un outil de développement incontournable

pour les systèmes embarqués, sans aucun compromis entre la performance et la facilité de

débogage.

Figure 3.13: Les librairies CAN et CANSPI de MikroC


67

III.5.1 Quelques fonctions utilisées dans le programme

CANSPIGetOperationMode() : lire le mode de fonctionnement actuel

CANSPIInitialize() : Initialiser le module CANSPI, Stand-Alone Contrôleur CAN dan

le module de CANSPI est fixé à:

Désactiver pouvez capturer , Continuer opération CAN en mode veille , Ne pas interrompre

les transmissions en attente , Vitesse de transmission est réglée en fonction de paramètres

donnés , CAN en mode Normal , Filter et masque registres identifiants sont mis à zéro Filtre

et masque type de trame de message est réglée en fonction de la valeur CANSPI_CONFIG_FLAGS

CANIRead() : Lire un message

Si au moins un tampon de réception complète est trouvée, elle sera traitée de la manière suivante:

ID du message est récupéré et stocké à l'emplacement fourni par le paramètre id Données du

message est récupéré et stocké dans un tampon fourni par le paramètre de données

La longueur du message est récupéré et stocké à l'emplacement prévu par le paramètre

DataLen Drapeaux de messages sont récupérés et stockés à l'emplacement prévu par le paramètre

CANSPI_RX_MSG_FLAGS

CANSPISetBaudRate() : Pour configure les Paramétrer la vitesse .

Définit la vitesse de transmission de module de CANSPI. En raison de la complexité du

protocole CAN, vous ne pouvez pas simplement forcer une valeur. Au lieu de cela, utiliser cette

fonction lorsque le module de CANSPI est en mode Config.

CANSPISetFilter() : Configurer un filtre de messages

CANSPISetMask() : Configurer le filtrage avancé

CANSPISetOperationMode() : Choisir mode de fonctionnement

Mode: mode de fonctionnement du module de CANSPI. Les valeurs valides: constantes de

CANSPI_OP_MODE. Voir constantes de CANSPI_OP_MODE.

ATTENDRE: mode CANSPI demande de commutation de vérification. Si ATTENDRE == 0,

l'appel est non-bloquante. La fonction ne vérifie pas si le module de CANSPI est en mode de

demande ou non. L'appelant doit utiliser CANSPIGetOperationMode de vérifier le mode de

fonctionnement correct avant d'effectuer l'opération spécifique de mode. ! Si ATTENDRE = 0,

l'appel bloque - la fonction ne sera pas «retour» jusqu'à ce que le mode demandé est réglé.

CANSPIWrite() :Ecrire un message

Si au moins un tampon de transmission vide est trouvé, la fonction envoie un message en attente

de transmission.

Autres fonctions de la librairie CANSPI utilisées dans le programme :

- Delay_us() - SPI1_init() - SPI1_read()


68

Concernant cette application, nous avons utilisé les paramètres CAN suivants :

Can_Rcv_Flags = 0;

Can_Send_Flags=_CANSPI_TX_PRIORITY_0&

_CANSPI_TX_XTD_FRAME &

_CANSPI_TX_NO_RTR_FRAME;

Can_Init_Flags = _CANSPI_CONFIG_SAMPLE_THRICE &

_CANSPI_CONFIG_PHSEG2_PRG_ON &

_CANSPI_CONFIG_XTD_MSG &

_CANSPI_CONFIG_DBL_BUFFER_ON &

_CANSPI_CONFIG_VALID_XTD_MSG;

SJW = 1;

BRP = 3;

Phase_Seg1 =3;

Phase_Seg2 =3;

Prop_Seg =1; /* baud rate = 128kb/s*/

III.6. Deuxième application

III.6.1 Introduction

Nous tous avons déjà au moins dit une fois:« Qu‟est ce qu‟il fait chaud …». Dans de

nombreux actes quotidiens, la notion de température est là. La température est partout ! On n‟y

prête plus attention tellement c‟est devenu un phénomène courant et « transparent ».

La température Physiquement c'est la comparaison d‟ une grandeur G mesuré (quelle que

soit son espèce), à une autre grandeur U, de même espèce, choisie pour unité.

Le résultat de mesure est un nombre entier si l'unité U est contenue un nombre entier de

fois dans la grandeur G considérée. Une grandeur est directement mesurable quand nous

pouvons définir le rapport ou l'égalité ou encore la somme de deux valeurs de cette grandeur.

Ainsi, de nos jours, l‟on distingue plusieurs types de capteurs de température selon le

phénomène en présence, en autre les thermomètres à dilatation pour la dilatation de la matière, le

thermomètre à mercure (classique) plus utilisé pour prélever la température humaine.

Toutefois, avec l‟évolution de la science et des technologies, les hommes ont été à plusieurs

reprises confrontés à des problèmes liés à la température : dilatation des métaux, variation des

résistances, problème des semi-conducteurs etc.…Dans ce sens est né l‟idée de mesurer la

température. [12]

Dans notre travail, on va concevoir un système de mesure et d‟affichage de température en

exploitant la communication par réseau CAN entre deux microcontrôleurs. et afficher cette

dernière dans un afficheur LCD.


69

III.6.2. Présentation du système

On va créer une communication entre deux nœuds ; le premier est un thermomètre électronique

qui composé d‟un capteur de température et des composants électroniques qui ont pour envoyer

dans le BUS CAN, et le deuxième reçoit l‟information et la rende exploitable pour l‟usage.

Notre application consistera à créer un thermomètre électronique (nœud 1) qui devra traiter et

envoyer la température via Bus CAN au nœud 02 pour l‟afficher sur un LCD. En total, cela se

présente sous forme de deux cartes électroniques; une pour l‟acquisition et l‟autre pour

l‟affichage Figure 3.14 similaire au système utilisé dans l‟automobile, où le calculateur moteur

mesure la température du liquide de refroidissement et l‟envoie au porte- instrument via le bus

CAN pour l‟affichage au conducteur. comme illustre la Figure 3.15

.

Figure 3.14: Réseau CAN Réalisé Avec 2 Nœuds

mesurer la température

Concernant cette application, nous avons utilisé les paramètres CAN suivants :

Can_Rcv_Flags = 0;

Can_Send_Flags=_CANSPI_TX_PRIORITY_0&

_CANSPI_TX_XTD_FRAME &

_CANSPI_TX_NO_RTR_FRAME;

Can_Init_Flags = _CANSPI_CONFIG_SAMPLE_THRICE &

_CANSPI_CONFIG_PHSEG2_PRG_ON &

_CANSPI_CONFIG_XTD_MSG &

_CANSPI_CONFIG_DBL_BUFFER_ON &

_CANSPI_CONFIG_VALID_XTD_MSG;

SJW = 1;

BRP = 3;

Phase_Seg1 =3;

Phase_Seg2 =3;

Prop_Seg =1; /* baud rate = 128kb/s*/


70

Clapet de commutation de volet de tubulure d’admission

Pompe de refroidissement Du carburant

Relais de pompe de refroidissement du carburant

Clapet de commutation de volet de tubulure d’admission

Soupape de recyclage des gaz

Témoin de temps de préchauffage

Electrovannes pour injecteur-pompe, cylindres 1-4

Bougies de préŽchauffage Transmetteur altimétrique

Transmetteur de régime-moteur

Transmetteur de Hall

Transmetteur de position de l’accélérateur Contacteur kick-down Contacteur de ralenti

Appareil de commande pour système D’injection directe diesel

Débitmètre d’air massique

Câble pour diagnostic et anti démarrage

Figure 3.15: Exemple Réseau CAN dans l’automobile

système utilisé dans l‟automobile

Porte instrument

système utilisé dans l‟automobile

Transmetteur de température de liquide de refroidissement Transmetteur de pression de tubulure D’admission Bus de données CAN

Appareil de commande D’ABS

Transmetteur de température de tubulure D’admission Contacteur de pédale de débrayage Contacteur de feux stop F et contacteur de pédale de frein Transmetteur de température de carburant Signaux supplémentaires: Signal de vitesse du véhicule Veille du compresseur du climatiseur Contacteur du régulateur de vitesse Alternateur-Borne DF

Appareil de commande de boite automatique Signaux supplémentaires:

Chauffage d’appoint du liquide de refroidissement Régime-moteur Post-fonctionnement du ventilateur de radiateur Coupure du compresseur du climatiseur Signal de consommation de carburant


71

III.6.3. Objectif principal

Créer une communication ( Réseau CAN avec interface spi ) entre thermomètre

électronique et l‟écran LCD qui affiche la température .

AFFICHER LA

TEMPERATURE

DANS LCD

BUS CAN AVEC

INTERFACE SPI

TRAITEMENT LES

DONNEES

PIC 16F877A

TEMPERATURE

LM35DZ

LIRE MESSAGE

CAN

ENVOI OU ECRIRE MESSAGE

CAN

ENVOI MESSAGE

CAN

LIRE OU Reçoit

MESSAGE CAN

TRAITEMENT LES

DONNEES

PIC 16F877A

Figure 3.16: Réseau CAN avec interface spi pour mesuré la température

III.7. Réalisation

La température devra être captée à l‟aide d‟un capteur, notre choix se porte sur le LM35 (

en peut remplacer le capteur lm35 par un potentiomètre qui varie les valeur de entré

analogique ).

L‟application contienne deux microcontrôleurs 16F877A :

le premier mesure la température et envoi sa valeur après traitement via Bus CAN

à l‟autre Microcontrôleur.

le deuxième reçoit la valeur de température ET afficher à partir d‟un afficheur

LCD QC1602A V2.0

Il faudra au préalable effectuer une source d‟une tension car 16F877A fonctionne

sous +5V.

Figure 3.17 : Alimentation stabilisée utilisée dans le projet.


72

Si Id=0x22

Si Id=0x20

Et

Donnée = ‘T’

Initialiser de module CAN


Mise à 1 des bit du mask

Metter le filtre à la valeur 0x22


Lire le message Can

Ecrire du caractère ‘T’sur

un message

Avec identifiant id=0x20

Initialiser de module CAN


Mise à 1 des bit du mask

Metter le filtre à la valeur 0x20


Noeud Afficheur Noeud Collecteur

Lire la température ADC

Non

Oui

Lire le message Can

Afficher sur LCD

ATTENDRE 2 S

CONVERTIR EN C°

Ecrire température sur un

message avec identifiant

id=0x22

Oui

Non

Figure 3.18 : Organigramme de fonctionnent de l’application Dans Le Bus CAN


73

Figure 3.19: schéma d’interconnexion des deux cartes au bus CAN

III.8. Conclusion

Dans ce chapitre, nous avons réussi de faire la conception et la réalisation d‟une

communication entre microcontrôleurs via bus CAN.

Dans la première application, une communication CAN entre trois nœuds est établies, ce

qui nous a permis de voire un allumage successif des LEDs (Figure 3.1), décalage dans un sens

pour les ports A pour les noeuds1 et 2, et décalage dans l‟autre sens pour les ports D pour les

noeuds1 et 3.

Ensuite dans la deuxième application nous avons mesuré la température a partir d‟un

lm35dz branché sur un nœud, ce dernier envoie la valeur mesurée pour l‟affichage dans un LCD

sur un deuxième nœud.L'absence de la simulation et des cartes de développement, ont rendu

difficile le débogage des deux applications. Mais malgré ces difficultés rencontrées ; nous avons

réussi d‟établir une communication CAN et voire son fonctionnement en pratique.

Conclusion Générale

47

Conclusion

Générale

Conclision general

74

Conclusion général

L‟objectif de ce projet était d‟étudier le principe, la conception et la réalisation de

quelques applications utilisant le bus CAN. Dans ce sens, il a été judicieux de diviser le travail

en trois chapitres; où le premier était une introduction aux réseaux informatiques et industriels.

Le deuxième était une présentation détaillée du réseaux CAN et ses différentes caractéristiques.

Dans le troisième chapitre, quelque applications du bus CAN ont étaient présentées en utilisant

quelques informations issues des chapitres précédents, pour réaliser la communication entre des

microcontrôleurs PIC 16F877A via bus CAN.

Suite à l‟étude et la manipulation des différents aspects et composants des applications

CAN vues, nous avons pu comprendre quelques notions techniques, à savoir :

La réalisation d‟une application embarquée ; le choix des composants Hardware et

Software (la programmation d‟un microcontrôleur PIC 16F877A avec un

compilateur mikroC).

La conversion Analogique/Numérique et la manipulation des ports d‟entrée/sortie.

La réalisation d‟une communication CAN entre des microcontrôleurs.

Ce projet de fin d‟étude nous a permis de découvrir le bus CAN, et de nous rendre

compte de l‟importance de ces réseaux dans quelques applications de la vie pratique. En effet, de

nos jours les équipements dans un véhicule ou dans l‟industrie se développent, et une

communication entre les différents systèmes s‟avère nécessaire.

Le prototype que nous avons réalisé préfigure un bus CAN dans des applications réelles,

mais il est évident qu‟un projet de cette nature ne se termine jamais.

Comme perspective de ce travail, on envisage d‟étudier le bus CAN en utilisant plus

d‟outils de développement qui permettent la visualisation des déférentes trames et le débogage

de l‟application. Donc, comme travail future, nous pouvons étendre ce travail dans une

application automobile pour le diagnostique par exemple (OBD : On Board Diagnostic), ou

réaliser une application temps réel pour la synchronisation de plusieurs machines.

Bibliographie

Bibliographie

75

Bibliographie

[1] Jean-Pierre THOMESSE «Réseaux locaux industriels Concepts, typologie,

caractéristiques» Traité Informatique industrielle (2001).technique de l‟ingénieur.

[2] Réseaux locaux industriels, Zoubir Mammeri et Jean-Pièrre Thomesse, Edition Eyrolles,

1994.

[3] Devaux S., Rachline M., “Introduction à l‟automatisme: Schneider Electric”,Encyclopédie

économie 3000, série haute technologie. ISBN 2-7191-0551-1, 2000

[4] [BAJ 01] BAJIC (E.) et BOUARD (B.) « Réseau Profibus ». Traité Informatique

industrielle (2001).technique de l‟ingénieur.

[5] Dominique PARET. « Le bus CAN Controller Area Network. » 1997

[6] Pascal BORGHESI, Cyril RAPIN. Projet de fin d'étude ENSERB. 1998

[7] KADIONIK, Patrice. Le bus CAN. École Nationale Supérieure Électronique Informatique

& Radiocommunications Bordeaux, 2001.

[8] IBRAHIM, Dogan. Advanced PIC microcontroller projects in C: from USB to RTOS with

the PIC 18F series. Newnes, 2011.

[9] CHOISEL, Sylvain, LIGER, Matthieu, et OBERLÉ, Vincent. Gestion de bus CAN. 2000.

[10] RANE, Akshay, SHENDGE, Ajit, SHINDE, Rushikesh, et al. Controller Area Network

and its Applications.

Web graphie

[1] Farhat benighil « réseaux locaux industriels » université d'ANNABA - licence

Automatique 2007 site : http://www.memoireonline.com/07/08/1326/m_reseaux-locaux-

industriels-0.html consulter le 14/04/2015

[11] http://www.mikroe.com/ consulter le 24/01/2015

[12] Benouaden Abderraouf « conception d‟un thermomètre électronique à base d‟un capteur

de chaleur, un PIC, et un afficheur LCD » le laboratoire du département d‟électronique du

l‟université Mentouri de Constantine .2011.

m1-sign-syst-13-12.e-monsite.com/medias/files/rapport-de-stage.docx

http://www.omegas.co.uk/CAN/index.html consulter le 14/03/2015

http://www.can-cia.de/ consulter le 15/04/2015

Le bus CAN - Eric Delaunay http://edelaunay.chez-alice.fr/buscan.htm

Gestion du bus CAN - Vincent Oberle http://www.oberle.org/can-index.html

http://www.memoireonline.com/07/08/1326/m_reseaux-locaux-industriels-0.html

http://www.memoireonline.com/07/08/1326/m_reseaux-locaux-industriels-0.html

http://www.mikroe.com/

http://www.can-cia.de/

http://edelaunay.chez-alice.fr/buscan.htm

http://edelaunay.chez-alice.fr/

http://edelaunay.chez-alice.fr/buscan.htm

http://www.oberle.org/can-index.html

http://www.oberle.org/

http://www.oberle.org/can-index.html

Bibliographie

76

Le bus de terrain CAN - Patrice Kadionik consulter le 11/05/2015

Le réseau CAN et le protocole CAN Open - Vincent Loustau, Eric Vauchey, Cédric Boutonnet

http://www.a2v.fr/program/canopen.htm

Introduction aux Réseaux Locaux Industriels - - Philippe Hoppenot

Le multiplexage automobile : bus VAN, CAN... -

Multiplexage - le bus CAN -

Multiplexage - le bus VAN -

Le transcodage de la trame dans les réseaux embarqués en automobile - Alain Chautard

Le multiplexage - Henri Noirel

http://uuu.enseirb.fr/~kadionik/formation/canbus/canbus.html

http://uuu.enseirb.fr/~kadionik/


http://www.a2v.fr/index.php


http://lsc.univ-evry.fr/~hoppenot/enseignement/cours/rli/introrli.pdf

http://lsc.univ-evry.fr/~hoppenot/presentationfrancaise.html

http://pagesperso-orange.fr/geea.org/telechargement/Le_multiplexage_evolution.zip

http://www.educauto.org/Documents/Infotech/Mux4.pdf



http://www.educauto.org/InfoTech/infotech.php

http://www.educauto.org/Documents/Tech/ANFA-MULTIPLEX/multiplex.pdf

77

Résumé

Lorsque plusieurs périphériques se partagent le même bus, il convient de définir la façon

comment accéder à ce bus. Le protocole CAN décrit avec précision et en détail la connexion de

plusieurs dispositifs à un bus, c‟est un bus très répandu dans l‟industrie. Le protocole définit

principalement la préséance d‟accès au bus et résout le problème de collision au niveau matériel

dans le cas où plusieurs périphériques commenceraient à communiquer en même temps .Dans ce

travail a pour but de présenter les caractéristiques essentiels du bus/réseau de terrain CAN

(Control Area Network). nous rendre compte de l‟importance de ces réseaux dans quelques

applications de la vie pratique. En effet, de nos jours les équipements dans un véhicule ou dans

l‟industrie se développent, et une communication entre les différents systèmes s‟avère

nécessaire.

Abstract

When multiple devices share the same bus, it is necessary to define the way how to access the

bus. The CAN protocol accurately describes in detail and connecting multiple devices to a bus,

the bus is a widespread in the industry. The protocol primarily defines the precedence of bus

access and solves the collision problem in hardware in case more devices start to communicate

simultaneously .In this work aims to present the main features of the bus / fieldbus CAN

(Control Area Network). we realize the importance of such networks in some applications of

practical life. Indeed, nowadays the equipment in a vehicle or in industry are growing, and

communication between different systems is necessary.