L Martine WAHL - ifsttar.fr · fret en 1990 et Tornad dans le TGV A et ... synthesis relating to the use of wire communication networks on-board guided ... 1.2 Evolution des topologies

L E S C O L L E C T I O N S D E L ’ I N R E T S

Martine WAHL

SY

NT

HÈ

SE

N ° 4 5

La nécessité de réduire l’espace occupé par le câblage des équipements embarqués

dans les transports guidés a motivé le passagede techniques de câblage filaire et parallèle àl’utilisation de réseau de terrain. Un réseaulocal de communication peut ainsi remplacerune centaine de lignes de commande parcou-rant le train. Différentes technologies ont ététestées, certaines spécifiquement conçues pourles trains (Mux G, Tornad, Tornad* et TCN –MVB et WTB), d’autres adaptées de solutionsdu marché (CAN, LONWORKS, Bitbus,WorldFip, Profibus).Cet ouvrage fait état des applications concer-nées par une mise en réseau à l’intérieur destransports guidés et présente les protocoles desréseaux de terrain mis en œuvre.

Synthèse INRETS n°45Janvier 2004

Prix : 15,24 €

ISSN 0769-0274ISBN 2-85782-591-9

LES

RÉSE

AU

X D

E TE

RRA

IN E

MBA

RQU

ÉS D

AN

S LE

S TR

AN

SPO

RTS

GU

IDÉS

Synt

hèse

IN

RE

TS

n°45

Martine WAHL est Chargée de Rechercheau Laboratoire Electronique, Ondes et Signaux pour les Transports (INRETS-LEOST).

LES RÉSEAUX DE TERRAIN EMBARQUÉS DANS LES TRANSPORTS GUIDÉS

Conformément à la note du 04/07/2014 de la direction générale de l'Ifsttar précisant la politique dediffusion des ouvrages parus dans les collections éditées par l'Institut, la reproduction de cet ouvrage estautorisée selon les termes de la licence CC BY-NC-ND. Cette licence autorise la redistribution noncommerciale de copies identiques à l’original. Dans ce cadre, cet ouvrage peut être copié, distribué etcommuniqué par tous moyens et sous tous formats.

(CC BY-NC-ND 4.0)

Attribution — Vous devez créditer l'Oeuvre et intégrer un lien vers la licence. Vous devez indiquer cesinformations par tous les moyens possibles mais vous ne pouvez pas suggérer que l'Ifsttar voussoutient ou soutient la façon dont vous avez utilisé son Oeuvre.

Pas d’Utilisation Commerciale — Vous n'êtes pas autoriser à faire un usage commercial de cetteOeuvre, tout ou partie du matériel la composant.

Pas de modifications — Dans le cas où vous effectuez une adaptation, que vous transformez, oucréez à partir du matériel composant l'Oeuvre originale (par exemple, une traduction, etc.), vousn'êtes pas autorisé à distribuer ou mettre à disposition l'Oeuvre modifiée.

Le patrimoine scientifique de l'Ifsttar

Le libre accès à l'information scientifique est aujourd'hui devenu essentiel pour favoriser la circulation dusavoir et pour contribuer à l'innovation et au développement socio-économique. Pour que les résultats desrecherches soient plus largement diffusés, lus et utilisés pour de nouveaux travaux, l’Ifsttar a entrepris lanumérisation et la mise en ligne de son fonds documentaire. Ainsi, en complément des ouvragesdisponibles à la vente, certaines références des collections de l'INRETS et du LCPC sont dès à présentmises à disposition en téléchargement gratuit selon les termes de la licence Creative Commons CCBY-NC-ND.

Le service Politique éditoriale scientifique et technique de l'Ifsttar diffuse différentes collections qui sontle reflet des recherches menées par l'institut :

• Les collections de l'INRETS, Actes• Les collections de l'INRETS, Outils et Méthodes• Les collections de l'INRETS, Recherches• Les collections de l'INRETS, Synthèses• Les collections du LCPC, Actes• Les collections du LCPC, Etudes et recherches des laboratoires des ponts et chaussées• Les collections du LCPC, Rapport de recherche des laboratoires des ponts et chaussées• Les collections du LCPC, Techniques et méthodes des laboratoires des ponts et chaussées, Guide

technique• Les collections du LCPC, Techniques et méthodes des laboratoires des ponts et chaussées, Méthode

d'essai

www.ifsttar.fr

Institut Français des Sciences et Techniques des Réseaux,de l'Aménagement et des Transports14-20 Boulevard Newton, Cité Descartes, Champs sur MarneF-77447 Marne la Vallée Cedex 2

Contact : [email protected]

http://creativecommons.org/licenses/by-nc-nd/4.0/deed.fr



Martine WAHL

Les réseaux de terrain embarqués dans les

transports guidés

Synthèse n˚ 45Juillet 2003

L’auteur :

Martine Wahl, Chargée de Recherche à l’[email protected]

L’Unité de recherche :

Laboratoire Electronique Ondes et Signaux pour les Transports (LEOST) 20, Rue Elisée Reclus B.P. 317 59666 Villeneuve-d’Ascq CedexTél. : (33) 3 20 43 83 43 – Fax. : (33) 3 20 43 83 59

Ce document a bénéficié des commentaires et remarques des référés suivants :

– Michel Dang, Professeur des Universités à l’Institut National Polytechniquede Grenoble, Directeur de l’Ecole Supérieure d’Ingénieurs en Systèmesindustriels Avancés Rhône-Alpes (INPG-ESISAR) ;

– Marion Berbineau, Directrice de Recherche à l’Institut National de Recherchesur les Transports et leur Sécurité, Directrice du Laboratoire ElectroniqueOndes et Signaux pour les Transports (INRETS-LEOST) ;

– Alain Launay, SNCF, Division Informatique Embarquée de la Direction duMatériel et de la Traction ;

– Jean-Philippe Lozac’h, SNCF, unité de recherche « Activité Fret » de laDirection de la Recherche et de la Technologie.

Institut National de Recherche sur les Transports et leur Sécurité

Service des publications : 2, avenue du Général Malleret-Joinville94114 ARCUEIL CEDEX Tél. : 33 (0)1 47 40 70 74 – Fax : 01 45 47 56 06www.inrets.fr

© Les collections de l’INRETSN ° ISBN 2-85782-591-9 N° ISSN 0769-0274

En application du code de la propriété intellectuelle, l’INRETS interdit toute reproduction intégrale ou partielle duprésent ouvrage par quelque procédé que ce soit, sous réserve des exceptions légales

Synthèse INRETS n° 45 3

Fiche bibliographiqueUR (1er auteur) Projet N° Synthèse INRETS N˚ 45

Laboratoire Electronique Ondes et CNS-2T1

Signaux pour les Transports (LEOST)

Titre

Les réseaux de terrain embarqués dans les transports guidés

Sous-titre Langue

F

Auteur(s) Rattachement ext.

Martine Wahl INRETS-LEOST

Nom adresse financeur, co-éditeur N° contrat, conv.

Ministère chargé des Transports/DTT – 9935PREDIT groupe 4.4 contrôle commande ferroviaire

Date de publication

Juillet 2003

Remarques

Résumé

La nécessité de réduire l’encombrement du câblage des équipements motive souvent le passage detechniques conventionnelles de câblage filaire et parallèle à l’utilisation de réseau de terrain. Le domainedes systèmes embarqués sur les matériels ferroviaires roulants ne fait pas exception à la règle. Lesréseaux de terrain introduits peuvent remplacer une centaine de fils parcourant l’ensemble du train. EnFrance, les premières solutions embarquées étaient dédiées (Mux G dans les locomotives de trains defret en 1990 et Tornad dans le TGV A et le métro Magaly de la ligne D à Lyon en 1988). Depuis, denombreuses solutions ont été testées. Certaines sont dédiées telles que Mux G, Tornad, Tornad* et TCN(MVB et WTB), d’autres sont adaptées de solutions normalisées (CAN, LONWORKS, Bitbus, WorldFip,Profibus).

Les premières expérimentations ont été entreprises pour les applications de réversibilité et de travailen unité multiple des locomotives. Les applications candidates au multiplexage ont alors augmenté avecl’expérience des technologies des réseaux de terrain. Ainsi, à une époque où les constructeursferroviaires sont intéressés par la mise en réseau des équipements de freinage (frein ECP –Electronically Controlled Pneumatic brake), le groupe contrôle commande ferroviaire 4.4 du PREDIT 2a souhaité l’entreprise et la diffusion d’un travail de bibliographie et de synthèse relatif à l’utilisation desréseaux de communication filaires embarqués dans le domaine des transports guidés. Cet ouvrage rendpublic les résultats de cette étude PREDIT ATUTEG. Il présente les applications candidates aumultiplexage et les protocoles des réseaux de terrain mis en œuvre.

Mots clés

Réseau de terrain embarqué, multiplexage, protocole de communication, transport guidé

Nb de pages Prix Bibliographie

181 15,24 € oui

1 Projet « Communication Navigation Surveillance pour les transports Terrestres ».

4 Synthèse INRETS n° 45

UR (1st author) Projet N° INRETS synthesis N˚ 45

Laboratoire Electronique Ondes et CNS-2TSignaux pour les Transports (LEOST)

Title

Embedded fieldbuses used in guided railway

Subtitle Language

F

Author(s) Affiliation

Martine Wahl INRETS-LEOST

Sponsor, co-editor, name and address Contract, conv. N˚

Transportation Ministry/DTT – 9935PREDIT group 4.4 on railway control command

Publication date

July 2003

Notes

Summary

The necessity to reduce the congestion of wires generally motivates the change from conventionalparallel wire techniques to the use of fieldbus technologies. This is also true for the systems embeddedinto rolling stocks. An embedded fieldbus can replace a hundred copper wires along the train. In France,the first embedded solutions were developed particularly for trains (Mux G in freight trains, 1990, andTornad in the TGV A and the D-line of the Magaly subway in Lyon, 1988). Since then, several solutionshave been tested. Some have been designed for trains (Mux G, Tornad, Tornad*, or TCN - MVB andWTB). Others have been adapted from standard technologies (CAN, LONWORKS, Bitbus, WorldFip, orProfibus).

The first experiments were undertaken on engine reversibility and multiple unit applications.Experience of local area network technologies has shown that more and more applications can bemultiplexed. Thus, at a time when railway manufacturers are interested in the multiplexing of brakingequipment (ECP brake –Electronically Controlled Pneumatic brake), the “4.4” railway control-commandgroup of the PREDIT2 organization wished to make available the result of this work of bibliography andsynthesis relating to the use of wire communication networks on-board guided transport. This publicationmakes public the results of this “PREDIT ATUTEG” study. It presents the applications which can bemultiplexed and the protocol of the fieldbuses tested.

Key words

Embedded fieldbus, multiplexing, protocol of communication, guided transport

Nb of pages Price Bibliography

181 15.24 € yes

Publication data form

Table des matières

Remerciements 17

Préface 19

Synthèse 21

Introduction 23

Chapitre 1 : Introduction aux réseaux de communication embarqués à bord des matériels roulants guidés 25

1. Qu’est-ce qu’un réseau de communication ? 252. Les applications embarquées dans les matériels ferroviaires roulants 263. Quelques réseaux embarqués ou candidats au multiplexage 30

3.1 Exemples de réseaux embarqués 303.2 Origine des réseaux de communication cités 36

Chapitre 2 : Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI 41

1. Introduction au modèle de référence OSI de l’ISO 412. Modèle de référence IEEE 802 pour les réseaux locaux 453. Equipements d’interconnexion pour les réseaux locaux 484. Décomposition en couches OSI des réseaux de communication « ferroviaires » 49

4.1 Observation générale 494.2 Réseau TORNAD 504.3 Réseaux CAN et CANopen 514.4 Réseau LonWorks 574.5 Réseau WorldFIP 584.6 Réseau TCN 614.7 Réseau PROFIBUS 62

5. Conclusion 64

Chapitre 3 : Couche physique des réseaux de communication filaires embarqués 65

1. Topologie des réseaux 651.1 Topologie des réseaux de communication locaux 65


1.2 Evolution des topologies des réseaux embarqués sur des matériels guidés ferroviaires 69

2. Supports de transmission filaires 722.1 Introduction 722.2 Le cuivre 722.3 La fibre optique 742.4 Autres média 75

3. Techniques de transmission et de codage des informations 753.1 Introduction 753.2 Méthodes de synchronisation entre deux équipements terminaux 763.3 Transmission de signaux analogiques et digitaux et codage des données 78

4. Supports de transmission et codage de l’information dans les « réseaux ferroviaires » 86

4.1 Supports de transmission disponibles pour le bus train sur les matériels roulants guidés 864.2 Supports de transmission et codage de l’information prévus par les réseaux 874.3 Conclusion 103

Chapitre 4 : Méthodes d’accès au médium de communication et trames de données 105

1. Introduction 1052. Accès par passage de jeton (token) 107

2.1 Introduction sur les protocoles IEEE 802.4 et 802.5 1072.2 Protocole d’accès aux réseaux TORNAD et TORNAD* 1102.3 Autres réseaux : les bus MVB et PROFIBUS 113

3. Accès par scrutation (polling) 1133.1 Introduction 1133.2 Protocole des bus WorldFIP, MVB et WTB 1153.3 Protocole du réseau PROFIBUS 1403.4 Protocole du réseau BITBUS 144

4. Accès par compétition (contention, CSMA) 1454.1 Introduction : le protocole IEEE 802.3 1454.2 Protocole d’accès au bus CAN 1464.3 Protocole d’accès au réseau LONWORKS (protocole LonTalk) 151

5. Conclusion 160

Chapitre 5 : Quelques mots sur la sûreté de fonctionnement dans le ferroviaire 163

1. Introduction 163



2. Normes relatives à la sûreté de fonctionnement des applications ferroviaires 1633. Normes relatives aux communications embarquées 1644. Maintenabilité d’un système 1655. Conclusion 166

Conclusion 169

Références Bibliographiques 173

Table des matières


Table des illustrations

Table des figures

Chapitre 1 :Figure 1 : représentation simplifiée d’un réseau de communication

[Summers 2000] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Chapitre 2 :Figure 1 : les sept couches du modèle de référence OSI . . . . . . . . . . . . . . . . . . . . . 42Figure 2 : la communication entre couches OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Figure 3 : taille relative des informations manipulées par chacune des sept

couches du modèle OSI [Rolin 1990] . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figure 4 : décomposition de la couche liaison de données selon le modèle

de référence IEEE 802 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Figure 5 : les groupes de travail IEEE 802 d’après [IEEE_Std_802 1990] . . . . . . . 48Figure 6 : représentation des couches OSI des « réseaux embarqués ferroviaires » 49Figure 7 : couches OSI et réseau TORNAD [Duhot 1989] . . . . . . . . . . . . . . . . . . . 51Figure 8 : organisation du protocole CAN selon le modèle ISO d’après

[Paret 1996 ; CANimpl 2000] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Figure 9 : architecture d’un composant CAN [CANimpl 2000] . . . . . . . . . . . . . . . 53Figure 10 : différentes architectures de nœud CAN [Philips 1995] . . . . . . . . . . . . . 54Figure 11 : modèle de référence CANopen [CANopen 2000] . . . . . . . . . . . . . . . . 56Figure 12 : profil CANOpen [IXXAT_URL] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figure 13 : architecture du réseau de communication LONWORKS

d’après [MOTOROLA_LonWorks] . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figure 14 : exemple d’architecture d’un « Neuron chip » . . . . . . . . . . . . . . . . . . . 58Figure 15 : le protocole WorldFIP [Azevedo & Cravoisy 1998 ; WorldFIP_URL] . 58Figure 16 : exemple d’architecture d’un nœud WorldFIP avec FULLFIP2

(source : « FIPWARE : ALSTOM technology for WorldFIP » ) . . . . . . 60Figure 17 : exemple d’architecture d’un nœud WorldFIP avec MICROFIP

(source : « FIPWARE : ALSTOM technology for WorldFIP » ) . . . . . . 60Figure 18 : couches du réseau TCN [TCNspecifications 1998] . . . . . . . . . . . . . . . 61Figure 19 : architecture de communication de PROFIBUS d’après

[Profibus 1997] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Figure 20 : architecture de communication de PROFIBUS d’après

[Profibus 1999] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figure 21 : architecture de communication de PROFIBUS d’après

[EN_50170_2 1996] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64


Chapitre 3 :Figure 1 : exemple de topologies multipoints et point à point . . . . . . . . . . . . . . . . 66Figure 2 : jonction de deux segments de bus par un répéteur . . . . . . . . . . . . . . . . . 67Figure 3 : état possible du coupleur dans une topologie anneau . . . . . . . . . . . . . . . 68Figure 4 : le réseau Tornad d’Alstom [Duquesnoy & Kieken 1986] . . . . . . . . . . . . 69Figure 5 : notion de bus train et bus véhicule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Figure 6 : exemple d’utilisation d’un bus train et d’un bus véhicule WorldFIP

d’après [WorldFIP_News 1995 ; 1999] . . . . . . . . . . . . . . . . . . . . . . . . . 70Figure 7 : configuration du réseau TCN d’après [Corradi & al 1996 ;

ROSIN_URLa] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Figure 8 : exemple de configuration du réseau LONWORKS d’après

[Chervet 1998] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Figure 9 : gamme de fonctionnement des média dans le spectre électromagnétique

d’après [Summers 2000] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Figure 10 : techniques de connexion d’un nœud à une fibre optique . . . . . . . . . . . 75Figure 11 : représentation d’un système de transmission de données

[Lagrange & Seret 1998 ; Mackenzie & Bettaz 1988] . . . . . . . . . . . . . 76Figure 12 : technique de transmission asynchrone . . . . . . . . . . . . . . . . . . . . . . . . . 77Figure 13 : technique de transmission synchrone . . . . . . . . . . . . . . . . . . . . . . . . . . 78Figure 14 : codage de données digitales dans le cas d’une transmission analogique

[Summers 2000] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 15 : codage de données analogiques dans le cas d’une transmission

analogique [Summers 2000] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Figure 16 : codage NRZ et NRZI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Figure 17 : codage HDB3 [Madec E7430 ; Duhot 1989] . . . . . . . . . . . . . . . . . . . . 83Figure 18 : codage Manchester et Manchester différentiel . . . . . . . . . . . . . . . . . . . 84Figure 19 : transmission bidirectionnelle en bande de base sur un médium cuivre

en topologie bus [Yoon 1998] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Figure 20 : transmission unidirectionnelle en large bande sur un médium cuivre

en topologie bus [Yoon 1998] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Figure 21 : câble UIC 568 et câble UIC 558 utilisé pour le bus train de TCN

[IEC_TCN_URL] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Figure 22 : principe de la télécommande par multiplexage (emprunté à

[Boutonnet & Chateaureynaud 1989a]) . . . . . . . . . . . . . . . . . . . . . . . . 88Figure 23 : codage des données de la liaison MUX G [Boutonnet &

Chateaureynaud 1989a]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Figure 24 : bus train WTB et bus véhicule MVB [Kirrmann & Zuber] . . . . . . . . . 91Figure 25 : partie de l’unité MAU (Medium Attachment Unit) connectée à

la ligne A du bus train . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Figure 26 : codage des éléments binaires du réseau WorldFIP . . . . . . . . . . . . . . . . 95Figure 27 : exemple de relais utilisé avec un bus train et bus véhicule en

technologie CAN (source [Witte 1998]) . . . . . . . . . . . . . . . . . . . . . . . . 98



Figure 28 : exemple d’utilisation de répéteurs dans un réseau CAN (source [Paret 1996]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Figure 29 : codage NRZ des bits CAN avec bourrage de bits [Paret 1996] . . . . . . 101Chapitre 4 :Figure 1 : techniques de partage du médium de transmission

(fait à partir des informations contenues dans [Summers 2000 ; Obracza & al 2000 ; Rolin 1990 & 1999 ; Lagrange & Seret 1998 ; Thomesse 1999]) . . . . . . 105

Figure 2 : jeton sur anneau et jeton sur bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Figure 3 : méthode d’accès par passage de jeton sur anneau du protocole IEEE 802.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Figure 4 : méthode d’accès par passage de jeton sur anneau du protocole FDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Figure 5 : circulation des messages dans TORNAD [Duquesnoy & Kieken 1986 ; Duhot 1989] . . . . . . . . . . . . . . . . . . . . . . 111

Figure 6 : mode « ping-pong » du régime perturbé de TORNAD [Duhot 1989] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Figure 7 : structure de la trame TORNAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Figure 8 : techniques d’accès au médium choisies pour les bus MVB et PROFIBUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Figure 9 : illustration d’un « télégramme » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Figure 10 : « Stations » et « Arbitre de Bus » du protocole WorldFIP . . . . . . . . . . 114

Figure 11 : protocole d’accès maître-esclaves de WorldFIP . . . . . . . . . . . . . . . . . . 114

Figure 12 : allocation du canal de communication par le contrôleur du bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Figure 13 : exemple WorldFIP d’allocation du médium . . . . . . . . . . . . . . . . . . . . . 116

Figure 14 : allocation du médium du protocole WorldFIP . . . . . . . . . . . . . . . . . . . 118

Figure 15 : format de la trame WorldFIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Figure 16 : passerelle entre les bus WTB et MVB (nœud WTB) permettant le transfert de « variables processus » . . . . . . . . . . . . . . . . 122

Figure 17 : trame de la couche liaison de données pour les services messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Figure 18 : vue du réseau par une « application utilisateur » [ROSIN_URLb] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Figure 19 : vue du réseau par une « application système »[ROSIN_URLb] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Figure 20 : adresses utilisateur et système (adressage de la couche réseau) [ROSIN_URLb] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Figure 21 : passerelle entre les bus WTB et MVB (nœud WTB) permettant le transfert de « messages »d’après [ROSIN_URLb] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126



Figure 22 : couche liaison de données de TCN d’après [TCNspecifications1998] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Figure 23 : allocation du médium des bus véhicule MVB et train WTB par leur maître respectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Figure 24 : numérotation des nœuds WTB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Figure 25 : format de la trame WTB du réseau TCN . . . . . . . . . . . . . . . . . . . . . . . 133

Figure 26 : protocole d’accès au médium du protocole MVB réparti sur plusieurs phases apériodiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Figure 27 : protocole MVB – Recherche d’événements (algorithme réparti sur plusieurs phases apériodiques) . . . . . . . . . . . . . . . . . . . . . . 137

Figure 28 : redondance de l’administrateur du bus MVB . . . . . . . . . . . . . . . . . . . . 138

Figure 29 : format des trames maîtres et esclaves du bus MVB . . . . . . . . . . . . . . . 140

Figure 30 : mode de transmission cyclique du bus PROFIBUS . . . . . . . . . . . . . . . 140

Figure 31 : définition d’un cycle message PROFIBUS . . . . . . . . . . . . . . . . . . . . . 141

Figure 32 : relation logique entre les adresses des stations maîtres d’après[EN_50170_2 1996] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Figure 33 : format de la trame PROFIBUS d’après [Schickhuber & McCarthy ; Siemens 1999] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Figure 34 : format de la trame BITBUS [Ciame 1999] . . . . . . . . . . . . . . . . . . . . . 144

Figure 35 : algorithme CSMA/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Figure 36 : protocoles CSMA – quelques stratégies de report de transmission [Misic 1999] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Figure 37 : arbitrage bit à bit sur le champ d’arbitrage de la trame CAN . . . . . . . . 147

Figure 38 : méthode d’accès CSMA avec arbitrage bit à bit et accès prioritaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Figure 39 : trame de donnée CAN [Bosch 1991] . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Figure 40 : communication synchrone cyclique et acyclique et communication asynchrone de CANopen [CANopen 2000] . . . . . . . . . . 151

Figure 41 : intervalle de temps aléatoires du protocole CSMA prédictifp-persistant [ANSI/EIA-709.1-A 1999 ; Schweins & Heffernan 1998] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Figure 42 : protocole CSMA prédictif p-persistant avec des intervalles de temps prioritaires [ANSI/EIA-709.1-A 1999 ; Schweins & Heffernan 1998] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Figure 43 : format d’une trame LONWORKS d’après la norme [ANSI/EIA-709.1-A 1999] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Figure 44 : format du champ « adresse » de la trame LONWORKS [ANSI/EIA-709.1-A 1999] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Figure 45 : exemple d’utilisation particulière de LONWORKS, non dédié ferroviaire, par [Schweins & Heffernan 1998] . . . . . . . . . . . . . . 158

Figure 46 : partage du canal (protocole FEBIS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 160



Chapitre 5 :Figure 1 : les références ferroviaires concernant la sécurité dans le

ferroviaire [XP_ENV_50129 1999] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Figure 2 : exemple d’un ensemble de systèmes de communication embarqué

mis en œuvre pour l’envoi d’information à une station [Adtranz 2001] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Figure 3 : architecture globale de communication train-infrastructure en étude [Adtranz 2001] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167



Table des tableaux

Chapitre 1 :Tableau 1 : matériels équipés des réseaux TORNAD et CAN

[Poitevin 2000 ; Duhot 1989] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Tableau 2 : matériels équipés du réseau TORNAD* [Poitevin 2000] . . . . . . . . . . . 32Tableau 3 : matériels équipés du réseau TCN ou MICAS-S2 [Poitevin 2000] . . . . . 32Tableau 4 : matériels équipés du réseau Intel BITBUS [Poitevin 2000] . . . . . . . . . 33Tableau 5 : utilisation d’un réseau WorldFIP dans des applications

ferroviaires d’après [WorldFIP_News 1999] . . . . . . . . . . . . . . . . . . . . 33Tableau 6 : matériels équipés de télécommande par multiplexage [Poitevin 2000] . 34Tableau 7 : matériels équipés du réseau LONWORKS [Poitevin 2000] . . . . . . . . . 35Chapitre 3 :Tableau 1 : recommandation pour l’utilisation conjointe des réseaux

de types T et L d’après [IEEE_1473 1999] . . . . . . . . . . . . . . . . . . . . . . 72Tableau 2 : transmission analogique/ numérique et nature de l’ETCD d’après

[Summers 2000] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Tableau 3 : caractéristique de la liaison MUX G d’après [Boutonnet

& Chateaureynaud 1989a] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Tableau 4 : caractéristique de la liaison TORNAD d’après [Duquesnoy

& Kieken 1986 ; Duhot 1989] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Tableau 5 : caractéristique des liaisons TCN d’après [IEC_TCN_URL ;

ROSIN_URLb ; TCNspecifications 1998] . . . . . . . . . . . . . . . . . . . . . . 93Tableau 6 : caractéristique des liaisons BITBUS d’après [Ciame 1999 ;

GESPAC_URL ; Elzet_80_URL ; Furrer 1998] . . . . . . . . . . . . . . . . . . 94Tableau 7 : caractéristique des liaisons WorldFIP d’après

[ALS_50414b-en 1998] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Tableau 8 : caractéristique de la liaison RS 485 du bus PROFIBUS

[Profibus 1997 ; 1999 ; EN_50170_2 1996] . . . . . . . . . . . . . . . . . . . . . 96Tableau 9 : caractéristique de la liaison CEI 1158-2 du bus PROFIBUS

[Profibus 1997 ; 1999] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Tableau 10 : propriétés de la fibre optique d’après [Profibus 1999] . . . . . . . . . . . . 97Tableau 11 : caractéristique d’une liaison CAN d’après

[GESPAC_URL ; Paret 1996] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Tableau 12 : caractéristique de la paire torsadée LONWORKS [Schickhuber &

McCarthy 1997a ; 1997b ; Echelon_URL] . . . . . . . . . . . . . . . . . . . . . . 102Tableau 13 : médium courant porteur [Echelon_URL] . . . . . . . . . . . . . . . . . . . . . . 102Tableau 14 : codage des éléments binaire, synchronisation et isolation

galvanique pour un médium paire torsadé . . . . . . . . . . . . . . . . . . . . . 103Tableau 15 : bilan des longueurs et débits des réseaux comparés à

ceux de TCN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104


Chapitre 4 :Tableau 1 : durée d’un cycle élémentaire (ou période de base) des réseaux

WorldFIP et TCN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Tableau 2 : trames de requête-réponse définies par le protocole

WorldFIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Tableau 3 : définition des télégrammes des bus de TCN . . . . . . . . . . . . . . . . . . . . . 129Tableau 4 : définition des télégrammes du bus WTB . . . . . . . . . . . . . . . . . . . . . . . 134Tableau 5 : description des requêtes de l’administrateur maître

du bus MVB d’après [ROSIN_URLb] . . . . . . . . . . . . . . . . . . . . . . . . . 139



Remerciements

Je tiens à remercier l’ensemble des personnes et des institutions qui m’ont aidée aucours de cette étude.

Je remercie les membres du groupe 4.4 contrôle-commande ferroviaire du PREDIT 2qui a discuté et retenu cette étude et la Direction des Transports Terrestres du ministèrechargé des transports qui l’a financée.

Je poursuivrai par les industriels et opérateurs qui m’ont fait connaître leurs points devue, et je citerai en particulier la CSEE et la SNCF.

Une pensée particulière pour la SNCF qui m’a ouvert ses portes à plusieurs reprises,en particulier à la Direction de la Recherche, à la division de l’informatique embarquéedu département des équipements et des systèmes électriques de la direction du Matériel et de la Traction, au pôle maintenance PMT2 de l’établissement industriel demaintenance du matériel d’Hellemmes.

Mes plus vifs remerciements vont enfin à Monsieur le Professeur Michel Dang(INPG-ESISAR), Madame Marion Berbineau (INRETS-LEOST), Monsieur AlainLaunay (SNCF) et Monsieur Jean-Philippe Lozac’h (SNCF), référés de cette étude, pourle travail de relecture et les amendements qu’ils ont bien voulu me suggérer.


Préface

L’émergence des Réseaux Locaux Industriels (RLIs) est contemporaine de celle desLANs, au tout début des années 1980. Après une décade où les principaux efforts por-taient sur les principes de commutation et les réseaux généraux, un événement remar-quable, souvent passé sous silence, a accompagné l’essor des LANs : l’annonce du réseaulocal ETHERNET n’était pas seulement celle de la méthode d’accès de R. Metcalfe, déjàconnue, mais aussi celle des circuits intégrés d’INTEL qui implantaient ladite méthoded’accès. Ce principe de réalité, couplant méthode d’accès et architecture des circuits, aaccompagné toutes les réussites industrielles des vingt dernières années des LANs, dontles RLIs.

Le domaine des réseaux de communication embarqués à bord des matériels roulantguidés annonce de grands efforts de standardisation des protocoles et de leurs interfaces.Ces efforts ont un caractère ou une urgence comminatoire lié à la communauté des utili-sateurs en général, des prescripteurs de toute origine et des industriels des RLIs. Cettequestion traditionnelle se pose aussi : importer des RLIs existant dans d’autres secteursapplicatifs (process, voiture,..) ou en concevoir de nouveaux, plus adaptés au domaineferroviaire ?

La sortie de cet ouvrage marque le début de ces efforts.

Le lecteur empruntera le parcours balisé selon le modèle de référence OSI, de lacouche physique à la couche MAC.

La couche physique est présentée selon un découpage qui facilite la compréhensiondu lecteur : topologie, support de transmission, techniques de transmissions et de codagedes informations. Quant aux spécificités des réseaux ferroviaires, elles font l’objet d’uneanalyse additionnelle.

La couche MAC est enfin présentée selon une approche très analytique, par grandesfamilles de méthodes d’accès numériques : accès répartis par passage du jeton, accès parscrutation et accès par compétition.

Le principe de réalité cité ci-dessus a rarement quitté les préoccupations de l’auteur :c’est un ouvrage pour ingénieurs, d’études ou d’application, avec un fond d’ouverturepour ceux qui font de la veille et pour des chercheurs.

Ingénieur de formation, Martine Wahl a passé brillamment sa thèse de doctorat, en1997, au sein de la communauté IMAG de Grenoble, dans le cadre de mon équipe derecherche. Celle-ci travaillait sur les réseaux de communication dans le projet européenPROMETHEUS-PROCHIP sur la voiture intelligente. Ses interrogations et résultats prin-cipaux l’ont conduite à l’INRETS. Elle y mène activement des travaux de recherche, dontcet ouvrage est une des retombées.


Les perspectives sont vastes et portent à la fois sur les problèmes posés par les sys-tèmes embarqués à temps réel critique, leur sûreté de fonctionnement et par ceux qu’en-gendre l’évolution de plus en plus marquée des réseaux de communication vers un espa-ce ouvert sans contrainte propriétaire visible, sans contrainte de type (télécommunication,INTERNET,..) et de préférence sans contrainte de débit.

Prof. Michel DangInstitut National Polytechnique de Grenoble



Synthèse

La nécessité de réduire l’espace occupé par les câbles d’interconnexion des équipe-ments motive souvent le passage de techniques conventionnelles de câblage filaire etparallèle à l’utilisation de réseau de terrain. Le domaine des systèmes embarqués sur lesmatériels ferroviaires roulants ne fait pas exception à la règle. Les réseaux de terrainintroduits peuvent remplacer une centaine de fils parcourant l’ensemble du train. EnFrance, les premières solutions embarquées ont été spécifiquement conçues pour le fer-roviaire (Mux G dans les locomotives de trains de fret en 1990 et Tornad dans le TGV Aet le métro Magaly de la ligne D à Lyon en 1988). Depuis, de nombreuses solutions ontété testées. Certaines sont dédiées telles que Mux G, Tornad, Tornad* et TCN (MVB etWTB), d’autres sont adaptées de solutions normalisées (CAN, LONWORKS, Bitbus,WorldFip). Malgré ce large éventail de réseau, c’est encore un autre réseau, le réseauPROFIBUS, qui a été choisi et est aujourd’hui à l’étude pour les applications de contrôle-commande ERTMS.

Si les premières expérimentations ont été entreprises pour les applications deréversibilité et de travail en unité multiple des locomotives, les applications candidates aumultiplexage ont alors augmenté avec l’expérience des technologies des réseaux deterrain. Les applications d’informations aux voyageurs et celles de diagnostique et demaintenance se sont jointes aux applications de télécontrôle. L’interconnexion possiblede trains de pays d’origines différents est un besoin fort pour les trains de fret. Cependant,l’utilisation de réseaux d’origine variée et leur implantation dans des matériels en relationavec leur origine et celle des matériels hôtes ne facilitent pas cette interconnexion desvéhicules de pays européens différents.

C’est dans ce contexte que l’ouvrage met en valeur les ressemblances etdissemblances des réseaux embarqués testés en effectuant une description progressive ettransversale de leur couche physique et de leur sous-couche d’accès au médium amenéeavec un rappel de notions de base en réseau de communication.

Dans un premier temps, l’hétérogénéité des solutions testées à ce jour et la difficultéd’une approche commune des problèmes de communication inter-systèmes sontnotamment constatées par l’étude de la décomposition des réseaux de terrain selon le modèle de référence OSI de l’ISO et le modèle IEEE 802 propre aux réseaux decommunication locaux.

Dans un deuxième temps, une étude des topologies des réseaux de communicationlocaux et des différents média de transmission est réalisée. Un consensus semble aujour-d’hui trouvé autour de leur intégration selon une structure hiérarchique à deux niveaux debus de communication. Cette hiérarchie repose d’une part sur la définition de plusieurs« bus véhicule » pour l’interconnexion d’équipements à bord de chaque véhicule ouencore à bord d’un ensemble indéformable de véhicules. Elle repose d’autre part sur celle


d’un bus train pour l’interconnexion des véhicules du train pouvant subir des opérationsde couplages et découplages en cours d’exploitation. Ce bus train assure une communi-cation entre les différents bus véhicule du train. L’étude de la longueur des média filairesen cuivre et des débits sur ces média pour chacun des réseaux montre alors des valeursde couples « longueur-débit » très différentes. Ces différences proviennent de celles descaractéristiques physiques des média de transmission considérés par chacun des réseaux,mais également des protocoles d’accès propres à ces réseaux.

Dans un troisième temps, l’étude des méthodes d’accès au médium de communica-tion montre l’utilisation de techniques d’accès round robin ou de contention CSMA(CAN, LONWORKS). Parmi les techniques round robin, on note d’une part la méthode depassage de jeton sur anneau (TORNAD) ou de jeton sur bus (TORNAD*, PROFIBUS,MVB) et d’autre part celle de la scrutation (WorldFIP, MVB, WTB, PROFIBUS, BITBUS). Les méthodes de passage de jeton sur bus et de scrutation sont souventcombinées. Outre les méthodes d’accès au médium de transmission, les accès auxréseaux TCN et LONWORKS définis sur les sept couches du modèle de référence OSI sontégalement considérés. Pour des applications temps critique ferroviaires, des réseaux detypes scrutation qui définissent un trafic périodique pour les variables temps critique etun trafic apériodique pour les autres variables et les messages semblent être privilégiés.Cette méthode est parfois associée à la technique du passage de jeton qui permet uneredondance du contrôleur maître du bus. Bien que les protocoles à accès aléatoires CANet LONWORKS ne définissent pas de trafics périodiques et apériodiques, les exemples duprotocole CANopen et d’utilisation du protocole LONWORKS montrent l’existence(CANopen) ou la faisabilité (LONWORKS) d’une telle spécification au niveau de la coucheapplication (protocole CANopen) ou de l’application utilisateur (LONWORKS).

Les systèmes ferroviaires étant soumis à de fortes perturbations électromagnétiques etmécaniques, la notion de sûreté de fonctionnement dans les systèmes embarqués inté-grant des réseaux de communication est finalement introduite. Les principales normesferroviaires y sont rappelées. Quelles que soient les mesures particulières prises dans lesprotocoles des réseaux de communication, les normes prEN 50159-1 et -2 imposentqu’une couche sécurité soit construite au-dessus du système de communication pour lesapplications de sécurité. La sûreté de fonctionnement des systèmes ferroviaires intégrantdes communications ne va cesser de prendre de l’importance avec l’extension des com-munications embarquées et des échanges entre les installations embarquées et celles del’infrastructure.

En guise de conclusion, on remarquera que si les réseaux MUX G, TORNAD et TORNAD* ne sont plus embarqués dans les nouveaux matériels ferroviaires, il estaujourd’hui très difficile de prévoire l’ensemble des solutions qui le seront sur les maté-riels à venir. L’existence de ces réseaux pourrait être plus liée à celle du développementdes passerelles adéquates qu’à celui des composants des réseaux qui, à l’exception duréseau TCN, sont des réseaux largement utilisés dans des applications d’automatisation.



Introduction

Le groupe contrôle commande ferroviaire du « Programme national de REcherche et D’Innovation dans les Transports terrestres » (groupe 4.4 du PREDIT 2) a mis en avant un certain nombre de problématiques scientifiques et techniques à traiter. Parmi celles-ci, un consensus s’est formé autour de la nécessité d’entreprendre et dediffuser un travail de bibliographie et de synthèse relatif à l’utilisation des réseaux decommunication filaires embarqués dans le domaine des transports guidés. Cette étude aété l’objet du projet PREDIT ATUTEG dont l’acronyme signifie « Analysebibliographique et synthèse Technique relative à l’Utilisation des réseaux de TerrainEmbarqués dans le domaine des transports Guidés ». Cet ouvrage de synthèse rend public les résultats de cette étude.

La démarche suivie pour cette étude a été la suivante. Deux premières réunions à la SNCF ont permis un recensement des différents réseaux embarqués sur du matériel ferroviaire roulant français. A partir de ces informations, une recherchebibliographique a pu être menée. Peu d’informations publiques ont pu être trouvées quant à la façon d’utiliser ces « réseaux de communication ferroviaires » ou d’autresréseaux locaux à l’étranger. Par contre, l’ensemble des informations collectées a montré un large éventail parmi les solutions techniques retenues qu’il a paru alorsintéressant de mettre en valeur. Deux choix se sont alors offert dans la façon de présenter les caractéristiques techniques des réseaux de communication filairesembarqués sur du matériel roulant ferroviaire :

– une description successive de chacun des réseaux après un chapeau introductifcommun rappelant des notions de base en réseau de communication ;

– une description progressive et transversale de chacun des réseaux amenée avec unrappel de notions de base en réseau de communication, description qui pour chacund’eux met en valeur leur ressemblance et dissemblance.

C’est cette seconde approche qui a été adoptée dans cette synthèse avec pour guidedescriptif l’organisation des fonctionnalités des réseaux de communication selon lemodèle de référence hiérarchique OSI (Open System Interconnection) de l’ISO(International Standardization Organisation) lorsque les informations étaientdisponibles. Il n’a pas été possible, dans le temps imparti, de parcourir l’ensemble des fonctionnalités des réseaux considérés dans cette étude. Nous nous sommes alors concentrés, en référence au modèle OSI, sur l’étude de leur couche physique et de leur sous-couche MAC (Medium Access Control –partie basse de la couche liaison de données).

Le document résultant comporte cinq chapitres. Le chapitre 1 introduit laproblématique des réseaux de communication embarqués à bord des véhicules guidés.Ensuite, le modèle de référence sur l’Interconnexion des Systèmes Ouverts (OSI en


anglais) de l’Organisation Internationale de Standardisation (ISO en anglais) est rappeléen chapitre 2. Les couches des réseaux de communication embarqués dans des matérielsferroviaires y sont présentées. Les chapitres 3 et 4 sont respectivement consacrés auxdifférentes couches physiques de ces réseaux et aux méthodes d’accès mises en jeu.Enfin, le chapitre 5 introduit la notion de sûreté de fonctionnement dans les systèmesembarqués intégrant des réseaux de communication.



Chapitre 1

Introduction aux réseaux decommunication embarqués à bord

des matériels roulants guidés

Ce premier chapitre a pour objet l’introduction de la problématique « réseau decommunication embarqué dans des matériels ferroviaires roulants guidés ». Nous yrappelons succinctement ce qu’est un réseau de communication et présentons quelquesapplications « train » candidates à ce jour à la mise en réseau dans les matériels roulantsconsidérés. Enfin, nous introduisons les différents réseaux de communication qui fontl’objet des chapitres 2 à 4 de cette étude.

1. Qu’est-ce qu’un réseau de communication ?

[Thomesse_R7574] définit un réseau de communication comme « un ensemble demoyens qui permettent la communication entre des processus d’application ou tâchesréparties sur des matériels informatiques de tout type ». L’architecture fonctionnelle decet ensemble comporte « au moins un support de transmission pour l’acheminement dessignaux » et des « protocoles de communication selon une architecture en couchesconformes ou non au modèle OSI (Open System Interconnection) » [Thomesse_R7574](voir le paragraphe 2 de ce chapitre). L’architecture matérielle, illustrée par la figure 1 de[Summers 2000], montre un ensemble de stations (ou nœuds) équipées d’un systèmed’émission et de réception et interconnectées entre elles via un support de transmissionpour l’acheminement des signaux.

De nombreuses classifications de réseaux de communication existent. La figure 1 meten valeur les réseaux WAN (Wide Area Network) et les réseaux LAN (Local AreaNetwork) qui sont également classiquement distingués des réseaux MAN (MetropolitanArea Network). Cette distinction tient compte de leur couverture géographique. Un réseauLAN ou réseau local est un réseau propriétaire, et donc d’utilisation gratuite, « qui couvreune zone géographique limitée » [Thomesse_R7574], typiquement un local ou un groupede locaux. La technologie choisie peut aussi être propriétaire ou rendue propriétaire parson utilisation particulière dans une ou un ensemble d’applications. Un réseau MAN ouréseau métropolitain (réseau fédérateur [Toutain 1999]) permet le raccordement delocaux ou groupes de locaux entre eux par l’interconnexion de leurs réseaux locaux. Lecoût de sa gestion et de sa maintenance est réparti entre les différents utilisateurs. Unréseau WAN ou longue distance (réseau public [Toutain 1999]) n’est pas limité à une


zone géographique et fait appel à des réseaux publics et les services qui leurs sontassociés. Sa gestion et sa maintenance sont réalisées par un opérateur facturant auxutilisateurs son utilisation.

Figure 1 : représentation simplifiée d’un réseau de communication [Summers 2000]



Les réseaux de communication embarqués au sein des matériels roulants ferroviairesfont parti de la famille des réseaux locaux. Les systèmes de communication qui nousintéressent plus particulièrement dans le cadre de cette étude sont :

– des réseaux de communication de type LAN embarqués existants ou à l’étude pourun matériel roulant ferroviaire,

– qui sont utilisés à des fins de contrôle-commande (c’est-à-dire des réseaux nonspécifiés pour la transmission d’images ou de voix) et

– dont le médium (support) de transmission filaire est constitué de cuivre ou de fibresoptiques.

Dans ce rapport, ne seront donc pas abordés les réseaux de communication sans fils(wireless), qui font l’objet de l’étude PREDIT-ESTUTEE (soit de l’« Etat de l’art etSynthèse Technique concernant l’Utilisation de systèmes de TélécommunicationExistants ou Emergeants dans le domaine des transports guidés » [Berbineau 2001a ;2001b]), ni les réseaux filaires utilisés dans les infrastructures ferroviaires.

2. Les applications embarquées dans les matérielsferroviaires roulants

L’introduction des réseaux de communication filaires à bord des trains date d’unevingtaine d’années. Elle se fait de manière prudente, en raison notamment des contraintes

fortes de sécurité liées au domaine ferroviaire, de la période d’amortissement du matérielroulant ferroviaire longue (de 15 à 30 ans) et du marché concerné restreint. Une desmotivations à cette introduction est la réduction de l’engorgement des câbles servant à latransmission des ordres entre les voitures d’un train de marchandises ou de voyageurs etnotamment entre les rames de TGV.

Les premières fonctionnalités multiplexées ont été :

– La réversibilité de la cabine de pilotage

La réversibilité a pour but, en autorisant un fonctionnement de la locomotive en traction ou en poussée, de faciliter les manœuvres en gare par exemple ou encore de permettre un fonctionnement des trains dans un réseau ferroviaire local nécessitant des changements de sens de circulation fréquents tel que celui de « l’étoile de Savoie » [Boutonnet et Chateaureynaud 1989a]. Cettefonctionnalité est implantée aussi bien dans les trains de marchandises que devoyageurs.

– Le travail en unité multiple (UM) des locomotives

Afin d’augmenter la longueur et le tonnage possible en marchandises des trains, lefonctionnement de plusieurs locomotives d’un même train doit pouvoir êtrecontrôlé simultanément. Cette technique permettait d’envisager dans [Boutonnet etChateaureynaud 1989a] la création, d’une part, d’un train de marchandise rapide à160 km/h comprenant deux locomotives en unité multiple en tête du train et,d’autre part, d’un autre train qualifié d’« hyperlourd » comportant troislocomotives, deux en traction en tête du train et une en poussée en queue de train.Cette fonctionnalité est implantée aussi bien dans les trains de marchandises que devoyageurs.

– La commande/surveillance des équipements des rames

La commande et la surveillance des équipements des rames de typeouverture/fermeture des portes, mise en marche/arrêt de la climatisation, deslumières... concernent aujourd’hui les trains de voyageurs, notamment les TGV.Cependant le multiplexage des trains de marchandises peut laisser envisager lasurveillance des voitures et, également, celle de l’état des marchandises parl’adjonction des capteurs adéquats [Lozac’h et al. 1998].

D’autres fonctionnalités mises en réseaux ou candidates au multiplexage dans destrains de voyageurs ou des trains de marchandises sont :

– Le frein électronique

Un des objectifs du frein électronique est l’amélioration du système de freinageréparti des trains par une réduction des différences dans les délais de réception del’ordre de commande de freinage d’une voiture à l’autre.

Dans le cas du frein pneumatique équipant les trains de fret [Brisou 2002], latransmission des consignes de freinage émises par le conducteur est réalisée aumoyen d’une conduite pneumatique appelée « Conduite Générale de freins » (CG).Cette conduite parcourt l’ensemble du train. Elle est maintenue, dans le cas le plus

Introduction aux réseaux de communication embarqués à bord des matériels roulants guidés


courant d’un frein à air comprimé, sous une certaine pression d’air comprimécorrespondant à l’état des freins desserrés. Toute baisse de pression conduit alors àune application des freins de l’ensemble du train.

Les inconvénients de ce frein sont les suivants. Dans les phases transitoiresd’établissement et de relâchement du freinage, il ne permet pas une simultanéité de la commande des freins entre la tête et la queue des trains lorsque la conduite générale atteint une certaine longueur [Brisou 2002]. La vitesse depropagation d’une variation de pression dans la conduite est en effet au plus égaleà la vitesse du son. Ainsi, pour un train de 750 mètres et une conduite de commandeparfaitement rectiligne, le dernier véhicule commence à freiner 3 secondes après lepremier.

Avec une consigne de freinage transmise par un réseau de communication venant en remplacement de la conduite générale (frein électronique ou ici frein électro-pneumatique), les différences entre les délais de réception de cet ordre par les voitures seront réduites. Une meilleure diffusion de la consigne defreinage permettra alors d’augmenter la longueur des trains (actuellement limitée à 750 mètres pour les trains de marchandise). Pour cette fonction, les commandes par bus informatique et par radio sont toutes deux étudiées [Witte et al. 2001].

D’autre part, avant chaque mise en service d’un train, la vérification dufonctionnement correct de ce système de freinage nécessite actuellement qu’untechnicien aille prendre une mesure du niveau de dépression d’air à chaqueextrémité du train.

Un autre apport de la mise en réseau des équipements de freinage sera alors laréduction du temps de mise en service du train en permettant un diagnostique enligne du fonctionnement du freinage et de la commande de freinage [Witte 1998 ;SNCF 1999]. Ce diagnostique sera possible par un retour d’information sur laconsole du conducteur de l’état des équipements.

Cette fonctionnalité, aujourd’hui envisagée pour les trains de marchandises, est àl’état de recherche pour le frein pneumatique européen de l’UIC (« UnionInternationale des Chemins de fer »). Un frein à assistance électrique existe, maisla ligne électrique transmettant la consigne vient en redondance de la conduitegénérale. Des trains de fret équipés du frein électronique ECP (ElectronicallyControlled Pneumatic brake) de l’AAR (Association of American Railroad) sont enexploitation en Amérique du Nord, en Afrique du Sud et en Australie depuis 2-3 ans[Brisou 2002]. Là encore la commande électronique redonde la conduite généralede frein.

– La vérification de l’intégrité des trains

L’installation de réseau embarqué dans les trains de fret devrait permettre, d’unepart, de connaître à tout moment la configuration du train et l’état des équipementsdes voitures et, d’autre part, d’être informé de tout changement dans la compositiondu train (ajout, suppression ou perte d’un wagon).



– L’information voyageur

Elle concerne aujourd’hui l’affichage de la destination des voitures, des numérosde voitures et numéros de places. L’affichage de la route du train est effectué surdes écrans à l’extérieur des trains, près des portes d’accès, et à l’intérieur, dans leszones d’embarquement. L’utilisation d’un récepteur GPS permettra égalementl’affichage de la prochaine station dans les voitures du train [Fabri et al. 1999]. Unaffichage de la réservation des sièges par l’intermédiaire de LED servira d’autrepart à informer les passagers de places libres. Cette information, récupérée à borddu train au moyen d’une disquette ou d’une liaison GSM [Fabri et al.1999], seradiffusée sur l’ensemble du train via le réseau filaire de communication interne.L’information voyageur pourrait servir à la diffusion d’information vidéo. Elle estutile pour les trains de voyageurs, notamment les TGV.

– La maintenance

Enfin, avec le multiplexage des applications du train, le réseau pourra êtreégalement utilisé à l’anticipation de la maintenance en autorisant la collecte desdéfauts détectés dans les véhicules et leurs rapatriements vers le sol.

L’introduction et les choix des réseaux de communication à l’intérieur des trains fontface à de fortes contraintes liées à l’environnement des matériels roulants guidés et à laparticularité de l’application train :

– Les contraintes liées à l’environnement ferroviaire

Celles citées dans [Poitevin 2000] sont notamment une large plage de températurede – 30 ˚C à + 70 ˚C ; des vibrations importantes en provenance du roulementFer/Fer et de la motorisation ; une pollution électromagnétique sévère enprovenance notamment de la caténaire, des équipements de traction et desconvertisseurs statiques ; une pollution importante par des poussières, y comprisdes poussières métalliques ; une corrosion importante des parties nues (contacts deconnecteurs) induite par une condensation fréquente. Les équipements embarqués,en particulier les coupleurs et média de communication des réseaux, sont doncsoumis à de fortes contraintes matérielles. Les champs électromagnétiques peuventinfluer sur les signaux transmis, les vibrations peuvent être cause de microcoupuresau niveau du médium de communication [Duhot 1989].

– Des contraintes relatives à l’application train

Elles concernent le caractère re-configurable du système train en coursd’exploitation. Par exemple, la configuration du train peut être modifiée en gare,typiquement le nombre de voitures d’un train peut augmenter ou diminuer. Parconséquent, un réseau de communication parcourant un train doit pouvoirsupporter l’ajout ou la suppression d’entités connectées. Un exemple est celui dedeux rames de TGV où les deux réseaux de communication autonomes des deuxrames découplées doivent pouvoir être transformés en un unique réseau decommunication après couplage des rames. Inversement, le découplage de ces ramesdevra induire une transformation du système « réseau de communication » en deuxsystèmes « réseau de communication » autonomes. Une autre difficulté, rencontrée



lors de l’ajout de véhicules à un train, est celle de l’interopérabilité de systèmes« réseau de communication » hétérogènes. Enfin, la longueur des trains et de sesvéhicules nécessite des réseaux de communication de près de 1 km pourl’interconnexion d’équipements répartis dans un train ou jusqu’à environ200 mètres pour ceux interconnectés au sein d’un véhicule [TCNspecifications1998].

D’autres contraintes liées à l’application sont la disponibilité de la communication etl’aspect temps réel [Duhot 1989]. Les réseaux embarqués pouvant remplacer descentaines de lignes à bord du train, la disponibilité ne doit pas être affectée par un défaut.L’aspect temps réel nécessite un délai d’acheminement des ordres borné.

D’autre part, l’impact du marché ferroviaire ne peut non plus être négligé :

– la période d’amortissement des véhicules ferroviaires guidés est de 15 à 30 ans, cequi nécessite de pouvoir garantir la pérennité des équipements embarqués durantcette période ou du moins de pouvoir les faire évoluer progressivement ;

– la disponibilité du matériel dans le pays et l’expérience acquise du réseau decommunication peut être également importante. Remarquons que [Poitevin 2000]constate une forte influence entre le pays d’origine d’un réseau de communicationembarqué et son développement géographique malgré la mondialisation desmarchés. Ainsi, si l’on considère les deux réseaux constituant la normeinternationale IEEE 1473 ratifiée en 1999 [IEEE_1473 1999], le réseau decommunication américain LONWORKS est essentiellement implanté dans les paysanglo-saxons (Etats-Unis, Canada, Australie...) et le réseau de communication TCN(Train Communication Network), développé à l’aide d’un financement de l’UnionEuropéenne, est aujourd’hui utilisé notamment dans des trains circulant enAllemagne, en Suisse et en Italie.

3. Quelques réseaux embarqués ou candidats aumultiplexage

3.1 Exemples de réseaux embarqués

Les premiers réseaux filaires de communication embarqués à bord des matérielsroulants ferroviaires ont été des réseaux spécifiquement conçus pour les besoins duferroviaire. En France, un des premiers besoins exprimés a été la réduction del’engorgement des câbles servant à la transmission des ordres d’une rame de TGV àl’autre.

ALSTOM a ainsi conçu le réseau TORNAD qui équipe les rames du TGV Atlantiquemis en exploitation en 1988 [Duhot 1989], mais aussi la ligne D du métro de LyonMAGGALY (tableau 1). Sur la ligne de métro, ce réseau « relie par rame sur la mêmeboucle deux pilotages automatiques, deux systèmes traction freinage et deux automatesprogrammables de 300 entrées sorties chacun », ce qui fait douze équipements connectéssur la même boucle dans le cas de deux rames accouplées [Duhot 1989]. Dans la rameTGV Atlantique « composée de deux motrices et dix remorques », « TORNAD parcourtl’ensemble de la rame et assure la communication entre dix-huit calculateurs en unité



simple et le double en unité multiple. Chaque remorque est équipée d’un calculateur quiassure les fonctions » anti-enrayage2, test, mémorisation des portes, climatisation,éclairage, sonorisation, instabilité bogies et indications voyageurs. « Dans la motrice,deux calculateurs commandent les moteurs synchrones et deux autres assurent lesfonctions » guide de dépannage, essais freins et cab signal3, transmission de données versle sol, préparation de la rame avant départ et mémorisation de défauts. « Ces fonctionsfont appel à TORNAD. La consigne d’effort de traction vers les moteurs passe dans leréseau » [Duhot 1989]. Outre ce réseau TORNAD, la rame du TGV Atlantique embarque,d’après [Poitevin 2000], la technologie CAN pour la commande et la synchronisation deséquipements de traction (tableau 1).

Tableau 1 : matériels équipés des réseaux TORNAD et CAN [Poitevin 2000 ; Duhot 1989]



Le réseau TORNAD* (lire TORNAD « Etoile ») d’ALSTOM a ensuite remplacé leréseau TORNAD sur les nouvelles rames de TGV mises en exploitation de 1992 à 1997([Brun et al. 1994] cité dans [Poitevin 2000]). Là encore, la technologie CAN est utiliséed’après [Poitevin 2000] pour la commande et la synchronisation des équipements detraction (tableau 2).

Fonctionnalités multiplexées parTORNAD : Unité Multiple, Réversibilité, Contrôle de la rame.

CAN : Commande et synchronisation des équipements de traction.

Année Exploitant Matériel Nombre

1988 SNCF TGV Atlantique 105*

Ligne D du métro de LyonMAGGALY

* Soit 210 motrices et 1 050 voitures.

2 Le dispositif électronique d’anti-enrayage sert à éviter un blocage, d’où glissement, d’un ouplusieurs essieux lors du freinage, grâce à une régulation de l’effort de freinage. Il permetainsi une utilisation optimale de l’adhérence entre la roue et le rail. Il minimise la distance defreinage et évite la formation de méplats sur les roues (définition de [Deufrako 1993]).3 « cab signal » ou « signalisation en cabine » : indication, sur le pupitre de conduite, de lavitesse maximale autorisée sur une section de ligne. Cette indication est fournie par undispositif installé en cabine pour les trains circulant à plus de 200 km/h avec le concours decircuits de voie utilisant une transmission continue de fréquences porteuses par les rails oude balises (KVB, « K contrôle de vitesse par Balise », TVM, « Transmission Voie-Machine »...).Ce dispositif contrôle le respect par le conducteur des consignes de sécurité et provoquel’arrêt d’urgence en cas de besoin [Deufrako 1993 ; Berbineau et al. 1990].



Tableau 2 : matériels équipés du réseau TORNAD* [Poitevin 2000]

Matériels équipés du réseau TCN ou MICAS-S2 (système de contrôle de traction dont le réseau a été lemodèle pour TCN [Scheinder et Vitins 1996]) [Poitevin 2000]Fonctionnalités multiplexées :


Unité Multiple, Réversibilité, contrôle de la rame

1989 DB ICE 1 601996 ICE 2 22Unité Multiple, Réversibilité

1992 SBB CFF FFS Re 450 1151996 Re 460 119Interconnexion des réseaux des locomotives et des triplettes

1993 EuroTunnel Navette Tourisme* 27

Unité Multiple, Réversibilité, contrôle de la rame

1993 EuroTunnel BoBoBo 9000 38 [Machefer Tassin1998 BoBoBo 9100 et Julien 1994]

51997 SBB CFF FFS IC 2000** 250

Réversibilité, contrôle de la rame

1987 FS Pendolino*** ETR 450 151993 Pendolino ETR 460 101997 Pendolino ETR 480 151996 Pendolino ETR 500 30

Contrôle de la rame

Pusan Métro

* Le réseau des navettes tourismes d’EuroTunnel est fourni par EKE. Le débit est de 250 kbit/s et lesniveaux électriques sont conformes à la norme RS485.** Les voitures IC 2000, incluant pour la version Bt une cabine de réversibilité, sont destinées à former unetrentaine de rames-bloc, tractées par une locomotive Re 460.*** Le réseau du Pendolino, analogue à celui de TCN, provient de EKE.

Tableau 3 : matériels équipés du réseau TCN ou MICAS-S2 [Poitevin 2000]

Fonctionnalités multiplexées parTORNAD* : Unité Multiple, Réversibilité, Contrôle de la rame.

CAN : Commande et synchronisation des équipements de traction.


1992 SNCF TGV Réseau bicourant 50TGV Réseau tricourant 30TGV R tricourant PBA 10

1992 SNCF TGV Transmanche 161992 SNCB « 41993 Eurostar UK ltd « 111995 Eurostar UK ltd « (North Of London) 7

1995 SNCF TGV DUPLEX 30

1996 SNCF TGV PBKA (Thalys) 61996 SNCB 71996 NS 21997 DB 2

Fonctionnalités multiplexées parIntel BITBUS : Contrôle des portes, éclairage, alarmes... [Julien et al. 1994]


1993 EuroTunnel* Voiture Tourisme 252(triplettes**)

* Les matériels roulants d’EuroTunnel sont équipés de trois réseaux (un pour les locomotives, ici ABBMICAS-S2 [Machefer Tassin et Julien 1994], un pour les « triplettes » et un fédérateur pour le train.** Une triplette est un ensemble indéformable de 3 voitures « Tourisme », assemblées par 9 pour former untotal de 9 navettes tourisme de 27 voitures.



Toujours dans le registre des trains à grande vitesse et à la même époque, on peut citer l’utilisation en Allemagne (train ICE – InterCity Experimental) et en Italie (train Pendolino), par exemple, du réseau TCN (Train Communication Network).Son intégration dans ces trains autorise un fonctionnement des rames en unité multiple, la réversibilité et le contrôle de la rame. Quelques exemples d’intégration sont cités dans le tableau 3, d’autres pourront être trouvés dans [ROSIN_URLd] quidonne une liste de projets en cours réalisés par Adtranz et Siemens et basés surl’intégration de TCN.

On retrouve également l’utilisation d’un réseau TCN dans les trains de voyageurs exploités par EuroTunnel, réseau utilisé conjointement à un bus BITBUS en 1993 (tableau 4) et sans doute, d’après le tableau 5, à un réseau WorldFIPen 1997-1998.

Tableau 4 : matériels équipés du réseau Intel BITBUS [Poitevin 2000]

Tableau 5 : utilisation d’un réseau WorldFIP dans des applications ferroviairesd’après [WorldFIP_News 1999]

Années Evolution de la technologieWorldFIP

Application du réseauWorldFIP

1997-1998 HIFLIRTS : système de communicationà haute intégrité pour le transportferroviaire léger

Métro Auber : en stationEurotunnel : NavetteBelgique : locomotive de fret

1998-1999 Université de Birmingham :« predictive condition monitoring ofrailway infrastructure »

Météor (Paris) : ligne de métrocomplètement automatiséeEuro : locomotive de fret

1999-2000 Intégration sur WFIP de communicationvoix (paquets de sons)

Singapour, Varsovie et Shangai : métrosDublin : Tramway

2000-2001 WorldFIP vidéo à 5 Mbit/s Inclinaison TGV (tilting)

2001^ WorldFIP HSF à 25 Mbit/sApplication Internet/WorldFIP intégrantdes serveurs web sur WFIPCommunication d’image video sur HSF

ALSTOM : conception des trams« optionic » : systèmes de métros, lignessub-urbaines, trains inter-cité et TGVIntégration future de communicationpassager (son et image) et contrôle du conditionnement sur WFIP, HSF(High Speed Fieldbus)



En Europe, les trains à grandes vitesses ont donc fait appel à des technologies dédiéesTORNAD, TORNAD* et TCN pour la communication inter-rame et le contrôle desrames, en combinaison parfois avec des réseaux non-dédiés tels que BITBUS, WorldFIPou CAN.

Dans le cas des trains de fret, un premier essai d’utilisation d’une liaison filaire est celle, en France, de la liaison MUX G (Multiplexage généralisé). Cette liaison filaire MUX G a été une première réponse de la SNCF au multiplexage de la commande de réversibilité des trains, commande qui a permis une simplification desmanœuvres en gare et donc un gain de temps [Boutonnet et Chateaureynaud 1989a]. Cemultiplexage MUX G autorise également la commande simultanée de plusieurslocomotives (train en unité multiple – UM) [Menoux 1993]. Une technique demultiplexage similaire à celle présentée dans [Boutonnet et Chateaureynaud 1989a] a été réalisée en Ecosse [Avery et Crawshaw 1984]. Ce type de liaison filaire présente les caractéristiques d’un réseau de communication local de type bus. Les fonctionnalités multiplexées en 1990 et en 1994, selon [Sauvestre 1993 ; Menoux 1993 ;Carrere et al. 1994] cités dans [Poitevin 2000], sont le fonctionnement de locomotives en unité multiple (UM), la réversibilité et le contrôle de la rame (tableau 6). On retrouve également d’autres technologies, telles que les réseaux WorldFIP (tableau 5) ouTCN par exemple.

Tableau 6 : matériels équipés de télécommande par multiplexage [Poitevin 2000]

Fonctionnalités multiplexées parMUX G : Unité Multiple, Réversibilité, Contrôle de la rame.


1990 SNCF BB 9200 10BB 25200 18

1994 SNCF BB 9700* 4BB 16100* 15Voitures V2N* 151

* Matériel qui permet la constitution de 11 rames-bloc.

Toujours dans le cas des trains de marchandises, de nombreuses recherches sontactuellement en cours en Europe pour la réalisation d’un frein électronique. On peut citercelle expliquée dans [Witte 1998] utilisant la technologie CAN. Plus récemment, laSNCF et la DB (Deutsche Bahn) expérimentent dans le cadre d’une collaboration franco-allemande l’utilisation de la technologie LONWORKS [Grasso et al. 2001 ; Witte et al.2001].

Cette technologie américaine non dédiée, LONWORKS, est utilisée depuis 1996 sur desmatériels roulants aux Etats-Unis, au Canada et en Australie pour le contrôle des freins,des systèmes de traction ou de la rame comme le montre le tableau 7.

Ce premier paragraphe a donc permis de lister un ensemble de réseaux decommunication qui ont été embarqués au sein de matériels ferroviaires roulants. Cette liste ne se veut pas exhaustive. D’autres réseaux, tels que le réseau decommunication allemand IBIS, dont le nom apparaît dans la littérature mais pour lequel nous n’avons pas d’informations techniques, peuvent également avoir étéembarqués dans des matériels ferroviaires guidés. L’intégration du multiplexage a menéd’une part à la conception de nouvelles technologies de réseaux de communicationspécialisés (MUX G, TORNAD*, TORNAD, TCN) et d’autre part à l’utilisation detechnologies existantes (BITBUS, CAN, WorldFIP, LONWORKS). Ce second choixd’adapter des solutions existantes aux besoins du ferroviaire répond à une demande dedisponibilité des composants et de réduction des coûts (coûts d’étude et dedéveloppement du réseau).



Fonctionnalités multiplexées par LONWORKS :

Contrôle des freins et de la rame


1996 BART*1 Voitures métro 9001 « Baie Area Rapid Transit network » (San Francisco) [DOHEN 1985]. Les aspects relatifs à lasécurité ne sont pas pris en charge [ECHELON 1997]. Certaines voitures devraient être équipées pour un essai de compatibilité avec le réseau TCN [McGean 1999].

Contrôle des freins (Knorr)

1996 AAR2 Locomotives 30Wagons 840

2 Différents réseaux de l’« Association of American Railroads ». L’ensemble forme 7 trains de120 wagons. Il utilise une ligne d’alimentation du train et dans certains cas un réseau FT 10. Les aspects relatifs à la sécurité ne sont pas pris en charge [Echelon 1997].

Contrôle des portes et affichage ; contrôle des freins (Knorr)

1996 NJ Transit*3 Métro 963 « New Jersey transit authority » (Trains de banlieue de New York). Les aspects relatifs à la sécurité ne sont pas pris en charge.

Contrôle des systèmes de traction, d’air conditionné, de système de freinage, auxiliaires...

1996 Kuala Lumpur*4 Métro 704 Le réseau fédère les informations provenant des différents systèmes pour une aide à la conduite et à la maintenance. Les aspects relatifs à la sécurité ne sont pas pris en charge.

Interphonie numérique

1996 Australie* Voitures 15

Contrôle de l’énergie (chauffage, ventilation, air conditionné)

1996 DB* Train (expérimental) 2

Contrôle traction freinage

1999 Canadien National Rames (expérimentation) 3

* Utilise un réseau FT-10 en topologie libre.

Tableau 7 : matériels équipés du réseau LonWorks [Poitevin 2000]

3.2 Origine des réseaux de communication cités

Le panorama effectué ci-dessus a montré que les premiers essais de multiplexageeffectués ont mené à la conception de nouveaux systèmes réseaux (liaison MUX G,réseaux TORNAD et TORNAD* en France, mais également en Allemagne, Italie etSuisse par exemple avec la définition des bus de communication qui sont à l’origine duréseau TCN). D’autres réseaux de communication (CAN, WorldFIP, BITBUS,LONWORKS) en provenance d’autres secteurs d’activités ont également fait l’objetd’intégration.

Face à l’ensemble de ces solutions techniques, afin d’assurer une interopérabilitéentre les différentes solutions existantes et permettre l’interconnexion de véhicules enprovenance de différents pays, le réseau de communication TCN (Train CommunicationNetwork) a été spécifié dans le cadre de l’IEC (International ElectrotechnicalCommission ou CEI en français pour « Commission Internationale Electrotechnique »[IEC_URL]). Des applications ont alors été étudiées à l’occasion du projet européenROSIN4 (acronyme de Railway Open System Interconnection Network) [ROSIN_URLa].Dans ce même souci, cette technologie, récemment normalisée sous le nom de IEC61375-1, ainsi que la technologie LONWORKS [Echelon 1999 ; Chervet 1998 ; Sullivan1998] ont été retenues en tant que standard IEEE (IEEE 1473-L pour la solutionferroviaire LONWORKS et IEEE 1473-T pour la solution TCN) [IEEE_1473 1999 ;ROSIN_URLa].

Mais malgré ces normalisations européennes et internationales, c’est encore un autreréseau, le réseau PROFIBUS, qu’il est question d’embarquer à bord des trains à grandevitesse en Europe pour les applications embarquées de contrôle ERTMS (European RailTraffic Management System). Rappelons que le but d’ERTMS est de permettre à tout typede train, équipé du système de contrôle-commande et de signalisation ETCS (EuropeanTrain Control System), de pouvoir circuler sur toute ligne européenne [ERTMS_URL].

Ce n’est donc pas sans raison que Dominique Paret s’exclame ainsi, dansl’introduction de son livre sur le réseau CAN [Paret 1996] : « Il s’agit encore d’un autrebus ! Mais quand donc s’arrêtera-t-on de créer de nouveaux bus et normalisera-t-on toutcela ? ». Il explique ensuite qu’il « n’est pas facile de mettre tout le monde d’accord ;



4 Le projet européen ROSIN de la DGXIII (Telematics Application Programme TransportSector) a duré de juin 1996 à avril 2000. Les partenaires était ANSALDO Trasporti SpA (ATR)(coordinateur – Italie), Laboratori Fondazione Guglielmo Marconi srl (sous-contractant –Italie), FIREMA Trasporti SpA E.M.T. (contractant – Italie), SIEMENS Verkehrstechnik AG(contractant – Allemagne), Adtranz Sweden (contractant – Suède), Adtranz Germany –Mannheim (contractant associé – Allemagne), Adtranz Switzerland Ltd (contractant associé –CH), ABB Corporate Research (sous-contractant – CH), Alstom Transport SA (GAT)(contractant – France), Construcciones y Auxiliar De Ferrocarriles SA (CAF) (contractant –Espagne), Adtranz Germany GmbH (contractant – Allemagne), Union Internationale desChemins de Fer (UIC) (partenaire sponsor – France), Union Internationale des TransportsPublics (UITP) (partenaire sponsor – Belgique). Le groupe utilisateur était composé de : UIC(Union Internationale des Chemins de Fer), EuroTeam (UITP – Belgique), NS Materieel (NL),ÖBB Technische Services (AT), SNCF (France), DB (Allemagne), Ferrovie dello stato (Italie),Azienda Trasporti Municipali (Italie), ET/FV S.A. (Eusko Trenbideak/Ferrocarriles Vascos –Espagne).

surtout lorsque chacun a des souhaits et des exigences techniques particulières et qu’ilexiste des marchés suffisamment importants pour justifier et optimiser chaque concept(comprenez... réduire le coût) », et conclut par « Voici donc un nouveau bus série à notrearsenal déjà important de réseaux locaux. »

La question du choix d’un réseau de communication local est une question récurrente,quel que soit le secteur d’applications. Il n’est pas facile d’y répondre, ni techniquement,ni commercialement (quel réseau subsistera-t-il demain ? Ses composants seront-ilsdisponibles ?). Les normalisations de réseaux locaux, la course aux standards, essaient derésoudre le problème du trop grand nombre de solutions, mais sans succès puisquechaque nouvelle norme commune juxtapose un certain nombre de solutions noninteropérables [Thomesse 1998]. Ainsi, nous n’essayerons pas d’y répondre, mais nousnous attacherons à mettre en valeur techniquement les différences ou ressemblances dechacun des réseaux cités selon différents critères, parmi lesquels on peut citer leurtopologie (c’est-à-dire la façon dont les équipements sont connectés les uns aux autres),leur médium de transmission (le support physique via lequel les données sonttransmises), leurs protocoles (soit les règles d’échanges de données, de codage desdonnées transmises...).

Dans ce contexte, les réseaux embarqués à ce jour, dont les caractéristiques de lacouche physique et de la méthode d’accès (partie inférieure de la couche liaison dedonnées) font l’objet de ce rapport dans la limite de l’information à notre disposition, sontdonc les solutions dédiées et non dédiées suivantes :

a. Les solutions dédiées

La liaison filaire MUX G

MUX G (« Multiplexage Généralisé ») a été une première réponse de la SNCF aumultiplexage de la commande de réversibilité des trains de marchandises. Cettecommande a permis une simplification des manœuvres en gare et donc un gain de temps[Boutonnet et Chateaureynaud 1989a].

Les réseaux TORNAD et TORNAD*

Les réseaux TORNAD et TORNAD* sont des réseaux propriétaires conçus parALSTOM (anciennement Alsthom) pour le TGV. Leurs topologies respectives sontl’anneau (TORNAD) et le bus (TORNAD*). Nous n’avons pas trouvé d’informations surle protocole TORNAD* sinon que son accès au médium est basé, comme celui deTORNAD, sur la possession d’un jeton mais avec une topologie bus. Nous évoquerons doncd’avantage le réseau TORNAD décrit dans [Duhot 1989] et [Duquesnoy et Kieken 1986].

Le réseau TCN

Le réseau de communication de données TCN (Train Communication Network) a étéspécifiquement conçu pour les applications embarquées sur matériel roulant ferroviaire.Il permet l’interconnexion d’équipements programmables situés à l’intérieur d’un mêmevéhicule et dans différents véhicules [TCNSpecifications 1998]. Pour cela sonarchitecture est définie comme une structure hiérarchique comportant un bus véhicule etun bus train. [TCNSpecifications 1998] spécifie notamment deux bus de communication :le bus véhicule MVB (Multifunction Vehicle Bus) pour l’interconnexion des équipements



standards situés à bord d’un véhicule, le bus train WTB (Wire Train Bus) pour celle desvéhicules d’un train « ouvert » tel que les trains internationaux UIC. La définition du busMVB repose sur l’expérience acquise sur 200 locomotives en service en Suissenotamment. Celle du bus WTB repose sur le standard allemand DIN V 43322 utilisé surle train allemand ICE et le train rapide italien CD450 [Kirrmann et Zuber].

Ce réseau a été normalisé IEC 61375-1 en octobre 1999 par le groupe 22 du comité 9de la Commission Internationale Electrotechnique (IEC TC9 WG22) en collaborationavec le Groupe pilote 5R de l’Union Internationale des Chemins de Fer (UIC 5R). Unnouveau groupe IEC TC9 WG38 étudie depuis juillet 2000 la possibilité d’une nouvellenorme TCN pour le test de conformité (IEC 61375-2) [ROSIN_URLa]. La même année,la société « IEEE Vehicular Society » incluait TCN dans son standard IEEE 1473-1999sur les protocoles de communication embarqués dans les trains sous la dénominationP1473-T. LONWORKS est le second protocole intégré dans cette norme sous le nomP1473-L.

b. Les solutions non dédiées

Le réseau BITBUS

Le réseau de terrain BITBUS a été créé et développé par Intel en 1983. Il est devenuun standard en 1990 (standard IEEE-1118 1990). Le réseau BITBUS est supporté parl’organisation BEUG (BITBUS European Users Group) en charge de la diffusion de cettetechnologie et de l’organisation d’une plate-forme pour un échange des expériences[BEUG_URL].

Les principales informations sur ce réseau inscrites dans ce document proviennent de[Ciame 1999] ou du site [BEUG_URL].

Le réseau WorldFIP

Le réseau de terrain WorldFIP, anciennement FIP5, a été créé en 1982 par un groupede travail français à la même époque que l’était le bus CAN par Bosch (1983-1984) et leréseau PROFIBUS (1985) en Allemagne. Il fait l’objet de la partie 3 de la normeCENELEC EN 50170 [EN_50170_1 :3 1996]. Les parties 1 et 2 de cette norme sontrespectivement dédiées aux réseaux P-NET et PROFIBUS. A l’époque, ces réseauxétaient connus sous le terme de réseaux de capteurs et d’actionneurs ou de réseauxd’instrumentations [Thomesse 1998].

Le réseau CAN

Le protocole CAN (Controller Area Network) a été le premier protocole decommunication conçu pour des applications embarquées à bord d’un véhicule. Il a étéspécifié et développé à l’origine par la société allemande BOSCH, puis avec Intel. Il estnormalisé ISO 11519-2 depuis 1994 [ISO 11519-1 :4 1994] pour les communications



5 FIP a été l’acronyme de « Flux d’Informations issues/vers le Processus » selon la premièreversion du livre blanc [FIP 1984] ou encore Flux Information Process, puis FactoryInstrumentation Protocol. Il est également celui de Fieldbus Internet Protocol depuis ladécision de 1998 d’introduire un produit intégrant le protocole Internet (IP) [WorldFIP_URL].

séries à bas débit embarquées à bord de véhicules routiers (soit un débit de transmissiondu réseau CAN sur une paire torsadée différentielle inférieur à 125 kbit/s). Les parties 1,3 et 4 de cette norme sont respectivement dédiées à des définitions et généralités sur lesréseaux de communication à basse vitesse pour les véhicules routiers (partie 1), au busfrançais VAN (Vehicle Area Network) issu d’une collaboration entre PSA et RNUR[Abou et Malville 1997 ; VAN_URL] (partie 2) et enfin (partie 3) au bus américain J1850[SAE_J1850 1995] proposé par la SAE (Society of Automotive Engineers [SAE_URL]).Le réseau CAN a été également normalisé en 1993 ISO 11898 [ISO_11898 1993/1995]pour les échanges d’informations digitales dans le cas d’une communication sur pairetorsadée différentielle à haut débit (jusqu’à 1 Mbit/s) pour des applications de contrôle-commande embarquées dans les véhicules routiers. Les spécifications du protocole CANsont également décrites dans [Bosch 1991].

Le réseau LONWORKS

Le réseau LONWORKS a été développé à la fin des années 1980 par la société EchelonCorp., Palo Alto, USA [Heffernan 1997]. Il réalise d’après [Heffernan 1997] une solutionde contrôle distribué pour de nombreuses applications qui incluent les bâtiments,l’industrie des procédés, l’automatisation, l’équipement. Dans le domaine des transportsferroviaires, ce réseau fait l’objet, avec le réseau TCN, de la norme internationaleIEEE 1473 votée en 1999. Dans le domaine des applications domotiques, une normeENV devrait inclure BatiBus, EIBUS, EHS et LONWORKS d’après [Thomesse 1999].

Echelon le définit comme un système réseau universel utilisable pour le contrôle. Ilest utilisé pour l’automatisation de l’industrie, des bâtiments et des maisons et dans letransport.

Enfin, un autre réseau non dédié, le réseau PROFIBUS, est couramment à l’étude pourles applications embarquées ERTMS.

Le réseau PROFIBUS

Le réseau de terrain PROFIBUS a été créé en Allemagne en 1985 à la même époqueque les réseaux FIP (1982) et CAN (1983-1984). Depuis 1989, il fait l’objet du standardallemand DIN 19245. En 1996, il a été ratifié pour la partie 2 de la norme CENELECEN 50170 [EN_50170_1 :3 1996]. La partie 3 de cette norme est dédiée au réseauWorldFIP. En 2000, le réseau PROFIBUS a été ratifié pour le standard internationalIEC 61158.

Le réseau PROFIBUS n’est actuellement pas embarqué à bord de trains. Ce réseau acependant été choisi pour les applications de contrôle ERTMS (European Rail TrafficManagement System), applications qui permettront à tout type de train de circuler surtoute ligne européenne [ERTMS_URL]. PROFIBUS est cependant déjà utilisé dansl’infrastructure ferroviaire pour les systèmes d’aiguillage.



Chapitre 2

Présentation des réseauxde communication ferroviaires

selon le modèle de référence OSI

1. Introduction au modèle de référence OSI de l’ISODevant l’impossibilité d’interconnecter les différents réseaux des constructeurs, un

sous-comité de l’organisation internationale de standardisation (ISO – InternationalStandard Organization) a été créé en 1977 afin d’établir une norme internationale pour latransmission de données par réseau. Le travail de ce sous-comité a donné lieu à lapublication en 1984 du modèle de référence OSI (Open System Interconnection)(normalisé ISO 7498).

Ce modèle a été prévu pour permettre « l’interconnexion de systèmes effectuéeconformément à des normes ISO [...] d’échange d’informations entre systèmes «ouverts»les uns aux autres à cet échange du fait de leur utilisation commune des normesappropriées » [EuroDicAutom_1]. Un système ouvert peut ainsi être un ordinateur, unterminal, un réseau ou tout autre équipement qui respecte des normes communes.

Ce modèle OSI est un modèle théorique dans lequel les relations entre un réseau etles services qu’il peut assurer sont représentées par une hiérarchie de couches deprotocole. Il est ainsi composé de sept couches (figure 1), chacune correspondant à unniveau d’abstraction du système. D’autre part, « chaque couche contient une ou plusieursfonctions comprises entre une limite logique supérieure et une limite logique inférieure. »Chacune « utilise les services des couches inférieures en même temps que ses propresfonctions pour créer de nouveaux services qui sont mis à la disposition des couches deniveau supérieur » [EuroDicAutom_2]. Pour chaque couche implantée par un réseau, unensemble de règles sémantiques et syntaxiques qui régit le comportement des unitésfonctionnelles au cours de la communication est défini [EuroDicAutom_3]. Cetensemble, appelé pour une couche n donnée « protocole de communication de lacouche n », permet la communication de cette couche n d’un équipement avec celle demême niveau n d’un autre équipement distant.


Figure 1 : les sept couches du modèle de référence OSI



Aucune donnée ne transite directement d’une couche n à une couche n distante. Ellessont tout d’abord transmises jusqu’au médium de communication via les services offertspar les interfaces des couches adjacentes (figure 2), puis elles transitent via les différentsnœuds du réseau, nœuds dont les couches basses (couches 1 à 3) traitent le message(acceptation, refus). Arrivé à la machine destinataire, le message qui les véhicule remontealors jusqu’à cette couche n.

Figure 2 : la communication entre couches OSI

Une présentation synthétique du modèle de référence OSI peut être la suivante. Lestrois couches hautes 5 à 7 (session, présentation et application) sont relatives àl’application et indépendantes du matériel (figure 1). Les couches basses 1 à 4 (physique,liaison, réseaux et transport) sont responsables du transport de données et dépendent dumatériel utilisé. A la transmission, la couche transport, décompose, si nécessaire, les

données en provenance de la couche immédiatement supérieure (couche session) enpaquets de taille plus petite de sorte à ce que chacun puisse être inséré dans la trame decommunication, propre au réseau choisi, qui circulera sur le médium de communication(figure 3). Les paquets formés sont alors transmis à la couche réseau.

Figure 3 : taille relative des informations manipulées par chacune des sept couches du modèle OSI [Rolin 1990]

Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI


Les trois couches inférieures 1 à 3 (physique, liaison et réseaux) se chargent alors del’acheminement avec contrôle d’erreur des paquets de la couche transport à travers leréseau [Mackenzie et Bettaz 1988]. La couche 4 (transport) assure l’interface entre lesfonctions liées à l’application (5 à 7) et celles directement liées à la communication (1 à 3).

Les fonctions des différentes couches du modèle de référence OSI sont maintenantrapidement présentées de la couche la plus haute à la couche la plus basse située au-dessus du médium de communication (support physique).

– La couche « application » ou « couche 7 »

Elle donne les moyens aux applications utilisateur d’accéder à l’environnementréseau. Elle est donc l’interface entre les processus utilisateur et l’environnementréseau (messagerie et transfert de fichiers font partie des services de cette couche).

– La couche « présentation » ou « couche 6 »

Elle concerne la représentation de l’information transmise, sa syntaxe et sasémantique. Quelques-uns de ses services peuvent être le codage des données, lacompression de données, le cryptage.

– La couche « session » ou « couche 5 »

Elle fournit des outils de synchronisation et de gestion de dialogue nécessaires auxéchanges entre utilisateurs distants. L’établissement d’une session entre deuxutilisateurs peut être utile pour permettre à l’un des utilisateurs de se connecter au système distant selon un mode d’accès à temps partagé ou encore pour letransfert d’un fichier de données de l’un à l’autre [Tanenbaum 1997]. Un desservices de cette couche est la gestion de dialogue, le trafic entre les utilisateurspouvant être bidirectionnel ou bidirectionnel à l’alternat. Dans ce second cas, leservice gestion de dialogue permet d’éviter les conflits d’accès à la ressourcepartagée par la gestion d’un « jeton » qui donne le droit de parole à la station qui lepossède. Un des services de synchronisation autorise, par l’insertion de points de reprise dans un flot important de données à transférer, de ne reprendre, après une panne, le transfert des données qu’à partir du dernier point de reprise inséré [Tanenbaum 1997].

– La couche « transport » ou « couche 4 »

Elle décompose si nécessaire les données de la couche session en paquets et créeune ou plusieurs connexions réseau par connexion transport requise par la couchesession (requête vers la couche réseau). Un mécanisme de contrôle des flux peutexister dans cette couche pour empêcher qu’une machine hôte ne sature unemachine plus lente. C’est un protocole de bout en bout en cela qu’une machinedestinataire échange des données avec une machine source en utilisant un mêmeprogramme identifié par le contenu des messages d’en-tête et de contrôle. Plusieursprogrammes hôtes pouvant être supportés par une même machine, l’en-tête de lacouche transport peut aussi permettre d’identifier les différentes connexionsentrantes et sortantes des machines distantes [Tanenbaum 1997].

– La couche « réseau » ou « couche 3 »

Elle réalise l’acheminement sans erreurs de paquets entre une station hôte et sonnœud de rattachement [Mackenzie et Bettaz 1988]. Elle détermine la façon dont les paquets vont être routés de leur source à leur destination et réalise un contrôlede flux des paquets afin qu’ils n’engorgent pas un sous-réseau. Différentesstratégies de routage existent basées sur une table de routage statique « câblée »,une table déterminée à l’initialisation ou une table recalculée dynamiquement[Tanenbaum 1997]. Cette couche, complexe dans des réseaux point à point, estsouvent inexistante dans les réseaux à diffusion, peu concernés par les problèmesde routage de l’information. Elle intervient lors de l’interconnexion de réseauxhétérogènes.

– La couche « liaison de données » ou « couche 2 »

Elle réalise le transfert sans erreurs de données à travers des liaisons point à pointou multipoints entre une station hôte et son nœud de transmission [Mackenzie etBettaz 1988]. Une de ses fonctions est l’assemblage des données sous la forme detrames de données, qui seront ensuite émises par la couche physique sous celled’éléments binaires. Afin de délimiter cette information émise, elle ajoutenotamment un délimiteur à chaque extrémité de la trame. D’autres fonctions sont



la transmission des trames en séquence, la gestion des acquittements, des erreurs(trames endommagées, perdues ou dupliquées), le contrôle des flux (empêcherqu’un émetteur rapide ne sature un plus lent) et l’accès au médium decommunication.

Afin de s’adapter à l’émergence des réseaux locaux, la norme ISO DIS 8802subdivise cette couche liaison de données en deux sous-couches (voir leparagraphe 2 de ce chapitre).

– La couche « physique » ou « couche 1 »

Elle est située au-dessus du médium de communication. Elle définit l’interfacemécanique, électrique et fonctionnelle entre une machine hôte et son nœud detransmission [Mackenzie et Bettaz 1988]. Elle définit notamment les niveaux dessignaux transmis et les débits de données. Cette couche est responsable de latransmission d’éléments binaires sur un médium de transmission [Tanenbaum1997]. Le support de transmission peut être une liaison filaire (fil en cuivre ou fibreoptique) ou sans fil (liaison infra-rouge, laser ou hertzienne, faisceaux hertziens,liaisons satellites).

En plus de ces 7 couches, le modèle de référence définit une entité « gestion deréseau » (Network Management – figure 1) :

– l’entité de « gestion de réseau », transversale aux sept couches, définit un ensemblede fonctions de paramétrage, de configuration, d’exploitation et de surveillancepour permettre le bon fonctionnement du réseau [Thomesse_R7574].

Le modèle de référence OSI est un modèle théorique qui nous permettra de comparerles différents réseaux de communication par l’examen des différents protocoles decommunication qui les composent. Comme nous le verrons, toutes les couches OSI ne sont pas implantées dans l’ensemble des réseaux de communication. Plusd’informations sur le modèle de référence OSI de l’ISO peuvent être trouvées dans [IEEE_Std_802 1990] ou encore dans de nombreux ouvrages dont [Tanenbaum1997].

Le paragraphe 2 suivant s’intéresse au modèle de référence IEEE 802 particulier auxréseaux de communication locaux et métropolitains, le paragraphe 3 présentera lesdifférentes méthodes d’interconnexion de réseaux locaux, enfin le paragraphe 4 traiterade la décomposition en couche, selon le modèle de référence OSI, des réseaux utiliséspour les applications ferroviaires embarquées.

2. Modèle de référence IEEE 802 pour les réseaux locaux

L’architecture des réseaux locaux est généralement définie selon le modèle IEEE 802[IEEE_Std_802 1990] (figure 4). Ce modèle est spécifié sur les deux couches basses dumodèle OSI, la couche physique et la couche liaison de donnée. Il propose unedécomposition de la couche liaison de données en deux sous-couches, la sous-couchebasse MAC (Medium Access Control ou « contrôle d’accès au médium ») et la sous-couche haute LLC (Logical Link Control ou « contrôle de liaison logique »). Lesfonctions des couches LLC, MAC et physique sont décrites ci-après.



– La sous-couche LLC (normalisé ISO 8802-2 et ANSI/IEEE Std 802.2) assure lecontrôle de flux entre stations voisines (c’est-à-dire connectées point à point ou àun même support de transmission). La sous-couche LLC IEEE 802.2 offre troistypes de services LLC :

• LLC Type 1, un service « sans connexion et sans acquittement »(unacknowledged connectionless) pour lequel il n’est pas nécessaire d’établir aupréalable de lien logique entre les entités communicantes. Chaque unité dedonnées est transmise comme un « datagramme » dans une trame nonnumérotée. Il n’y a ni accusé de réception, ni garantie de séquence, nirecouvrement d’erreur.

• LLC Type 2, un service « orienté avec connexion » (connection-oriented) pourlequel une liaison logique doit être établie avant tout échange de tramesd’informations. Les paquets de données transférés via les trames sont numérotéset délivrés en séquence. La couche LLC acquitte les paquets reçus et effectue unrecouvrement d’erreur.

• LLC Type 3, ce troisième service « sans connexion avec acquittement »(acknowleged connectionless) est un compromis entre les deux premiers. Il nenécessite pas l’établissement d’un lien logique entre les entités LLCcommunicantes avant tout échange de trames. Mais, un accusé de réception, quel’émetteur attend avant d’émettre toute nouvelle trame, est envoyé à chaquetrame reçue. Cet acquittement permet le recouvrement d’erreur etl’ordonnancement correct des trames. Ce troisième service autorise égalementqu’une station en scrute (interroge) une autre.

Figure 4 : décomposition de la couche liaison de données selon le modèle de référence IEEE 802



La sous-couche LLC est indépendante de la couche physique, elle utilise les servicesde la sous-couche MAC afin d’assurer le contrôle d’erreur de la couche physique et lacorrection de certaines erreurs par retransmission des trames erronées (services LLCtypes 2 et 3).

– La sous-couche MAC

Elle réalise, en support de la couche LLC, les fonctions d’accès au médium decommunication partagé, l’adressage et la reconnaissance des trames. Lors del’émission d’une trame, elle génère et insère dans la trame une séquence pour lecontrôle d’erreurs (FCS – Frame Check Sequence). Elle réalise également ladélimitation de l’« unité de données du protocole LLC » par l’insertion dedélimiteurs. A la réception, elle désassemble la trame reçue (suppression desdélimiteurs et de la séquence de contrôle) et vérifie l’intégrité de la trame au moyende la séquence de contrôle.

– La couche physique

Elle fournit les moyens de transmettre et de recevoir des bits entre deux entités dela couche physique, c’est-à-dire ceux nécessaires à l’émission et la réception designaux modulés affectés à différents canaux de fréquences spécifiques, dans le casd’une transmission large bande (broadband), ou affectés à un unique canal dansune bande de fréquences donnée, dans le cas d’une transmission en bande de base(baseband).

Elle se charge ainsi notamment du codage et décodage des bits, de la générationd’éléments de synchronisation et de délimitation de la trame MAC transmise(« bit(s) start », « bit(s) stop », « préambule » et « postambule »). Elle spécifieégalement le médium de transmission utilisé et la topologie.

La couche MAC est souvent spécifique au réseau, la même couche LLC pourra êtretrouvée pour différentes couches MAC. Les normes IEEE 802 (ou ISO DIS 8802)suivantes portent sur les spécifications de la couche physique et de la méthode d’accèsdes réseaux [IEEE_Std_802 1990] (figure 5) :

– CSMA/CD (norme ISO/IEC 8802-3 ou standard « ANSI/IEEE Std 802.3 ») ;

– Token-Passing Bus ou Token Bus (accès au médium par passage de jeton sur bus,norme ISO/IEC 8802-4 ou standard « ANSI/IEEE Std 802.4 ») ;

– Token-Passing Ring ou Token Ring (accès au médium par passage de jeton suranneau, standard « IEEE Std 802.5 ») ;

– métropolitains (MAN – Metropolitan Area Network, projet P802.6) ;

– intégrants « voix » et données (projet P802.9) ;

– sans fils (projet P802.11).

Les autres standards ou projets du groupe IEEE 802 sont [IEEE_Std_802 1990] :

– la norme IEEE Std 802.7 qui spécifie la couche physique et donne des conseils techniques et recommandations pratiques pour la transmission large bande ;

– le projet P802.8 qui spécifie la couche physique et donne des conseils techniquespour la transmission sur fibre optique ;

– le projet P802.10 qui porte les spécifications de la couche physique et de laméthode d’accès des réseaux sécuritaires dont les données sont privées.



Figure 5 : les groupes de travail IEEE 802 d’après [IEEE_Std_802 1990]



En plus des couches LLC, MAC et physique, une couche gestion de réseau « fournitun ensemble d’outils qui permet à des applications de gestion spécifiques de réaliser destâches de gestion à l’intérieur des stations LAN, telles que la gestion de confirmation, defautes, de performance ou de sécurité » [IEEE_Std_802 1990].

3. Equipements d’interconnexion pour les réseaux locauxIl existe quatre types d’équipements permettant l’extension d’un réseau local : les

répéteurs, les ponts, les routeurs et les passerelles. Dans le cas des réseaux WAN, desnœuds de commutation sont utilisés. Nous ne nous intéressons ici qu’aux quatre premierséquipements cités. Les informations fournies ci-dessous proviennent en grande partie de[DeLinares et VanCaeyseele 1989].

Les répéteurs (repeaters), ponts (bridges), routeurs (routers) et passerelles (gateways)interconnectent les réseaux à différents niveaux du modèle de référence OSI : la couche 1(physique) pour les répéteurs, la couche 2 (liaison de données) pour les ponts, la couche 3(réseau) pour les routeurs et enfin les couches supérieures pour les passerelles.

Les répéteurs « reçoivent des trains d’impulsions, les amplifient et lessynchronisent ». Ils interconnectent deux segments de même technologie d’un mêmeréseau afin d’en augmenter la longueur en palliant la dégradation des signaux électriques.

Les ponts interconnectent deux réseaux de technologies identiques dont les média detransmission peuvent être de natures différentes. Leur rôle est de filtrer et de relayer lestrames de la couche liaison de données d’un réseau à l’autre de sorte à ce que lesutilisateurs de chacun des deux réseaux interconnectés puissent accéder aux ressourcesde l’autre. Cela suppose une connaissance locale des adresses de chacun des réseaux.

Les routeurs interconnectent deux réseaux distincts dont les couches physique etliaison de données peuvent être différentes. Leur rôle est d’assurer « le routage etl’aiguillage des messages », à partir de la connaissance des adresses, afin d’acheminer unmessage d’un équipement source d’un réseau à un équipement destinataire d’un autreréseau. Les routeurs peuvent également assurer un rôle de filtrage des trames au niveaude la couche liaison de données, ils sont alors parfois appelés « ponts/routeurs ».

Les passerelles interconnectent deux réseaux hétérogènes incompatibles. Ellesassurent, en utilisant une partie ou l’ensemble des sept couches du modèle de référenceOSI, l’adaptation des deux réseaux. Elles convertissent les informations d’un format à unautre.

La conception de chacun de ces équipements est naturellement spécifique aux réseauxqu’ils interconnectent.

4. Décomposition en couches OSI des réseaux de communication « ferroviaires »

4.1 Observation générale

La figure 6 montre la décomposition en couches OSI des réseaux présentés dans cetteétude, soit huit réseaux qui ont déjà été embarqués sur des matériels roulants guidés(MUX G, TORNAD, TORNAD*, WorldFIP, BITBUS, CAN, LONWORKS, TCN) et unréseau dont l’utilisation est à l’étude à l’occasion des activités ERTMS (PROFIBUS).

Aucune référence n’a été trouvée sur le réseau TORNAD* et les références à notredisposition ne spécifient pas les couches implantées par la liaison MUX G. Lesinformations reportées sur ces deux réseaux sont donc des hypothèses élaborées d’aprèsla description de la liaison filaire MUX G dans [Boutonnet et Chateaureynaud 1989a] etpar similitude avec le réseau TORNAD, prédécesseur de TORNAD*, dont les couchessont en partie décrites dans [Duhot 1989 ; Duquesnoy et Kieken 1986].

Figure 6 : représentation des couches OSI des « réseaux embarqués ferroviaires »



Une observation générale de cette figure 6 montre que :

– quatre de ces réseaux sont définis sur les six ou sept couches du modèle deréférence OSI. Trois d’entre eux ont été spécifiés dès l’origine pour les applicationsferroviaires (TORNAD, TORNAD* et TCN). Le quatrième (LONWORKS, protocoleLonTalk), dont la couche physique n’est pas spécifiée dans le protocole, était déjà

couramment utilisé dans le secteur du bâtiment, notamment pour des applicationsde domotique.

– les autres protocoles (WorldFIP, BITBUS, PROFIBUS et sans doute MUX G) sontdéfinis sur les couches physique, liaison de données et application (1, 2 et 7).

Le protocole CAN l’est sur une partie de la couche physique et la couche liaison dedonnées (sous-couches MAC et LLC). Cependant, pour ce dernier protocole, denombreuses couches application propriétaires ou commerciales existentaujourd’hui (paragraphe 4.3 de ce chapitre).

– parmi l’ensemble des réseaux utilisés dans le ferroviaire, deux mettent en évidenceune couche « gestion du réseau » (WorldFIP et TCN). Cependant, l’absence decette couche dans une représentation ne signifie pas que des services permettantcette gestion du réseau n’existent pas au sein des différents protocoles du réseaucomme le montre l’exemple des protocoles CAN et PROFIBUS.

– outre les sept couches du modèle de référence OSI et la couche de gestion deréseau, une huitième couche, la couche utilisateur, est considérée dans lesprospectus techniques relatifs au réseau PROFIBUS. Cette couche concerne desprofils applicatifs définis en réponse à des besoins spécifiques de différentssecteurs d’activités industriels, par exemple du manufacturier (équipement de typevariateurs, codeurs, IHM...) ou du process (équipement de type transmetteur,positionneurs, E/S) [Profibus 1999].

Si maintenant, nous nous intéressons aux schémas, présentés dans les documentationstechniques ou autres publications publiques, qui représentent la décomposition encouches de ces réseaux, on comprend que cette représentation ne permet pas de lescomparer rapidement. Deux types de présentations peuvent être distingués selon qu’ellesmettent en valeur :

– un détail de fonctionnalités des couches du réseau relativement au modèle deréférence OSI ou

– des aspects hiérarchiques et/ou normatifs de différents protocoles composant leréseau.

Le premier cas a été rencontré lorsque le réseau de communication local est construitautour d’un protocole spécifique qui peut être ou pourrait être normalisé. On peut citer leréseau CAN basé sur le protocole CAN, le réseau LONWORKS basé sur le protocoleLonTalk ou encore le réseau propriétaire TORNAD (figures 7 à 10). La secondereprésentation est souvent observée lorsque le réseau de communication est composéd’un ensemble de protocoles dont certains sont normalisés (réseau TCN composé dequatre protocoles, réseau WorldFIP mettant en valeur les parties normalisées ou réseauPROFIBUS soulignant l’ensemble de ses profils et normes).

Les paragraphes suivants décrivent ces représentations selon le modèle de référence OSI.

4.2 Réseau TORNAD

La figure 7 représente les couches du réseau TORNAD relativement au modèle deréférence OSI de l’ISO d’après [Duhot 1989]. Elle met en valeur les caractéristiques



fonctionnelles du réseau et la répartition de ces fonctions sur les différentes couches dumodèle de référence OSI. Les coupleurs TORNAD, au moyen desquels sont connectéesles stations, couvrent les six premières couches. On en déduit raisonnablement que lacouche application est gérée par la station destinatrice elle-même.

Figure 7 : couches OSI et réseau TORNAD [Duhot 1989]



Ce réseau TORNAD et ses coupleurs spécifiques ont été réalisés par Alstom. Descoupleurs TORNAD, entièrement compatibles, ont également été développés par lasociété SAFARE-CROUZET.

4.3 Réseaux CAN et CANopen

4.3.1 Réseau CAN

CAN (Controller Area Network) est un protocole multi-maîtres multi-esclaves dont laspécification couvre une partie de la couche physique et la couche liaison de données(MAC et LLC). Les couches 3 à 6 sont vides. La couche 7, application, est à écrire parl’utilisateur. Comme nous l’avons précédemment signalé, des protocoles application sontcependant disponibles sur le marché. Le réseau s’appelle alors du nom de ces protocoles.

La figure 8 réunit les informations de deux tableaux de [Paret 1996 ; CANimpl 2000].Elle montre la répartition des différentes fonctionnalités de ce protocole sur les couches 1et 2 du modèle de référence OSI. [Bosch 1991] définit la couche physique et les deuxsous-couches MAC et LLC comme expliqué ci-dessous.

– Seule la partie haute de la couche physique est spécifiée. Elle décrit le rythmebinaire, le codage des bits et la synchronisation. La partie basse correspondant auxémetteurs récepteurs de ligne n’est pas définie afin d’autoriser une optimisation dessignaux sur le médium de transmission choisi en fonction de l’application cible.

D’après [CANimpl 2000], la sous-couche PS de la couche physique est superviséepar une entité de management appelée « gestion des défaillances de bus ».

– La sous-couche MAC implante le cœur du protocole CAN. Elle présente à lacouche physique les messages reçus en provenance de la sous-couche LLC et elleaccepte de la couche physique les messages à transmettre à la sous-couche LLC.Elle est responsable de la mise en trame des messages (message framing), del’arbitrage (arbitrage lors d’un accès concurrent sur le médium), de l’acquittement,de la détection et signalisation d’erreurs. Cette sous-couche est supervisée par uneentité de gestion de réseau appelée confinement d’erreur. Cette entité est unmécanisme « d’auto-vérification » qui distingue les perturbations temporaires desdéfaillances permanentes [Paret 1996 ; Bosch 1991].

– La sous-couche LLC se consacre au filtrage de messages (acceptation ou refus d’unmessage), à la notification de surcharge et à la gestion de recouvrement.

Figure 8 : organisation du protocole CAN selon le modèle ISO d’après [Paret 1996 ; CANimpl 2000]



La figure 8 met également en valeur les fonctions implantées dans les circuitscontrôleur de protocole CAN. Certaines de ces fonctions sont reprises sur la figure 9 quiprésente l’architecture fonctionnelle d’un circuit contrôleur de protocole CANs’interfaçant à un micro-processeur.

Les circuits contrôleur de protocole CAN intègrent un module contrôleur de protocoleCAN, un module matériel pour filtrer les messages en réception (« filtre d’acceptance »),une mémoire tampon pour les messages en réception, une autre pour ceux en émission et,enfin, une interface, soit CPU, soit application. La taille des mémoires tampon enémission et réception diffèrent selon les circuits CAN (figure 9). Différentes architecturesde nœuds CAN sont possibles selon le choix du circuit contrôleur de protocole(figure 10). Les circuits CAN autonomes (cas « A » de la figure 10) s’interfacent avec unmicrocontrôleur externe qui gère notamment son fonctionnement. Les circuitsmicrocontrôleurs intégrés avec un contrôleur de protocole CAN (cas « B » de lafigure 10) s’interfacent directement avec l’application. Il en est de même pour lescomposants CAN SLIO (Serial Linked I/O Device – cas « C » de la figure 10). Les nœudsSLIO, contrairement aux nœuds possédant une unité de traitement (CPU), ne peuventtransmettre que sur une demande d’un autre nœud. Les composants SLIO étant conçuspour l’interfaçage direct d’entrées/sorties digitales ou analogiques, sans traitement local,les nœuds SLIO peuvent servir comme extension des ports digitaux et analogiques d’unmicrocontrôleur distant sur le bus CAN.



Figure 9 : architecture d’un composant CAN [CANimpl 2000]

Il existe de nombreux composants CAN. L’organisme CiA répertoriait en avril 2001,sur son site web [CAN_cia_URL], 19 concepteurs de contrôleur CAN (dont ST-Microelectronics, NEC, Motorola, Fujitsu, Philips, Bosch, Intel) proposant un choix deplus d’une centaine de composants. Quelques exemples de composants existantaujourd’hui sont :

– des contrôleurs CAN 2.0B autonomes tels que le composant SJA1000 de Philips avecune interface CPU hôte de 8 bits, une mémoire tampon (buffer) pour la transmissiond’un message, une FIFO de 64 octets pour la réception de messages ; le composant82527 d’Intel offrant le choix d’une interface CPU 8 bits multiplexés (bus adresses etdonnées), 8 bits non multiplexés, 16 bits multiplexés ou série SPI, une mémoiretampon acceptant 14 messages, chacun configuré soit en émission soit en réception,une quinzième mémoire doublée pour la réception de message ; le composantMCP251 de Microchip avec une interface CPU série SPI et une mémoire de3 messages en transmission, une autre de 2 messages en réception... [IXXAT_URL] ;

– des circuits microcontrôleurs 8 bits, 16 bits ou encore 32 bits avec un contrôleurCAN 2.0B intégré tels que les composants C515/C505C d’Infineon avec un CPU de8 bits, une mémoire tampon de 14 messages en émission ou en réception, plus unemémoire doublée pour la réception de message ; le composant C167CR d’Infineonavec un CPU de 16 bits et également une mémoire tampon de 14 messages enémission ou en réception, plus une mémoire doublée pour la réception de message ;le composant MC68376 de Motorola avec un CPU de 32 bits et une mémoiretampon de 16 messages en émission ou en réception... [IXXAT_URL] ;



Figure 10 : différentes architectures de nœud CAN [Philips 1995]

– des circuits DSP avec un contrôleur CAN intégré tels que le DSP eCAN (enhancedController Area Network) TMS320F28x de Texas Instrument ;

– enfin, mais moins nombreux, des circuits CAN SLIO tels que le 82C150 de Philips.

4.3.2 Couches applicatives commerciales basées sur l’utilisation duprotocole CAN

Un certain nombre de couches application CAN est disponible sur le marché.Développées par différents secteurs d’activité, elles sont implantées de façon logiciellealors que le protocole CAN est implanté de manière matérielle (figure 8).

Les protocoles de la couche application développés par le secteur automobile sont lesprotocoles J1939 de la SAE (Society of Automotive Engineers aux USA), OSEK (OpenSystems and the Corresponding Interfaces for Automotive Electronics) du groupementEuropean Car Industries Users Group [Paret 1996]. Les protocoles les plus connusdéveloppés pour les systèmes de contrôle et les réseaux embarqués de l’industrie sont lesprotocoles application CAL (CAN Application Layer) du groupement CiA (CAN inAutomation), CANopen dont les spécifications sont basées sur CAL et qui a été ratifié en2002 par le comité de standardisation Cenelec pour être publié comme partie 4 de lanorme EN 50325 (EN 50325-4), DeviceNet de la société Allen Bradley, SDS (SmartDistributed System) de la société Honeywell ou encore pour des applications plusspécifiques CAN Kingdom de Kvasa [Paret 1996 ; CANappl 2000].

Parmi ces protocoles de la couche application, signalons l’utilisation dans lestransports de CANopen par BMW pour le bus hybride développé par Neoplan. D’autrepart, la CiA (CAN in Automation) a établi pour le secteur ferroviaire un « CANopen SIG6

Railways » spécifiant des profils d’équipements spécifiques tels que ceux nécessaires aucontrôle des portes, le contrôle du freinage et les passerelles aux systèmes du bus train.La CiA et VDV (Verband Deutscher Verkehrsbetriebe) ont également développé unsystème d’informations aux passagers utilisant ce protocole application. Le réseauCANopen devrait se substituer au réseau allemand IBIS utilisé sur du matériel ferroviaireallemand. Ce profil CANopen standardisé pour les transports publics devait être publiéau printemps 1999 sous le nom de CiA DSP-407 [CANappl 2000].

A titre d’exemple, regardons l’organisation de ce réseau CANopen. Il est basé surl’utilisation de la partie 1 et 2 de la norme ISO 11898 du protocole de communicationCAN (couche liaison de données et une partie de la couche physique – figure 11).

Le protocole CANopen décrit une couche application, un profil de communication etspécifie des fonctionnalités de communication additionnelles pour les équipementsprogrammables. Il complète également la couche physique du protocole CAN endéfinissant la durée des éléments binaires et en faisant des recommandations surl’affectation des broches des connecteurs. Ces recommandations sont à respecter pourassurer l’interopérabilité d’équipements conçus par des constructeurs différents.



6 SIG : Special Interest Group.

Les profils des équipements, des interfaces et applications « standardisés » spécifientle comportement par défaut et les fonctionnalités optionnelles des équipements,interfaces et applications [CANopen 2000].

Figure 11 : modèle de référence CANopen [CANopen 2000]



Figure 12 : profil CANOpen [IXXAT_URL]

La figure 12 présente les fonctions logicielles d’un profil CANopen. Le logiciel duprotocole CANopen peut être supporté par différents micro-processeurs et contrôleurs de protocole CAN (cas « A » et « B » de la figure 10). [IXXAT_URL] donne l’exempledes micro-processeurs des familles 8051 et C16x interfacés à un contrôleur CAN externeIntel 82527, Philips 82C200 ou Philips SJA1000 par exemple, ou encore, de micro-processeurs intégrant un contrôleur CAN tels que le Siemens/Infineon C505/515.

Plus d’informations sur ce réseau pourront être trouvées dans [CAN_cia_URL].

4.4 Réseau LONWORKS

Le protocole de communication du réseau LONWORKS est le protocole LonTalk(figure 13). Ce protocole est défini sur les six couches hautes du modèle de référence OSI. Lacouche physique n’est pas spécifiée autorisant ainsi l’utilisation de différents média decommunication et méthodes de codage des données, la méthode de codage choisie dépendantdu médium utilisé. Le chapitre 4 présentera plus en détail les couches du protocole LonTalk.

Une particularité des réseaux LONWORKS est l’implantation sous forme logicielle duprotocole LonTalk. Un circuit dédié, le « Neuron Chip », a été conçu pour exécuter ce logiciel.Il est composé de trois processeurs (figures 13 et 14) : un processeur Application, un processeurRéseau et un processeur MAC. Il existe deux familles de ce circuit « Neuron Chips », le Neuron3120 et le Neuron 3150. Le 3120 stocke directement l’applicatif. Avec le 3150, l’applicatif eststocké dans une mémoire PROM externe ou une flash re-programmable [Lorin 1995]. Ce circuit a été fabriqué jusqu’en 1999 par Motorola et Toshiba, puis par Toshiba et CypressSemiconductor suite à un changement d’orientation de la société Motorola annoncé en janvier1999. Echelon indique également que le code du protocole LonTalk, qui figure dans la normeANSI/EIA-709.1-A, peut être implémenté sur d’autres microprocesseurs que le « NeuronChip ». Les composants des réseaux de contrôle LONWORKS sont fournis par Echelon et sespartenaires ou des développeurs indépendants [Schickhuber et Mc Carthy 1997a ; 1997b].

Figure 13 : architecture du réseau de communication LONWORKS

d’après MOTOROLA_LonWorks



4.5 Réseau WorldFIP

La figure 15 tirée de [Azevedo et Cravoisy 1998] met en valeur la normalisation desquatre couches du protocole WorldFIP, les couches physique, liaison de données,application et gestion de réseau.

Figure 15 : le protocole WorldFIP [Azevedo et Cravoisy 1998 ; WorldFIP_URL]



Figure 14 : exemple d’architecture d’un « Neuron chip »

Le document [Azevedo et Cravoisy 1998] définit ces couches comme ci-après.

– La couche physique assure le transfert des bits d’informations d’un équipement auxautres équipements connectés sur le bus, le médium peut être une paire cuivretorsadée blindée ou une paire de fibres optiques (EN50170-3, parties 2 et 3). Elledéfinit le débit, le codage des éléments binaires de la trame et les média detransmission possibles.

– La couche liaison de données fournit deux types de service de transmission, leséchanges de variables identifiées et les transferts de messages. Ces échanges sontréalisés cycliquement, sans requête de l’utilisateur, lorsque le système a étéconfiguré à cette fin ou encore sur demande explicite de l’utilisateur.

– Les services de la couche application sont divisés en trois groupes distincts :ABAS, MPS et subMMS. Le groupe ABAS (bus arbitrator application services)définit les services application de l’arbitre de bus. MPS (manufacturing periodical/aperiodical services) définit les services périodiques et apériodiques pour lesapplications. Le groupe subMMS (subset of messaging services) définit un sous-ensemble de services de messagerie.

– La couche gestion de réseau décrit l’ensemble des services utilisés pour gérer lacommunication et l’ensemble des ressources de communication nécessaires. Lesdeux services de cette couche sont d’une part le service SM_MPS basé sur lesservices périodiques et apériodiques MPS et d’autre part le service SMS basé surles services message MCS-MSG [Azevedo et Cravoisy 1998].

Les différents composants de communication WorldFIP ont pour nom FULLFIP2,FIPIU2, FIPCO1 et MicroFIP [WorldFIP_URL] :

– FULLFIP2 est un co-processeur de communication implantant la plus grande partiedes couches liaison de données et physique des normes EN50170-IEC61158. Ilaccepte les quatre débits standard de transmission : 31,25 kbit/s, 1 Mbit/s,2,5 Mbit/s et, avec un médium fibre-optique, 5 Mbit/s. Il est capable de gérerjusqu’à 4000 identificateurs et 2 Mbits de mémoire externe. La figure 16 montre unexemple d’architecture d’un nœud WorldFIP implantant un circuit FULLFIP2.

– FIPIU2 est un contrôleur de communication opérant aux débits de 31,25 kbit/s,1 Mbit/s et 2,5 Mbit/s. Utilisé avec un micro-processeur, il peut remplir lesfonctions d’abonnés (Subscriber), d’arbitre de bus (Bus Arbiter) (voir leparagraphe 3 du chapitre 4) et d’observateur réseau WorldFIP.

– FIPCO1 et MicroFIP sont des circuits bon marché. FIPCO1 est à utiliser avecun micro-processeur pour la connexion d’équipements simples échangeantuniquement des variables. Il ne permet pas le transfert de messages et ne peutréaliser la fonction d’arbitre de bus (paragraphe 3 du chapitre 4). MicroFIP a étéconçu aussi bien pour l’acquisition directe d’entrées/sorties que celle de donnéestraitées localement. Il opère à 31,25 kbit/s, 1 Mbit/s et 2,5 Mbit/s. Il est capablede gérer des messages de longueur maximum de 128 octets et jusqu’à 8 mémoirestampons distribuées parmi les 120 octets de mémoire interne. La figure 17montre un exemple d’architecture d’un nœud WorldFIP implantant un circuitMicroFIP.



D’autres informations sur les différents produits WorldFIP pourront être trouvées sur[WorldFIP_URL].

Figure 16 : exemple d’architecture d’un nœud WorldFIP avec FULLFIP2 (source : « FIPWARE : ALSTOM technology for WorldFIP »)



Figure 17 : exemple d’architecture d’un nœud WorldFIP avec MICROFIP(source : « FIPWARE : ALSTOM technology for WorldFIP »)

4.6 Réseau TCN

La décomposition en couches des protocoles du réseau TCN (Train CommunicationSystem) est montrée en figure 18 [TCNspecifications 1998]. Cette figure met en évidenceses quatre protocoles MVB, WTB, RTP et NM spécifiquement conçus pourl’interconnexion d’équipements programmables situés à l’intérieur d’un même véhiculeet de différents véhicules :

– Le protocole du « bus véhicule » MVB (Multifunction Vehicle Bus) est défini surles couches 1 et 2. Il permet l’interconnexion des équipements standards situés àbord d’un véhicule.

– Le protocole du « bus train » WTB (Wire Train Bus) est également défini sur lescouches 1 et 2. Il permet l’interconnexion des véhicules d’un train dans le cas detrains « ouverts » tels que les trains internationaux UIC.

– Les protocoles temps réel RTP (Real Time Protocols) sont définis sur les couches 3à 7. Les protocoles et services de RTP offerts à une application d’un véhiculeautorisent la communication avec d’autres applications du même ou d’autresvéhicules au travers du réseau TCN. Les protocoles RTP de TCN sont utilisés pourla communication sur un bus véhicule MVB, le bus train WTB ou tout autre busoffrant les mêmes services de base demandés par RTP. Ces protocoles offrent à lacouche application les services « variables », pour lesquels seule la couche 7 estspécifiée, et les services « messages », pour lesquels les couches 3 à 7 le sont.

– Le gestionnaire de réseau NM (Network Management) spécifie des servicesnécessaires à la mise en service, au test et à la maintenance d’un réseau TCN dontles bus (MVB, WTB ou autres bus non spécifiés par TCN) acceptent les protocolesRTP pour la communication entre applications.

L’ensemble de ces protocoles fait l’objet de la norme européenne IEC 61375-1.

Figure 18 : couches du réseau TCN [TCNspecifications 1998]



Nous n’avons pas trouvé beaucoup d’informations sur les composants MVB ou WTB.[TrainCom_URL] fait état de différents équipements disponibles. Par exemples, des cartesMVB sont conçues par Bombardier, Far Systems et Siemens, des cartes MVB/VME parKontron et Unicontrols, des passerelles TCN par Bombardier, EKE Electronics, FarSystems, des passerelles MVB/CAN par Duagon et Selectron, le logiciel TCN estdisponible chez Bombardier, Far Systems et Siemens, le logiciel WTB chez Unicontrol.

4.7 Réseau PROFIBUS

Un réseau de terrain est amené à évoluer en fonction des besoins de l’industrie et desprogrès techniques. L’évolution de la représentation des couches du réseau PROFIBUSillustre bien ce propos (figures 19 et 20). Un autre exemple explicite aurait pu être leréseau WorldFIP dont la couche application est couramment en cours de développementafin d’accepter de nouvelles familles d’applications [WorldFIP_URL].

Les deux figures montrent un protocole défini sur les couches physiques, liaison de donnéeset application du modèle de référence OSI. Le manuel technique [Profibus 1997] mettait envaleur les différentes parties faisant l’objet de la norme européenne EN 50170, de la normeallemande DIN E 19245 (partie 4) ou encore de directives PROFIBUS. Elle distinguaitégalement trois profils applicatifs : PROFIBUS-FMS, réseau qualifié « d’universel » pour lesapplications « d’usage général », PROFIBUS-DP, réseau « rapide » pour les applications« manufacturières » et PROFIBUS-PA, réseau « orienté métier » pour les applications de type« process » (figure 19). Cette décomposition est reprise dans le livre [Ciame 1999].

Figure 19 : architecture de communication de PROFIBUS d’après [Profibus 1997]



Par contre, la décomposition en couche du réseau PROFIBUS selon la version de1999 du manuel technique [Profibus 1999] met en avant (figure 20) :

– des supports physiques (liaison RS 485 pour les applications de l’industriemanufacturière, la transmission CEI 1158-2 pour le process et la fibre optique pourles environnements perturbés et les longues distances) ;

– deux profils de communication, DP et FMS (Fieldbus Message Specification),

Le profil DP est le plus répandu des profils PROFIBUS. Il est « réservé au dialogueentre automatismes et périphérie décentralisé », en remplacement « des signaux24 V dans le manufacturier et de signaux analogiques sur boucle 4-20 mA dans leprocess » [Profibus 1999].

Le profil FMS est conçu pour la communication entre équipements intelligents.Soumis à la percée du monde TCP/IP au niveau cellule et à l’évolution dePROFIBUS, il devrait jouer, d’après [Profibus 1999], un rôle moins important dansla communication industrielle ;

– des profils applications qui décrivent « l’interaction du protocole utilisé », DP etFMS, « avec la technique de transmission utilisée », c’est-à-dire la transmissionRS 485, CEI 1158-2 ou sur fibre optique.

Figure 20 : architecture de communication de PROFIBUS d’après [Profibus 1999]



Quant au volume 2 de la norme EN 50170, il ne met en valeur que les couchesphysique à application du réseau et les points d’accès de l’unité de gestion de réseau àchacune de ces couches (figure 21).

Nous n’avons pas trouvé d’information sur les composants PROFIBUS. [Profibus2002] fait état de trois types de puces de protocole :

– « des puces simples intégrant toutes les fonctions du protocole, sans contrôleursupplémentaire ;

– des puces de communication mettant en œuvre tout ou partie du protocole,moyennant un contrôleur supplémentaire ;

– des puces de protocole avec microcontrôleur intégré ».

5. ConclusionCe second chapitre a tout d’abord été l’objet d’un rappel du modèle de référence OSI,

spécifié entre 1977 et 1984 dans le souci premier de permettre l’interconnexion de réseauxde communication multi-constructeurs. Le modèle de référence propre aux réseaux decommunication locaux dont les couches 1 et 2 sont généralement très développés et lesdifférents types d’équipements d’interconnexion ont alors été présentés. Après ces troisparties introductives, nous nous sommes alors intéressés à la représentation des réseaux decommunication « ferroviaires » selon le modèle de référence OSI ainsi qu’à l’architecturedes nœuds. Le parcours de ces représentations a été fait à partir des normes, d’articlesscientifiques ou de prospectus. Il nous permet déjà d’introduire l’hétérogénéité des solutionsmises en œuvre et le large éventail des choix technologiques. Il met notamment en valeur ladifficulté d’une approche commune des problèmes de communication inter-système,difficulté à l’origine du modèle de référence OSI et des nombreuses normalisations.

Le paragraphe sur les équipements d’interconnexion et le constat de l’hétérogénéitédes solutions technologiques retenues à ce jour montrent l’importance du développementde passerelles pour permettre l’interconnexion de ces solutions et donc de véhiculesferroviaires de pays d’origines différentes. Un exemple d’interface est celle fournie parSelectron entre le CAN et MVB [Selectron 1999]. Deux autres exemples sont un répéteurMVB et une passerelle MVB/WTB développés par Siemens [TSD_URL]. Enfin,[Sullivan 1998] évoque l’intérêt d’une passerelle entre TCN et LONWORKS.

Dans les deux chapitres suivants, nous allons décrire plus en détail la couche physiqueet les protocoles d’accès au médium de ces réseaux.



Figure 21 : architecture de communication de PROFIBUS d’après [EN_50170_2 1996]

Chapitre 3

Couche physique des réseaux decommunication filaires embarqués

Les deux principales couches des réseaux de communication locaux sontgénéralement les deux couches basses du modèle OSI, la couche physique et la coucheliaison de données (modèle de référence IEEE 802 propre aux réseaux LAN et MAN[IEEE_Std_802 1990]). Ce chapitre présente certaines fonctionnalités de la couchephysique des protocoles de communication embarqués, le chapitre suivant s’intéresseraplus particulièrement aux méthodes d’accès de la couche liaison de données.

La couche physique fournit les moyens de transmettre et de recevoir des élémentsbinaires entre deux entités de la couche physique, c’est-à-dire ceux nécessaires àl’émission et la réception de signaux modulés affectés à différents canaux de fréquencesspécifiques dans le cas d’une transmission large bande (broadband, transmission parmodulation de porteuse) ou encore les signaux affectés à un unique canal dans une bandede fréquences donnée dans le cas d’une transmission en bande de base (baseband,transmission sans modulation de porteuse).

Elle se charge ainsi notamment du codage et décodage des bits et de la générationd’éléments de synchronisation. Elle spécifie également le médium de transmission utiliséet la topologie.

Les paragraphes suivants présentent tout d’abord l’évolution des topologiesembarquées au sein des trains, ensuite les supports de transmission prévus par lesprotocoles de communication qui nous intéressent et enfin les différentes techniques detransmission sur un médium de transmission (filaire ou non) et le codage desinformations.

1. Topologie des réseaux Dans cette première partie, nous rappelons tout d’abord les différentes

caractéristiques des topologies des réseaux de communication locaux, avant de présentercelles choisies dans le cas particulier de réseaux de contrôle-commande embarqués ausein de véhicules ferroviaires.

1.1 Topologie des réseaux de communication locaux

La topologie d’un réseau décrit les relations physiques et logiques à l’intérieur d’un réseau. La topologie physique définit la façon dont les différents nœuds (stations) d’un réseau sont raccordés physiquement entre eux. La topologie logiquedéfinit la façon dont une trame est véhiculée sur le réseau. Elle est réalisée par unprotocole d’accès.


On peut classer les différentes topologies physiques selon deux types (figure 1) :

– les topologies « point à point » ;

– les topologies « multipoints ».

Dans les topologies « point à point », les stations du réseau sont raccordées deux àdeux, chaque segment ne relie alors que deux abonnés. Celles « multipoints » supportentl’interconnexion en parallèle de plusieurs stations à un même support physique. Toutabonné du réseau est donc physiquement en liaison directe avec les autres [Desodt 1997].

Figure 1 : exemple de topologies multipoints et point à point



Les principales topologies rencontrées dans les réseaux de communication embarquéssont le bus (topologie multipoint), l’anneau (topologie point à point) et l’étoile (topologiepoint à point) [Tanenbaum 1997 ; Mackenzie et Bettaz 1988 ; Desgeorge 2000 ; Summers2000]. Les principales caractéristiques de ces topologies sont maintenant présentées.

1.1.1 Le bus

Un câble, souvent une paire torsadée ou un câble coaxial, relie toutes les stations duréseau sur une seule ligne. Tous les abonnés partagent le même médium généralementterminé à chaque extrémité par une terminaison chargée de supprimer tout écho. Letransfert des bits s’y fait en série, la transmission des données sous forme de trame. Dansle cas particulier d’une connexion par coupleur passif, un médium fibre optique permetégalement d’obtenir une topologie bus (voir le paragraphe 2.3 de ce chapitre).

La transmission peut se faire en bande de base ou en large bande. Dans le premier cas,le signal s’atténuant fortement avec l’augmentation de la distance, la longueur maximalechoisie pour le bus est souvent de 1 km. Cette longueur peut être augmentée parl’utilisation de répéteurs qui régénèrent alors le signal dans les deux sens (figure 2). Il està noter qu’afin d’éviter un effet de rebouclage immédiat de la sortie du répéteur sur sonentrée, un retard volontaire est introduit dans la chaîne de traitement du répéteur [Paret1996]. Ce retard de quelques dizaines ou centaines de nanosecondes est à considérer

comme une augmentation apparente de la longueur physique du réseau qui peutnécessiter de réduire le débit (voir le paragraphe 4.2.2.2 de ce chapitre).

Figure 2 : jonction de deux segments de bus par un répéteur

Couche physique des réseaux de communication filaires embarqués


Un signal émis sur un bus se propage le long du médium. Ceci permet de diffuserfacilement des informations d’une station source à l’ensemble des stations connectées.Cependant les données transmises peuvent n’être qu’à destination d’une station ou d’unsous-ensemble de stations. Afin de distinguer ces différents cas de figures, la trame doitcontenir une information qui définit la destination de l’information transmise. Selon lesprotocoles de communication, cette information de destination pourra être une adressephysique ou une adresse logique. Une adresse physique identifie un nœud. Utilisée commeinformation de destination, elle sert à la transmission point à point. Une adresse logiqueest un nom symbolique qui identifie les éléments d’un ensemble sur le réseau. Elle permetla diffusion d’une information. L’ensemble identifié par l’adresse peut être celui desadresses physiques destinatrices. Les destinataires sont alors ce groupe d’adressesphysiques. Il peut également être celui des données transmises dans la trame (on dit quel’adresse logique, souvent appelée ici « identificateur », identifie la nature de l’informationcontenue dans la trame). Dans ce second cas, seuls les nœuds abonnés à cette adresseacceptent en réception l’information transmise. Un nœud a une seule adresse physique,mais peut accepter plusieurs adresses logiques. Enfin, le même médium est aussi bienutilisé pour l’émission que la réception. Afin d’éviter les collisions et la monopolisation dumédium par une station, ce médium nécessite une régulation des accès à sa ressource.

Une topologie dérivée du bus est la topologie « arbre » (tree) que l’on peut rencontrerdans des réseaux où la transmission se fait en large bande : la transmission du signal étantalors unidirectionnelle, le signal se diffuse à partir du point d’émission sur l’ensemble desbranches de l’arbre.

Les avantages de la topologie bus sont le faible coût du câblage et du médium detransmission. D’autre part, la panne d’une station ne perturbe pas l’ensemble du réseauet le réseau est facile à étendre. Ses inconvénients sont un ralentissement possible duréseau lorsque le trafic est important, des difficultés d’isolation des problèmes quipeuvent apparaître sur le réseau et, en cas de coupure du câble, l’affectation d’un grandnombre de stations, voire de l’ensemble du système.

1.1.2 L’anneau

Les stations sont raccordées au médium via un coupleur actif qui répète le signald’une station à une autre. Chaque coupleur est lié via une liaison point à point avec celuide son voisin jusqu’à arriver à la formation d’un anneau. Le câble utilisé peut être unepaire torsadée, des câbles coaxiaux ou des fibres optiques.

Le transfert de bits se fait en série. La transmission de données est unidirectionnelle :le signal arrive par un point du coupleur qui le répète sur le médium via le second point.Les données transmises le sont dans une trame qui circule d’une station à une autrejusqu’à retourner à la station émettrice qui la détruit alors. Une station destinatrice d’unetrame la copie au passage. Pour cela, les coupleurs ont deux modes de fonctionnement :le mode écoute, où chaque bit reçu est copié dans la mémoire tampon du coupleur avantd’être retransmis après un délai d’une durée d’un bit, le mode transmission dans lequelse met le coupleur lorsqu’il a des données à transmettre. Dans ce mode, les informationsd’un nœud sont émises sur la partie aval de l’anneau. En fin de transmission, le coupleurpasse en mode écoute dans lequel il pourra retirer la trame du réseau lorsqu’elle luiparviendra en fin de tour. Un troisième mode de fonctionnement du coupleur, le modedérivation, est utile pour contourner une station rattachée et ainsi l’isoler en cas dedéfaillance (figure 3).

Figure 3 : état possible du coupleur dans une topologie anneau



Cette topologie nécessite l’usage d’une méthode de contrôle d’accès au médium pourdéterminer le moment où une station peut insérer une trame dans la boucle. Elle offre unaccès équitable au réseau à tous les abonnés et permet d’avoir un débit proche de 90 %de la bande passante. Les performances du réseau sont régulières quel que soit le nombrede nœuds. Ses inconvénients sont l’affectation de l’ensemble du réseau lors del’apparition d’une défaillance sur un coupleur ou après rupture du médium et lesdifficultés d’isolation d’un problème sur le réseau. D’autre part, le fonctionnement duréseau est interrompu pour toute reconfiguration. Signalons également quel’interconnexion de deux réseaux en anneau n’est pas facile à mettre en œuvre.

1.1.3 L’étoile

Chaque nœud est directement connecté par des segments de câble à un nœud centralqui sert d’intermédiaire dans toute communication entre les nœuds. Le médium utilisépeut être le cuivre ou la fibre optique.

L’unité centrale transfère l’information d’une station à une autre en fonction del’adresse contenue dans la trame. Elle peut également diffuser l’information reçue àl’ensemble des stations, auquel cas le réseau en étoile se comporte comme un « buslogique ». Une méthode de contrôle d’accès au médium est nécessaire afin qu’un uniquenœud ne soit autorisé à transmettre à un instant donné.

Un réseau en étoile offre des facilités de modification et d’ajout de nouveaux abonnés,une surveillance et une gestion centralisée, une robustesse vis-à-vis de la panne d’unnœud (autre que l’unité centrale) sur l’ensemble du système. Sa faiblesse est son nœudde gestion centralisé. En cas de panne de ce nœud, le réseau ne peut plus fonctionner.

1.2 Évolution des topologies des réseaux embarqués sur desmatériels guidés ferroviaires

Les premières topologies des réseaux de communication embarqués dans lesmatériels roulants ferroviaires ont été l’anneau et le bus. Les réseaux TORNAD etTORNAD*, utilisés dans des trains de voyageurs TGV (TORNAD et TORNAD*) et lemétro de Lyon MAGGALY (TORNAD), sont respectivement des réseaux à passage dejeton sur anneau et sur bus. La notion de jeton fait référence à la méthode d’accès utilisée(voir le chapitre 4). Le passage d’une topologie anneau à bus a été un premier pas versune simplification des procédures de couplage et découplage de deux rames TGV.L’anneau ou le bus parcourent l’ensemble des rames du TGV de part et d’autre du train(figure 4).

Figure 4 : le réseau Tornad d’Alstom [Duquesnoy et Kieken 1986]



Un autre exemple de première liaison bus est la liaison multiplexée MUX G[Boutonnet et Chateaureynaud 1989a ; 1989b] pour les applications de réversibilité et deconduite en unité multiple des trains de fret.

L’évolution suivante a été une décomposition hiérarchique du système réseau decommunication embarqué avec la définition d’un « bus train » (Train Bus) et d’un « busvéhicule » (Vehicule Bus) (figure 5). Le bus train sert alors à l’interconnexion del’ensemble des véhicules du train (rames ou wagons) et supporte notamment les fonctionsde numérotation des véhicules et d’intégrité du train (surveillance du nombre devéhicules en cours d’exploitation du train). Ce bus train est un réseau ouvert : le nombrede nœuds connectés n’est pas figé, le réseau accepte l’ajout ou la suppression de

véhicules en cours de fonctionnement. Le bus véhicule interconnecte les différentséquipements situés à l’intérieur d’un même véhicule ou dans un ensemble indéformablede véhicules (pas de découplage autorisé de ces véhicules en cours d’exploitation). C’estun réseau fermé : le nombre d’équipements connectés est connu et fixé à la conception,de nouveaux abonnés ne sont pas autorisés en cours d’exploitation. L’interconnexion desbus véhicule au bus train se fait par l’intermédiaire des nœuds du bus train qui serventalors de passerelle. Cette architecture permet l’utilisation de technologies différentes pourles bus véhicule et le bus train, pourvu que les passerelles adéquates aient été définies etimplantées au préalable.

Figure 5 : notion de bus train et bus véhicule



Les figures 6, 7 et 8 illustrent différents exemples d’utilisation de bus train etvéhicule. La figure 6 montre celle d’un bus véhicule FIP pour l’interconnexion deséquipements d’une triplette (ensemble indéformable, en cours d’exploitation, de troisvéhicules) et d’un bus train WorldFIP supportant les fonctions de couplage et découplagede triplettes.

Figure 6 : exemple d’utilisation d’un bus train et d’un bus véhicule WorldFIPd’après [WorldFIP_News 1995 ; 1999]

La figure 7 montre l’utilisation du bus véhicule MVB de TCN pour l’interconnexiond’équipements programmables entre eux et celle de ces équipements avec des capteurs etactionneurs à l’intérieur des véhicules. Un bus MVB autorise la connexion au réseau TCN deséquipements ferroviaires standard situés à l’intérieur d’un même véhicule ou dans un ensembleindéformable de véhicules. Le bus train utilisé est le bus WTB de TCN. Il a été conçu pourpermettre l’interconnexion de véhicules qui, en cours d’exploitation quotidienne d’un train,

sont couplés ou découplés. Ce bus remplit les exigences de communication UIC 556 définiespour un train UIC comportant jusqu’à 22 voitures de 26 mètres chacune [ROSIN_URLb].

Figure 7 : configuration du réseau TCN d’après [Corradi et al. 1996 ; ROSIN_URLa]



Un autre exemple est celui donné par le schéma de la figure 8 montrant l’utilisationdu réseau LONWORKS en tant que bus train et bus véhicule d’un train [Chervet 1998].Avec cette même technologie, la SNCF et la DB testent un système de freinageélectronique pour les trains de fret (appelé FEBIS – Freight Electronic Brake andInformation System). Deux approches de connexion des équipements au bus train sontnotamment étudiées : un nœud central à chacun des véhicules implante toutes lesfonctionnalités du système et est directement connecté au bus train ; dans chaquevéhicule, les équipements électroniques exécutant les fonctions sont connectés à un busvéhicule, lui-même rattaché au nœud du bus train [Witte et al. 2001].

Figure 8 : exemple de configuration du réseau LONWORKS

d’après [Chervet 1998]

Signalons encore un essai précédent, en Allemagne, d’un système de freinageélectronique utilisant la technologie CAN pour les bus train et véhicule de ce systèmeexpérimental [Witte 1998].

Enfin, il convient de rappeler que le standard « IEEE P1473, CommunicationsProtocol Aboard Trains » adopté en 1999 repose sur la possibilité d’intercommunicationtransparente des deux protocoles TCN et LONWORKS l’un avec l’autre, c’est-à-dire del’existence d’une passerelle entre ces deux protocoles [McGean 1999]. Ce standarddéfinit les configurations permises pour l’utilisation de ces réseaux TCN (tableau 1).

Cette norme, qui comme toutes normes peut évoluer en fonction de l’expérience,montre aujourd’hui une grande prudence vis-à-vis d’une solution non dédiée(LONWORKS) par rapport à une solution dédiée (TCN).

2. Supports de transmission filairesAprès la présentation des topologies, nous poursuivons ci-après par celle des média

de communication filaires.

2.1 Introduction

La couche physique transmet tout élément binaire en provenance de la couche liaisonsur un support physique, le médium de communication. La nature du médium peut être[Lagrange et Seret 1998] :

– le cuivre (paire torsadée blindée ou non, câble coaxial, câble d’alimentation),

– la fibre optique,

– l’éther (faisceaux hertziens, rayons infrarouges, rayons laser...).

La figure 9 donne pour information la gamme de fonctionnement de ces média dansle spectre électromagnétique. La connaissance de ce spectre est utile dans le cas d’unetransmission large bande (par modulation de fréquence). Dans le cas des réseaux decommunication locaux filaires, les média rencontrés sont avant tout le cuivre (pairetorsadée et câble coaxial), parfois le « courant porteur » (surtout dans la domotique) etplus récemment la fibre optique. Les paragraphes suivants donnent quelques élémentscomplémentaires sur ces média filaires.

2.2 Le cuivre

2.2.1 La paire torsadée

Une paire torsadée est composée de deux fils de cuivre mutuellement isolés etenroulés l’un autour de l’autre afin de limiter les interférences extérieures, en particulier



Tableau 1 : recommandation pour l’utilisation conjointe des réseaux de types Tet L d’après [IEEE_1473 1999]

Bus VÉHICULE Bus TRAIN Couplage et découplage Exigences deCas Non Temps d’unités opérationnelles de performances et

Temps Critique base à l’intérieur d’un train d’interopérabilitéCritique avec celles provenant

d’autres autorités ayantjuridiction

I Type T Type T Type T Oui Spécifiées dans Sdt. II Type L Type T Type T Oui IEEE 1473-1999III Type L Type L Type T Oui Non spécifiées dans Sdt.IV Type L Type L Type L Non IEEE 1473-1999Où Type T désigne le réseau TCN et Type L le réseau LONWORKS.

en provenance d’autres câbles [Linux_URL]. Plusieurs paires sont groupées dans unemême gaine pour former des câbles de 2, 4 ou 8 paires.

Il existe plusieurs types de paires torsadées, les paires torsadées non blindées,blindées, écrantées ou encore blindées et écrantées. Les paires torsadées se différencientégalement par leurs impédances caractéristiques (100, 120 ou 150 Ohms). Elles sontutilisées pour la transmission en bande de base et en large bande (voir le paragraphe 3.3de ce chapitre).

Les avantages de la paire torsadée sont sa facilité d’utilisation, son faible coût, saprésence dans de nombreux lieux (câblage téléphonique). Par contre, elle est sensible auxperturbations en provenance de l’environnement. Elle présente une forte atténuation dusignal en fonction de la distance et peut nécessiter l’utilisation de répéteurs. Enfin, elleoffre une faible sécurité (confidentialité), l’écoute des signaux y est relativement aisée.

2.2.2 Le câble coaxial

Un câble coaxial est constitué d’un premier conducteur qui conduit le signalélectrique. Ce premier conducteur est entouré d’un diélectrique (ou isolant), lui-mêmerecouvert d’un deuxième conducteur assurant le blindage. Ce deuxième conducteur estconstitué de métal tressé. L’ensemble est enfin mécaniquement protégé par une gaine deplastique.

Il existe plusieurs types de câbles coaxiaux. Les plus courants sont classés par leurimpédance caractéristique, mais ils sont principalement caractérisés par leur impédance



Figure 9 : gamme de fonctionnement des média dans le spectre électromagnétiqued’après [Summers 2000]

et leur affaiblissement linéique qui varient en fonction de la fréquence de travail et de leursection. Un câble coaxial permet la transmission en bande de base et large bande.

Ses avantages par rapport à une paire torsadée sont une faible atténuation du signal etune meilleure protection contre les perturbations de l’environnement. Il permet detransmettre la voix, des données et des images et présente une meilleure sécurité.

Par contre, son coût est plus élevé que celui de la paire torsadée. D’autre part, salourdeur et sa rigidité le rendent difficile à manipuler.

2.2.3 Les « courants porteurs »

Le médium « courant porteur » utilise les câbles du réseau électrique. Lesinformations y sont transmises sous la forme d’un signal à hautes fréquences superposéà l’onde porteuse du courant alternatif basse fréquence (230V-50 Hz pour les applicationsde la domotique). La modulation du signal haute fréquence permet d’éviter lesinterférences. Mais l’atténuation du signal en fonction de la distance est importante. Lesdébits maximaux de ce médium sont actuellement de l’ordre de 1 Mbit/s.

2.3 La fibre optique

La fibre optique est composée d’un conducteur très fin en silice ou en plastiqueentouré par une gaine protectrice. Elle supporte la transmission unidirectionnelle designaux lumineux. Par conséquent, une configuration en boucle ou l’utilisation de deuxfibres optiques sont nécessaires à une transmission bidirectionnelle des données. Dans cedernier cas, l’une est utilisée pour la transmission, l’autre pour la réception.

La transmission de données s’effectue par modulation numérique de la puissanceoptique d’une onde émise à une longueur d’ondes donnée.

Les deux familles de fibres optiques sont les fibres monomodes et les fibresmultimodes qui se différencient par leur composition et le mode de propagation desrayons lumineux. Le cœur d’une fibre monomode extrêmement fin (10 mm) permet unepropagation quasiment directe. La dispersion modale est alors proche de zéro. La bandepassante transmise est presque infinie (> 10 GHz/km). Cette fibre est utiliséeessentiellement pour l’interconnexion de sites distants. Deux types de fibres multimodesse distinguent : la fibre à saut d’indice et la fibre à gradient d’indice. La fibre à sautd’indice est constituée d’un cœur et d’une gaine optique en verre de différents indices deréfraction. Cette fibre provoque, en raison de l’importante section du cœur, une grandedispersion des signaux la traversant, ce qui génère une déformation du signal reçu. Lecœur de la fibre à gradient d’indice est constitué de couches successives de verre dont lesindices de réfraction sont proches et par conséquent les temps de propagation. Ladispersion modale est donc réduite.

La connexion sur un médium fibre optique peut se faire par l’intermédiaire d’uncoupleur actif ou passif (figure 10). Un coupleur actif agit comme un répéteur, laconnexion des coupleurs est alors point à point. Un coupleur passif extrait une portion del’énergie optique du bus en réception et en injecte directement sur le médium entransmission. Cette connexion multipoint limite, par rapport à la première solution, lenombre de stations sur le bus et également la longueur du médium.



Les avantages de la fibre optique sont une très bonne immunité aux bruits, une faibleatténuation du signal permettant une propagation des signaux sur de longues distances,une vitesse de transmission plus élevée (débit de plusieurs Gbit/s ; débits de l’ordre de600 Mbit/s sur des distances de l’ordre du km contre quelques kbit/s à quelques centainesde Mbit/s pour un médium métallique), une très large bande passante (de l’ordre duGHz), une insensibilité aux perturbations électromagnétiques, un haut niveau de sécurité(confidentialité) et une bonne intégrité des données.

Ses inconvénients sont son caractère unidirectionnel qui impose en générall’utilisation de paires de fibres, le coût des connexions et sa fragilité mécanique.

On trouve aujourd’hui, dans la littérature, une augmentation des recherches sur lafibre optique dans le secteur de l’embarqué, notamment dans celui de l’automobile.

2.4 Autres média

Les réseaux sans-fil se développent très rapidement et trouvent de nombreusesapplications dans les entreprises et les institutions. La voie hertzienne est utilisée pour lesconstituer.

On distingue deux types de réseaux sans-fil : les réseaux locaux sans-fil de typeboucle locale radio (WLAN, Wireless LAN, BRAN, Broadband Radio Network...) et lesréseaux mobiles. Plus d’informations sur l’utilisation de ces réseaux dans les transportsferroviaires pourront être trouvées dans [Berbineau 2001a ; 2001b].

3. Techniques de transmission et de codage desinformations

Les différentes topologies et média de transmission ayant été introduits, nousprésentons maintenant les techniques de transmission et de codage des informations surun médium de transmission.

3.1 Introduction

Un système de transmission de données est souvent représenté selon le schéma de lafigure 11 [Lagrange et Seret 1998 ; Mackenzie et Bettaz 1988]. Ce schéma montre les



Figure 10 : techniques de connexion d’un nœud à une fibre optique

entités mises en jeu pour la transmission d’informations entre deux équipements terminaux.La transmission se fait via un support de transmission. Chaque équipement terminalcomporte deux entités, l’« Équipement Terminal de Traitement de Données » (ETTD ouDTE en anglais pour Data Terminal Equipment) et l’ « Équipement Terminal de Circuit deDonnées » (ETCD ou DCE en anglais pour Data Circuit terminating Equipment).

L’ETTD est un équipement informatique impliqué dans un échange de données àdistance [Mackenzie et Bettaz 1988]. Il génère les données à transmettre et traite les donnéesreçues, les données transmises et reçues étant composées de l’information utilisateur et dedonnées de contrôle utiles à l’échange. L’ETTD permet de transmettre des données (entitéSD de la figure 11) ou de collecter les données (entité CD) en provenance du médium decommunication par le biais d’un contrôleur de communication connecté à l’ETCD.

L’ETCD est un équipement chargé d’adapter les données en sortie de l’ETTD ensignaux conformes aux caractéristiques du médium de transmission, et inversement, ilconvertit les signaux en provenance du médium en données compréhensibles par l’ETTD.

Figure 11 : représentation d’un système de transmission de données [Lagrange et Seret 1998 ; Mackenzie et Bettaz 1988]



Nous rappelons tout d’abord ci-après les différentes méthodes de synchronisation etde transmission entre deux équipements distants, dans le cas d’une transmission sériellede données. Ensuite, les techniques de transmission analogique et digitale et le codagedes données en fonction de ces transmissions seront considérés au paragraphe 3.3.

3.2 Méthodes de synchronisation entre deux équipements terminaux

3.2.1 Introduction

Les informations transmises sur un médium de communication série par unéquipement doivent pouvoir être lues et comprises par un équipement destinataire. A cettefin, deux techniques, les techniques asynchrones et synchrones, permettent lasynchronisation de l’émetteur et d’un récepteur.

La technique synchrone nécessite la mise en œuvre d’un référentiel temporel communentre l’émetteur et le récepteur qui leur permet de connaître les instants de dépôt et deprélèvement des informations sur le médium. Ce référentiel commun n’existe pas dans latechnique asynchrone [Mackenzie et Bettaz 1988] comme nous allons le voir.

3.2.2 Technique asynchrone de synchronisation

Cette technique est utilisée dans le cas d’un transfert irrégulier ou à débit faibled’informations de petites tailles (blocs de trois à huit bits), typiquement lors du transfertde caractères d’un clavier à un terminal. Elle consiste en l’ajout d’un ou plusieurs bits dedébut d’information (« bit start ») et d’un ou plusieurs bits de fin d’information (« bitstop ») (figure 12).

Figure 12 : technique de transmission asynchrone



A partir du « bit start », le récepteur, dont l’horloge est n fois plus rapide que larapidité de modulation du signal représentant l’information transmise, va échantillonnerle signal reçu au milieu de chaque impulsion [Mackenzie et Bettaz 1988].

3.2.3 Technique synchrone de synchronisation

Cette technique est utilisée dans le cas d’un transfert régulier d’informations dont lataille peut être importante. Chaque bloc de données élémentaire constituant l’informationtransmise est transmis sans bits « start » et « stop ». Cependant, les horloges locales del’émetteur et du récepteur doivent être maintenues synchrones. Pour cela, un référentieltemporel commun est établi entre l’émetteur et le récepteur par la transmission, entre lesdeux entités, d’un signal d’horloge déterminant les instants de dépôt et de prélèvementdes informations élémentaires [Mackenzie et Bettaz 1988]. Sur de courte distance, cettehorloge peut être transmise par l’émetteur sur une ligne de transmission dédiée (cas dubus I2C [I2c_URL]). Sur de longues distances, la synchronisation entre l’émetteur et lerécepteur se fait via le codage de l’information élémentaire. Ce codage permet aurécepteur de maintenir synchronisée son horloge locale avec celle de l’émetteur tout aulong de la transmission lorsqu’il insère l’horloge de l’émetteur dans les donnéestransmises (utilisation d’un codage biphase par exemple) ou qu’il présente assez detransitions [Mackenzie et Bettaz 1988].

Afin de délimiter les blocs d’informations, cette technique utilise un préambule et un« postambule » (figure 13). Ces préambules et « postambules » sont une série de bits desynchronisation mis en début et fin de trame. Le codage de ces éléments binaires peutdifférer de ceux du champ de données.

C’est cette dernière technique de synchronisation synchrone qui est utilisée parl’ensemble des protocoles ferroviaires considérés (voir le paragraphe 4.2 de ce chapitre).Toutefois, le protocole PROFIBUS code aussi chaque bloc élémentaire d’information(caractère) composant sa trame d’information selon la technique de transmissionasynchrone.

3.3 Transmission de signaux analogiques et digitaux et codage des données

Les données transmises par l’ETTD à l’ETCD peuvent être analogiques ou digitales,de même que les signaux transmis par l’ETCD sur le médium (tableau 2). Latransmission analogique a été le premier mode de transmission de données [Mackenzieet Bettaz 1988]. Aujourd’hui, les données analogiques et numériques sont aussitransmises numériquement.

Tableau 2 : transmission analogique/numérique et nature de l’ETCD d’après [Summers 2000]



Figure 13 : technique de transmission synchrone

Type de données(interface ETTD-

ETCD)Nom de l’ETCD

Nature des signaux sur le médiumde transmission

(interface ETCD-médium)

Analogiques(onde sonore, voix)

Téléphone analogique

Analogiques :

Analogiques(son,...)

Codec(Codeur/Décodeur)

représentation desdonnées par unsignal variant defaçon continue

Digitaux :

représentation desdonnées par unsignal variant defaçon discrète

Digitales(texte)

Modem(Modulateur/Démodulateur)

Digitales Emetteur et récepteur digitaux

En nous limitant au cas particulier des transmissions non hertziennes dans les réseauxembarqués, nous présentons ci-après les différentes méthodes de transmissionsanalogiques et numériques de données et les techniques associées de codage del’information transmise. Il convient de remarquer que la transmission des données dansles réseaux locaux embarqués de contrôle-commande dont le médium de communicationest une paire cuivre est essentiellement numérique.

3.3.1 Transmission de signaux analogiques ou transmission suronde porteuse

La transmission analogique (transmission large bande) est également appeléetransmission sur onde porteuse (la bande de fréquence allouée à la transmission est

centrée autour d’une fréquence F0, où F0 est non nulle). Elle se fait par modulation desdonnées à transférer (numériques ou analogiques) par une onde porteuse sinusoïdale dontune des caractéristiques (fréquence, amplitude ou phase) varie. On parle alors demodulation d’amplitude, de fréquence et de phase. Les données sont représentées par desvaleurs variant continuellement dans un intervalle de temps donné. Ce type detransmission permet le multiplexage fréquentiel (FDM –Frequency DivisionMultiplexing) sur le médium de communication, c’est-à-dire la division de la bandepassante de ce médium en plusieurs canaux de transmission ayant chacun une bande defréquences allouée différente.

La transmission analogique de données digitales utilise un « modem » pour modulerles informations à émettre et les démoduler à la réception (tableau 2). L’utilisation d’untéléphone analogique permet la transmission analogique de données analogiques(transmission de la voix).

Cette technique de transmission est possible sur un médium cuivre. Elle est la seulepour un médium fibre optique, courant porteur ou éther. Le signal transmis subit uneatténuation qui est fonction de la distance. L’utilisation d’amplificateurs sur la ligne detransmission pallie cet inconvénient, cependant ils amplifient également le bruit.

3.3.1.1 Codage des données digitales

Trois types de modulation existent pour le codage de données digitales sous la formed’un signal analogique :

– la modulation d’amplitude ASK (Amplitude Shift Keying) qui représente les valeurspar des amplitudes différentes de l’onde porteuse. L’amplitude zéro est souventchoisie et la détection de la présence ou de l’absence de porteuse sert alors pourdifférencier les valeurs binaires. Cette modulation est utilisée pour la fibre optique.

– la modulation de fréquence FSK (Frequency Shift Keying) qui représente lesvaleurs par des fréquences différentes. Cette technique est moins susceptible auxerreurs que la précédente. Elle est utilisée aux hautes fréquences radio (médiuméther) et à des fréquences encore plus élevées sur le câble coaxial (médium cuivre)de réseaux LAN.

– la modulation PSK (Phase Shift Keying) qui représente les valeurs binaires desdonnées en décalant la phase du signal de la porteuse.

La figure 14, empruntée à [Summers 2000], montre les signaux transmis sur unmédium pour la séquence binaire « 00110100010 ». Les données binaires à transmettrepeuvent avoir été codées selon un codage en bande de base (voir le paragraphe 3.3.2suivant) avant modulation puis transmission sur onde porteuse.

3.3.1.2 Codage des données analogiques

Les données analogiques à transférer peuvent également être modulées par une ondeporteuse sinusoïdale.

La modulation de données analogiques permet de rendre plus efficace la transmissionen augmentant la fréquence et autorise aussi le multiplexage par division de fréquence(multiplexage FDM).



Les trois techniques possibles de modulation de données analogiques (modulationd’amplitude, de fréquence et de phase) sont représentées en figure 15.

Figure 15 : codage de données analogiques dans le cas d’une transmission analogique [Summers 2000]



Figure 14 : codage de données digitales dans le cas d’une transmission analogique [Summers 2000]

3.3.2 Transmission de signaux digitaux ou transmission digitale (en bande de base)

La transmission d’un signal digital sur un médium de communication est égalementappelée transmission en bande de base (la bande de fréquence allouée à la transmissionest comprise entre zéro, ou une fréquence proche de zéro, et une fréquence Fmax). Latransmission en bande de base ne nécessite pas de moduler le signal après codage del’information. Les suites de bits sont directement émises sur le médium decommunication sous la forme de valeurs discrètes. Cette transmission utilise au moinsdeux composantes continues.

Le signal n’étant pas modulé, ce type de transmission n’est possible que sur unmédium de transmission cuivre, par exemple une paire torsadée ou un câble coaxial.L’atténuation du signal en fonction de la longueur de ces supports est importante. Parconséquent, à partir d’une certaine longueur de médium (spécifique au réseau choisi), unetransmission de données en bande de base nécessite l’utilisation de répéteurs quirégénèrent les niveaux de tension des signaux binaires.

Cette technique de transmission est la plus utilisée pour les réseaux LAN de contrôle-commande embarqués dont le médium de communication est la paire torsadée cuivre.Cette méthode utilise toute la largeur de la bande passante du médium et ne permet doncpas le multiplexage fréquentiel.

Nous présentons maintenant le codage de données digitales et analogiques dans le casd’une transmission digitale.

3.3.2.1 Codage des données digitales

Une donnée digitale est une série d’éléments binaires ‘1’ et ‘0’. Ces éléments binairessont représentés par des éléments de signal transmis sous la forme d’impulsions detension.

Le codage des éléments binaires transmis sur le médium s’appelle codage en bandede base. Différents schémas de codage en bande de base existent. Ils se différencient par[Summers 2000] :

– le spectre du signal transmis : l’absence de fréquences hautes dans le signaltransmis réduit la bande passante nécessaire. L’absence de composante continue(fréquence zéro) permet un couplage par transformateur et ainsi une isolation galvanique du système. La puissance est concentrée au milieu de la bande passante.

– leur capacité ou non à permettre le maintien d’une synchronisation entre les entitéscommunicantes : le codage du signal binaire rend ou non possible lasynchronisation d’un émetteur et d’un récepteur, parce qu’il transporte l’horloge de l’émetteur ou qu’il offre suffisamment de transitions pour permettre au récepteurde recaler son horloge locale sur le signal transmis.

– leur capacité ou non à détecter une erreur,

– certains codes offrent une meilleure immunité aux bruits et aux interférences dusignal que d’autres,



– le coût et la complexité : une fréquence du signal de transmission supérieure (etdonc un débit des données supérieur) conduit à un coût plus élevé ; certains codesnécessitent une fréquence du signal supérieure au débit des données [Summers2000].

Nous présentons ci-dessous différents types de codage selon qu’ils codent ou nonl’horloge de l’émetteur.

a. Codage ne codant pas l’horloge de l’émetteur :

Les codages NRZ et NRZI sont codés par deux niveaux de tension différents(figure 16). Chaque niveau de tension est maintenu constant pendant la durée de l’élémentbinaire. Ces codages n’offrent pas de capacité de re-synchronisation.

– Le codage NRZ apporte une solution à la difficulté d’obtenir un courant nul. Ilpossède souvent une tension positive et l’autre négative, l’un des niveaux de tensioncodant l’élément binaire ‘1’, l’autre l’élément binaire ‘0’. Ce codage n’offrant pasde capacité de re-synchronisation, il ne permet pas au récepteur de recaler sonhorloge par l’intermédiaire du signal reçu en cas de réception d’une longue séried’un même élément binaire. Enfin, ce codage présente une composante continue.

– Le codage NRZI est un codage différentiel. L’absence ou la présence de transitiondu signal en début de transmission d’un élément binaire code cet élément : un ‘1’ estcodé par une transition positive (passage d’un niveau de tension bas à haut) ounégative (passage d’un niveau de tension haut à bas), un ‘0’ est codé par une absencede transition. Ce codage est donc basé sur une détection des transitions, détectionplus fiable que celle des niveaux (codage NRZ) [Summers 2000]. Contrairement aucodage NRZ, il permet au récepteur de recaler son horloge en cas de transmissiond’une longue série de ‘1’, par contre la transmission de celle de l’élément binaire ‘0’reste un problème.

Figure 16 : codage NRZ et NRZI



D’autres codages utilisent plus de deux niveaux de tension pour représenter unélément binaire. On peut citer le codage HDB3 (Haute Densité Bipolaire 3 Zéros) ou lecodage bipolaire AMI (Alternate Mark Inversion) dont il est dérivé (figure 17).

– Le code AMI est un code à trois niveaux qui représente alternativement un ‘1’binaire comme une impulsion rectangulaire d’amplitude « + a » et « – a » et un ‘0’binaire par une absence d’impulsion [Madec E7430]. Contrairement au codageNRZ et à l’image du NRZI, il permet au récepteur de recaler son horloge en cas detransmission d’une longue série de ‘1’, par contre la transmission de celle del’élément binaire ‘0’ reste un problème.

– Le codage HDB3 remédie à la perte de la synchronisation en cas d’une longue série de zéro en remplaçant une série de quatre zéros par la série « B00V » ou« 000V » (figure 17), où B et V sont des éléments non nuls, B respectant la règle de polarité et V, de signe inverse au V précédent, la violant [Madec E7430 ;Duhot 1989].

b. Codages embarquant l’horloge de l’émetteur :

Les codages biphases (ou Manchester) représentent chaque élément binaire par deuxniveaux en transmettant deux polarités opposées pendant l’intervalle de temps del’élément binaire [Lagrange et Seret 1998] (figure 18). Ces codages transportentl’horloge de l’émetteur.

– Pour le codage Manchester utilisé par la norme IEEE 802.3, la transitionsignificative est trouvée au milieu de chaque élément binaire : une transition de basà haut représente un ‘1’ et une transition de haut à bas un ‘0’ (figure 18). Dansd’autres protocoles, tels que le protocole WorldFIP, une transition de bas à hautreprésentera un ‘0’ et une transition de haut à bas un ‘1’.

– Pour le codage Manchester différentiel utilisé par la norme IEEE 802.5, unetransition en début de la transmission de l’élément binaire représente un ‘0’,l’absence de transition un ‘1’. La transition en milieu de l’élément binaire, quicodait la donnée et l’horloge dans le codage Manchester, ne code plus quel’horloge.



Figure 17 : codage HDB3 [Madec E7430 ; Duhot 1989]

Les codages Manchester nécessitent une bande passante supérieure à celle du codageNRZ ; sa vitesse de modulation maximale est deux fois celle du codage NRZ. L’avantagede ce codage est de permettre une synchronisation du récepteur sur l’horloge del’émetteur à l’aide de la transition en milieu de l’élément binaire. D’autre part, ce codagene présente pas de composante continue contrairement au codage NRZ. Enfin, une erreursur un élément binaire est détectable par l’absence de transition.

Le codage en bande de base est courant dans les réseaux locaux. Son coût est peuélevé. L’atténuation des signaux émis dépend du support de transmission utilisé et ladégradation du signal augmente avec la distance à parcourir. L’utilisation régulière derépéteurs pour régénérer le signal peut alors devenir nécessaire et en augmenter le coût.Ce codage est principalement utilisé pour les réseaux locaux pour des distancesinférieures à 5 km d’après [Nicolas 2000].

3.3.2.2 Codage des données analogiques

Les données analogiques doivent être converties en données digitales via un« codec » avant transmission sous forme binaire (tableau 2). Les mêmes techniquesprécédentes de codage sont alors utilisées.

Signalons qu’il existe deux types de modulation pour la conversion des donnéesanalogiques en données numériques, la modulation PCM (Pulse Code Modulation)et la modulation Delta. La première échantillonne les données analogiques à des intervalles réguliers à un débit deux fois supérieur à la fréquence la plus élevée dusignal. Par exemple, une donnée vocale limitée à 4 000 Hz nécessite 8 000 échantillonspar secondes, chaque échantillon est alors assigné à une valeur numérique représentantun niveau de signal. La représentation d’un échantillon sur plusieurs bits permet alors de représenter plusieurs niveaux du signal. La seconde modulation, modulation Delta, approche la donnée analogique par une fonction en escalier. Achaque intervalle d’échantillonnage, le niveau est décrémenté ou incrémenté d’une valeur constante. La série d’éléments binaires résultante représentant le signal correspond alors à l’information d’incrémentation ou de décrémentation du niveau du signal.



Figure 18 : codage Manchester et Manchester différentiel

3.3.3 Conclusion

Des données analogiques ou numériques peuvent être transmises au moyen d’unsignal numérique (transmission en bande de base) ou d’un signal analogique parmodulation de porteuse (transmission large bande). Certains supports, tels que la pairetorsadée et le câble coaxiale, autorisent aussi bien une transmission analogique quenumérique. Les média « courants porteurs », fibre optique et éther n’acceptent qu’unetransmission analogique.

La transmission large bande permet le multiplexage fréquentiel, c’est-à-dire ladivision de la bande passante du médium de communication en plusieurs canaux detransmission utilisables pour les données, la vidéo et l’audio. Le spectre en fréquence dusignal transmis en bande de base occupe presque toute la bande passante.

Dans le cas d’une topologie bus, la transmission d’information sur le médium de communication est bidirectionnelle en bande de base (figure 19). Par contre, elle est unidirectionnelle en large bande ce qui impose alors l’utilisation de deux fréquences, l’une pour l’émission et l’autre pour la réception, ou bien une doubleconnexion au médium de communication de part et d’autre de la boucle formée par le bus(figure 20).

Figure 19 : transmission bidirectionnelle en bande de base sur un médium cuivre en topologie bus [Yoon 1998]



Figure 20 : transmission unidirectionnelle en large bande sur un médium cuivre en topologie bus [Yoon 1998]

La longueur d’un médium pour une transmission en bande de base est classiquementde quelques kilomètres, elle est de quelques dizaines de kilomètres en large bande [Yoon1998]. Dans le cas des réseaux de communication embarqués dans des trains, la longueurmaximale du médium de transmission étant aujourd’hui proche du kilomètre, unetransmission en bande de base, qui permet facilement une détection en ligne d’une erreurbinaire, est possible.

4. Supports de transmission et codage de l’information dans les « réseaux ferroviaires »

Les paragraphes 2 et 3 de ce chapitre ont été l’occasion d’effectuer des rappels sur lesdifférents supports de transmission filaires et les techniques de transmission adaptées àces supports. Un premier paragraphe présente maintenant les supports de transmissiondisponibles sur les matériels roulants ferroviaires guidés pour les bus trains. Un secondparagraphe reprend chacun des bus cités en introduction et répertorie pour chacun d’euxles média les plus courants. Les points notamment abordés dans ce second paragraphesont pour chacun des réseaux de communication :

– point « 1 », le type du médium de transmission ;

– point « 2 », la topologie du réseau ;

– point « 3 », le nombre maximal de stations par segment, avec et sans répéteurs ;

– point « 4 », le nombre maximal de répéteurs ;

– point « 5 », la longueur du médium ;

– point « 6 », le débit du réseau en bit par seconde et leur codage.

Ces six points seront repris dans des tableaux récapitulant les caractéristiques desréseaux.

4.1 Supports de transmission disponibles pour le bus train sur les matériels roulants guidés

Cette partie reprend les informations contenues dans [Poitevin 2000] relatives auchoix d’un médium de transmission pour le bus train, soit le bus supportant le couplageet le découplage des véhicules d’un train.

Le bus train doit pouvoir utiliser les câbles déjà embarqués dans les véhiculesroulants, notamment le câble UIC568 défini par l’Union Internationale des Chemins deFer (UIC) pour permettre l’interopérabilité des voitures du train (référence [UIC5681996] citée dans [Poitevin 2000]). Ce câble prend en charge des fonctions telles que lacommande de l’éclairage, le contrôle de la fermeture des portes ou l’interphonie. Il estcomposé de 12 conducteurs, arrangés en 3 quartes, et est destiné à des applications partensions continues ou basses fréquences. L’utilisation de la paire interphonie de ce câblepour la transmission d’informations (bus de train) est admise par la fiche UIC 556[UIC556].



La SNCF a essayé d’utiliser cette paire pour la télécommande de locomotives par latechnique du multiplexage [Boutonnet et Chateaureynaud 1989a]. Ces essais ont mis enévidence un débit maximal d’utilisation de l’ordre de 5 kbit/s. Ce résultat a été confirmépar le groupe de travail du projet ROSIN qui a montré qu’elle n’est utilisable à 500 kbit/sque pour un nombre limité de voitures et à la condition d’accepter un taux d’erreursimportant [ROSIN_URLc].

L’UIC a alors défini le câble UIC 558 (figure 21) comportant 4 quartes et 1 pairetorsadée blindée unitairement pour les applications nécessitant une bande passanteimportante (référence [UIC558 1996] citée dans [Poitevin 2000]). C’est cette pairetorsadée blindée que le réseau TCN utilise pour le bus WTB. Ces câbles UIC (UIC 568ou UIC 558) sont installés de chaque côté des véhicules. Par conséquent le médium detransmission pour le réseau train peut être naturellement redondé.

Figure 21 : câble UIC 568 et câble UIC 558 utilisé pour le bus train de TCN [IEC_TCN_URL]



Les média de communication déjà embarqués dans les trains et disponibles pour lebus train sont donc la paire interphonie du câble UIC 568 ou la paire torsadée blindée ducâble UIC 558. D’autres média peuvent être envisagés pour les bus train et véhicule telsqu’une paire d’alimentation en continue (médium courant porteur) [Chervet 1998] ou unmédia installé spécifiquement [Poitevin 2000]. Par exemple, les essais effectués avec latechnologie LONWORKS pour le frein électronique utilise un médium courant porteur[Grasso et al. 2001]. La redondance du médium du bus train est obligatoire, celle dumédium du bus véhicule est optionnelle d’après [ROSIN_URLb ; TCNSpecifications1998].

4.2 Supports de transmission et codage de l’information prévus par les réseaux

Les réseaux de communication ont été regroupés selon deux paragraphes en fonctionde leur caractère dédié ou non au domaine ferroviaire. Ainsi, seront tout d’abordconsidérés les réseaux MUX G, TORNAD et TCN, puis les réseaux BITBUS, WorldFIPet PROFIBUS d’une part et CAN et LONWORKS d’autre part.

4.2.1 Les réseaux de communication spécifiques au ferroviaire

4.2.1.1 MUX G

La liaison MUX G a été conçue pour permettre la réversibilité de la cabine de pilotageet le fonctionnement en unité multiple. Le pupitre de la cabine de la locomotive menéeest alors commandé à distance par la cabine de réversibilité ou par la locomotive quimène le train (figure 22). Le système de multiplexage est redondé et utilise deux fois unepaire de ligne du câble de sonorisation UIC. La longueur du câble est de l’ordre de 700 m.A l’époque, cette nouvelle liaison MUX G qui multiplexe temporellement les signauxélectriques à transmettre remplaçait, par rapport à une liaison classique où les lignesélectriques étaient prolongées, quatre coupleurs de dix-neuf conducteurs, soit soixante-seize lignes électriques [Boutonnet et Chateaureynaud 1989a].

Figure 22 : principe de la télécommande par multiplexage (emprunté à [Boutonnet et Chateaureynaud 1989a])



Les informations transmises sont « les ordres que le conducteur envoie à la machinedepuis la cabine de réversibilité » et « les signalisations issues de la machine que leconducteur reçoit sur le pupitre » [Boutonnet et Chateaureynaud 1989a]. Elles sontfournies par des contacts électriques qui transmettent au système de multiplexage destensions si l’ordre est présent. Un télégramme les transporte alors sous forme digitale àun débit de 5 kbit/s selon un codage qui pourrait être un codage NRZ d’après la figure 23.Cette figure montre également que le protocole d’accès de la liaison MUX G utilise unpréambule pour la synchronisation de l’horloge du récepteur avec celle de l’émetteur.

4.2.1.2 TORNAD et TORNAD*

Les média prévus pour le réseau TORNAD sont la paire torsadée blindée et la fibreoptique. Dans [Duhot 1989], Alsthom utilise la paire torsadée blindée dont le coût estmoindre. Sa longueur est de 900 m pour le TGV A. La topologie du réseau TORNAD estl’anneau, celle du réseau TORNAD* le bus.

Différentes protections sont assurées par les coupleurs TORNAD. A titre d’exemple,nous rappelons les suivantes [Duhot 1989] :



Figure 23 : codage des données de la liaison MUX G [Boutonnet et Chateaureynaud 1989a].

Le tableau 3 résume les caractéristiques de la liaison MUX G d’après les informationscontenues dans [Boutonnet et Chateaureynaud 1989a].

Tableau 3 : caractéristique de la liaison MUX G d’après [Boutonnet etChateaureynaud 1989a]

1 Type du médium de transmission Câble UIC (1 paire de conducteurs de la ligne de sonorisation UICredondé, isolation galvanique du système de multiplexage

également redondé)

2 Topologie du réseau BUS

3 Nombre maximal de ?stations par segment

4 Nombre maximal de répéteurs ?

5 Longueur en mètres sans répéteur > 700 m(longueur correspondant en 1989 à celle

des trains de marchandises,< 750 m, limitée par celle des gares de triages)

6 Débit du réseau 5 kbit/s(Codage d’un ‘1’ par une tension > 0,

d’un ‘0’ par une tension < 0,soit sans doute un codage de type NRZ)

– afin d’éviter des phénomènes d’éblouissement, le médium TORNAD estinterrompu par des coupleurs isolant et ne propageant pas les défauts ; destransformateurs assurent l’isolement galvanique ;

– le problème d’affaiblissement sur la paire torsadée blindée est résolu par larégénération du signal par les coupleurs ;

– le réseau est protégé d’une panne de coupleur par la connexion des coupleurs auréseau via un relais.

Le codage des bits du réseau TORNAD est un codage HDB3 (HDP – Haute DensitéBipolaire, figure 17) pour la paire torsadée blindée et, dans le cas de l’utilisation de lafibre optique, le codage choisi pour ce réseau est un codage Manchester (figure 18)[Duhot 1989]. D’autre part, la trame de données transmise dispose en fin et début detrame d’un « flag » de huit bits (‘01111110’). Etant donné les codages utilisés, ce « flag »sert à la fois à la synchronisation au niveau de l’élément binaire et du bloc d’informationtransmis (délimitation des informations en provenance de la couche liaison de données).

Le tableau 4 résume les caractéristiques de la liaison TORNAD d’après lesinformations contenues dans [Duquesnoy et Kieken 1986 ; Duhot 1989].

Tableau 4 : caractéristique de la liaison TORNAD d’après [Duquesnoy et Kieken 1986 ; Duhot 1989]



1 Type du médium Paire torsadée blindée (TGV) Fibre optiquede transmission (câble UIC utilisable)

2 Topologie du réseau ANNEAU

3 Nombre maximal 12 équipements dans le cas de pas d’exemplede stations par segment deux rames de la ligne D du

métro de Lyon MAGGALY.18 calculateurs en unité simple,

ou 36 en unité multiple dansle cas du TGV A

4 Nombre maximal Les coupleurs régénèrentde répéteurs chaque fois le signal

5 Longueur du médium 900 m TGV A

6 Débit du réseau 1 Mbit/s pour le TGV (codage Manchester)(codage HDB3)

4.2.1.3 Bus MVB et WTB de TCN

Les supports de transmission spécifiés pour le protocole de communication TCN sontceux des protocoles MVB et WTB. Ces deux protocoles ont pour codage de leurséléments binaires le codage Manchester. Le débit du bus MVB est de 1,5 Mbit/s, il est de1 Mbit/s pour le bus train WTB.

Le bus véhicule MVB comporte un ou plusieurs segments de bus qui peuvent êtrereliés par des coupleurs. Ces coupleurs sont des répéteurs pour l’interconnexion dedifférents média électriques et des coupleurs en étoile utilisés pour former un bus dans lecas d’un médium fibre optique. Trois types de médium de transmission sont définis dansla norme du réseau TCN, deux électriques (ESD et EMD) et un optique (OGF).

– Le médium ESD (Electrical Short Distance) utilise une paire de conducteurs depréférence torsadée et blindée. Les émetteurs-récepteurs de ligne doivent êtreconformes à la norme ISO 8482 (RS-485). Ce médium peut atteindre une longueurde 20 mètres et interconnecter jusqu’à 32 entités par segment, chaque segmentcomprenant un unique maître. Il est prévu pour tout lieu où une isolationgalvanique n’est pas nécessaire, typiquement les racks ou les armoires.

– Le médium EMD (Electrical Middle Distance) utilise une paire torsadée et blindéequi est terminée à chaque extrémité du bus par une impédance de ligne de120 Ohm. Ce médium est d’autre part isolé galvaniquement par transformateur. Ilpeut atteindre une longueur de 200 m et supporte un maximum de 32 entités parsegment.

– Le médium OGF (Optical Glass Fibre) est formé d’une paire de fibres optiques quiforme une liaison point à point bidirectionnelle (full-duplex). Une paire de fibrespeut connecter deux appareils entre eux ou être reliée à d’autres par un coupleur enétoile, de préférence actif, afin de former un bus. Ce médium peut atteindre2 000 m. Il est prévu pour l’interconnexion d’équipements sur de longues distancesou bien pour les environnements hautement perturbés, tels que celui deslocomotives.

Le bus train WTB comporte (figure 24) :

– un « Bus Train » pour l’interconnexion des véhicules du train, ce bus doit êtreconforme au protocole WTB, et

– des « nœuds », qui sont les équipements connectés au bus WTB servant depasserelle entre le « Bus Train » et le « Bus Véhicule ».

Figure 24 : bus train WTB et bus véhicule MVB [Kirrmann et Zuber]



Le médium du bus WTB est réalisé avec une paire cuivre torsadée et blindée.Afin de permettre l’interconnexion de 22 véhicules de 26 mètres chacun, il autorisel’interconnexion de 32 nœuds et couvre une distance de 860 mètres (des distances plus

grandes avec un maximum de 62 nœuds peuvent être réalisées). Dans le train, le câbleWTB est redondé afin que le bus soit connecté aux deux connecteurs situés à chaqueextrémité des véhicules.

Les nœuds WTB sont connectés à chacun des deux câbles par l’intermédiaire de deux émetteurs-récepteurs (transceivers) isolés galvaniquement du médium par destransformateurs. Chacun de ces émetteurs-récepteurs est utilisé pour l’émission dans une direction différente. Ils sont connectés à un encodeur/décodeur Manchester etpermettent un débit de 1 Mbit/s sur le bus. Le bus WTB supporte la duplication dumédium mais pas celle des nœuds. Un nœud émet toujours sur les deux lignes et ne reçoitles informations que de l’une ; il utilise l’autre pour vérifier que la ligne de réception esttoujours valide.

Il existe deux types de nœuds : les nœuds intermédiaires et les nœuds de fin de bus.Les nœuds intermédiaires sont situés au milieu du bus, entre les deux nœuds de fin debus. Ils relient les deux sections de câbles auxquels ils sont connectés afin de former lebus. Les nœuds de fin de bus sont situés aux extrémités du bus, l’un en tête de train,l’autre en queue. Ils n’interconnectent plus les deux sections de câbles mais les relientchacune à une terminaison de bus afin de réduire les réflexions (figure 25).L’interconnexion des sections de câble par les nœuds WTB est réalisée au cours de laphase d’initialisation du bus train. Cette phase, appelée « inauguration » du bus, estcontrôlée par le nœud maître du bus WTB. Elle permet notamment l’attributiondynamique d’une adresse à chaque nœud (voir le paragraphe 3.2.3.3. du chapitre 4).

Figure 25 : partie de l’unité MAU Medium Attachment Unit)connectée à la ligne A du bus train



4.2.1.4 Conclusion

Un premier bilan montre une longueur du bus train comprise entre 700 et 900 mètres.Des longueurs supérieures pourraient être envisagées dans l’avenir avec la prise en comptedes retours d’expérience d’applications comme celle du frein électronique qui devraitpermettre l’augmentation de la longueur des trains de marchandise. Une longueur de2 250 m est d’ailleurs en expérimentation avec la technologie LONWORKS à l’occasion desrecherches franco-allemande sur le frein électronique [Witte et al. 2001]. Les informationsà notre disposition sur la longueur du bus véhicule proviennent de TCN. Ce réseauspécifie, pour un câble métallique, une longueur maximale du bus véhicule avec isolationgalvanique par transformateur de 200 mètres. Par contre, l’ensemble des informationsprécédentes ne permet pas d’effectuer de conclusion quant au débit nécessaire du réseau.

4.2.2 Réseaux de communication non spécifiques

Les réseaux considérés dans cette section ont été répartis dans deux paragraphes selonque leur méthode d’accès au médium est de type scrutation ou contention (voir lechapitre 4).



Le tableau 5 résume les caractéristiques des bus de TCN.

Tableau 5 : caractéristique des liaisons TCN d’après [IEC_TCN_URL ;ROSIN_URLb ; TCNspecifications 1998]

MVB (bus véhicule) WTB (bus train)Bus fermé Bus ouvert

Redondance du bus possible Redondance du busoptionnelle

1 Type du médium ESD EMD OGF Utilisation d’une pairede transmission (RS-485 ; (avec isolation (fibre métallique torsadée

sans isolation par optique) blindée dédiée (du câblegalvanique) transformateur) UIC 558 s’il existe)

2 Topologie du BUS BUS Coupleur BUSréseau étoile

3 Nombre maximal 32 32 2 32 nœuds (1 ou de stations par 2 par véhicule)segment (extension possible

jusqu’à 62 nœuds)

4 Nombre maximalde répéteurs

5 Longueur sans 20 m 200 m 2 000 m 860 m (22 véhicules)répéteur (extension possible

avec répéteur)

6 Débit du réseau 1,5 Mbit/s (codage Manchester) 1,0 Mbit/s (codageManchester)

(seulement 500 kbit/ssi ancien câble UIC568)

Où l’acronyme ESD signifie Electrical short distance, EMD Electrical Medium Distance et OGF OpticalGlass Fibre.

4.2.2.1 Réseaux à accès au médium par scrutation

Les réseaux non spécifiques au secteur ferroviaire ayant un accès par scrutation sontles bus BITBUS, WorldFIP et PROFIBUS.

a. Intel BITBUS/ IEEE 1118

Le réseau BITBUS utilise le standard RS-485 (paire torsadée) pour la couchephysique et le standard SDLC (Synchronous Data Link Control – protocole de la coucheliaison de données) pour la couche liaison de données et le codage des éléments binaires.Le médium normalisé est donc la paire torsadée différentielle, mais la fibre optique estégalement possible. Le codage des éléments binaires sur la paire torsadée est le codageen bande de base NRZI.

La trame SDLC comprend en fin et début de la trame de la couche liaison de donnéesun champ « flag » dont le codage permet au récepteur, en début de réception de trame, dese synchroniser sur l’horloge de l’émetteur.

Le tableau 6 résume les principales caractéristiques de la liaison du réseau BITBUS.Ce tableau montre un débit de 375 kbit/s pour une longueur de bus maximale sans répéteurde 300 m et avec un répéteur de 900 m. Le débit du bus est limité à 62,5 kbit/s dès quedeux répéteurs sont utilisés ou pour une longueur maximale de 1,2 km sans répéteur.

Tableau 6 : caractéristique des liaisons BITBUS d’après [Ciame 1999 ;GESPAC_URL ;Elzet_80_URL ; Furrer 1998]



1 Type du médium Paire torsadée différentielle Fibre Optiquede transmission (0/5V) (RS 485)

2 Topologie du réseau BUS

3 Nombre maximal de 28 esclaves par segment en plusstations par segment, de la station maître, (249avec et sans répéteurs esclaves au maximum)

(remarque : la liaison RS485accepte 31 récepteurs)

4 Nombre maximal 1 10 Contrainte : le début d’unde répéteurs message doit être détecté dans

un délai inférieur à la durée de2 bits, soit une troncature par

répéteur d’une valeurmaximale de 2 bits ; la fin du

message doit être détectéedans un délai inférieur à la

durée de 10 bits

5 Longueur sans répéteur 300 m 1 200 m 1 000 m(avec répéteurs) (900 m) (13 200 m)

6 Débit du réseau 375 kbit/s 62,5 kbit/s 1,5 Mbit/s, 3 Mbit/s(débit standard)

(codage NRZI)

b. WorldFIP

Le réseau WorldFIP accepte pour médium de transmission la paire torsadée et la fibreoptique (tableau 7). Un débit de 1 Mbit/s pour une longueur maximale sans répéteur de

1 km et un débit de 2,5 Mbit/s pour une longueur de 500 m sont possibles avec un médiumde type paire torsadée. Ces débits et longueurs se rapprochent de ceux des bus de TCN.

Le codage utilisé pour la transmission des données est le Manchester. Il permet latransmission simultanée de l’horloge et de la donnée. Deux champs ont un codageparticulier différent du code Manchester. Ces champs « délimiteur de début de trame »(‘1V+V–V+V–101’) et « délimiteur de fin de trame » (‘1V+V–10V–V+0’) servent aussibien à la synchronisation au niveau de l’élément binaire qu’au niveau du blocd’information transmis (délimitation des informations en provenance de la couche liaisonde données). La figure 26 montre l’ensemble des codes utilisés par ce réseau.

Figure 26 : codage des éléments binaires du réseau WorldFIP



Tableau 7 : caractéristique des liaisons WorldFIP d’après [ALS_50414b-en 1998]

1 Type du médium detransmission

fil métallique – paire torsadée fibre optique

2 Topologie du réseau BUS Connexion point à point, utilisationde coupleurs actifs en étoile

3 Nombre maximal destations par segmentsans répéteur

256 256

4 Nombre maximal derépéteurs

ND7 à ladate du

03. 1998

44 3 4

5 Longueur sans répéteur(avec répéteurs)

5 000 m(ND)

1 600 m(7 000 m)

? ?

6 Débit du réseau 31,5 kbit/s 1 Mbit/s 2,5 Mbit/s 5 Mbit/s

1 000 m(5 km)

500 m(2 km)

1 Mbit/s 2,5 Mbit/s

Des exemples de circuits de ligne pour le réseau WorldFIP sont les suivants [WorldFIP_URL]. Le circuit deligne « CREOL » (CREOL Line Driver) avec isolation par transformateur tourne à 1 Mbit/s ou 2,5 Mbit/s eta une interface pour les contrôleurs de communication FIPIU et FIPCO1 (voir aussi le paragraphe 4.5 duchapitre 2). Le circuit de ligne FIELDRIVE fournit une interface entre le médium et un processeur decommunication tel que FULLFIP2 sans isolation. L’utilisation du transformateur FIELDTR permet alors uneisolation du médium WorldFIP pour des débits de 31,25 kbit/s, 1 Mbit/s et 2,5tMbit/s.

7 ND : Non défini.

c. PROFIBUS

La couche physique de PROFIBUS se décline selon deux versions d’après[EN_50170_2 1996] :

– la version 1

Les éléments binaires sont codés en NRZ. Cette version est utilisée avec la liaisonEIA RS-485. Les coupleurs de lignes cibles sont bas coût et peuvent ou non êtreisolés galvaniquement de la ligne. Des terminaisons de lignes sont nécessaires, enparticulier pour les hauts débits. Le débit maximal est de 1,5 Mbit/s.

– la version 2

Cette couche physique est conforme à la norme IEC 1158-2. Elle a été conçue pourdes environnements nécessitant une haute sécurité intrinsèque et pour améliorer lacompatibilité électromagnétique. Cette version accepte différentes topologies(notamment la topologie arbre). Les coupleurs de lignes consomment moins decourant et réduisent l’influence des stations défaillantes sur le bus.

Les média acceptés par le réseau PROFIBUS sont la paire torsadée pour une liaisonRS 485, la fibre optique et la paire torsadée pour une transmission IEC 1158-2(tableaux 8 et 9). L’utilisation de la fibre optique est également possible d’après [Profibus1999] (tableau 10).



Tableau 8 : caractéristique de la liaison RS 485 du bus PROFIBUS [Profibus 1997 ; 1999 ; EN_50170_2 1996]


Liaison RS 485 : paire torsadée blindée ou non (blindage facultatif selon environnement CEM)

2 Topologie du réseau(« dénomination particulière au protocole »), Terminaison de ligne

BUS (« topologie linéaire »)

Terminaison active

3 Nombre maximal de stations par segment

32 sans répéteur127 avec répéteurs


3(Lignes de jonctions limitées aux débits Ò 1,5 Mbit/s)

Liaison RS 485 PROFIBUS DP ET FMS

5 Longueur pour un câble de Type A

1 200 m 1 000 m 400 m 200 m 100 m

Longueur pour un câble deType B

1 200 m 600 m 200 m 70 m

6 Débit du réseau pour uncâblage de type A ou B

9,6 kbit/s19,2 kbit/s ou93,75 kbit/s

187,5 kbit/s 500 kbit/s 1,5 Mbit/s 12 Mbit/s

Câble de type A : impédance 135 à 165 Ý (f = 3 à 20 MHz) ; capacité < 30 pF/m ; résistance de boucle110 Ý/ km ; diamètre du conducteur 0,64 mm ; section du conducteur > 0,34 mm2.Câble de type B : impédance 100 à 130 Ý (f > 100 kHz) ; capacité < 60 pF/m ; résistance de boucle nonprécisée ; section du conducteur > 0,22 mm2.

(codage NRZ)

Dans le cas de l’utilisation d’une liaison RS 485, deux types de câbles sont possibles[EN_50170_2 1996] (tableau 8) sans utilisation de répéteurs. Un débit de 1,5 Mbit/s peutêtre obtenu pour une longueur maximale de 200 m et un débit de 187,5 kbit/s pour unelongueur de 1 km. Les valeurs du premier couple « débit longueur » se rapprochent decelles données pour le bus véhicule MVB. Par contre, les débits sur de grande longueur,sans utilisation de répéteur, sont moindres.

Le codage NRZ de la liaison RS-485 ne permet pas de synchroniser les horloges del’émetteur et du (des) récepteur(s). Par contre, la trame PROFIBUS code ses champsd’information selon le format des caractères UART. Ainsi pour une information utile de8 bits, un « bit start » est ajouté en début d’octet, un bit de parité en fin d’octet, suivi d’un« bit stop ». Ce codage des champs selon celui du mode de transmission asynchronepermet une synchronisation octet et évite une trop forte dérive au niveau binaire entre leshorloges de l’émetteur et des récepteurs.



Tableau 9 : caractéristique de la liaison CEI 1158-2 du bus PROFIBUS [Profibus 1997 ; 1999]

Médium métallique, profilapplicatif :

PROFIBUS PA (Transmission CEI 1158-2, application chimie et pétrochimie ; elle autorise la sécurité intrinsèque et

la téléalimentation des modules via le bus.)


Paire torsadée blindée ou non/Transmission CEI 1158-2

2 Topologie du réseau(« dénominationparticulière auprotocole »), Terminaison de ligne

BUS(« topologie linéaire et arborescente »)

Terminaison de ligne passive

3 Nombre maximal destations par segment

32 sans répéteur126 avec répéteurs


4

5 Longueur sans répéteur La longueur maximale est de 1 900 mElle dépend de la tension d’alimentation, des exigences maximales en

courant, de la section nominale du câble (voir [Profibus 1999])

6 Débit du réseau 31,25 kbit/s, Mode Tension (codage Manchester)

Tableau 10 : propriétés de la fibre optique d’après [Profibus 1999]

Médium fibre optique Portée

Verre, multimode Moyenne (2 à 3 km)

Verre, monomode Longue (> 15 km)

Plastique Courte (< 80 m)

PCS/HCS Courte (400 m)

4.2.2.2 Réseaux à accès au médium par contention

Les réseaux non spécifiques au secteur ferroviaire ayant un accès par contention sontles bus CAN et LONWORKS.

a. CAN

Un réseau CAN a été utilisé en Allemagne à l’occasion de recherche sur le frein àcommande électronique [Witte 1998]. Des essais ont été faits pour des trains de fret delongueur 700 mètres utilisant pour bus train et bus véhicule la technologie CAN. Le trainayant servi pour les essais connectait 22 wagons à une locomotive. La connexion desnœuds du bus véhicule se faisait par l’intermédiaire de relais (figure 27). Le débit choisipour le bus train était de 10 kbit/s, laissant ainsi une marge par rapport au débit maximalthéorique de 70 kbit/s pouvant être obtenu avec un câble de longueur 1 000 m (longueurtenant compte de celle du train et des méandres du câble à l’intérieur du train). Le busvéhicule travaillait à 100 kbit/s.

Figure 27 : exemple de relais utilisé avec un bus train et bus véhicule en technologie CAN (source [Witte 1998])



La norme CAN ne définit pas de médium et d’interface physique particulière. Lemédium de transmission d’un réseau CAN peut ainsi être une paire torsadée, un câble ennappe, le courant porteur ou la fibre optique. Elle accepte par exemple pour la pairetorsadée une liaison RS 485. Il existe également dans le commerce des émetteursrécepteurs de ligne spécifiques pour ce même médium. D’après [Paret 1996], des liaisonsCAN propriétaires à infrarouges existent également.

Les valeurs données dans le tableau 11 sont celles couramment fournies dans lesdocuments CAN pour un médium « paire torsadée différentielle ».

Les fortes contraintes « débit-longueur » du réseau CAN mises en évidence par letableau 11 proviennent de la méthode d’accès au médium de cette technologie (sous-couche MAC) qui impose à une station émettrice de pouvoir détecter une collision surl’élément binaire en cours d’émission afin de cesser de suite, en cas de contention, toutetransmission avant le temps imparti pour celle de l’élément binaire suivant (voir leparagraphe 4.2 du chapitre 4).

Ces contraintes imposent de prendre quelques précautions dans l’utilisation derépéteurs dans un réseau CAN. Il a été écrit au chapitre 2 que la longueur du câble pouvaitêtre augmentée par l’utilisation de répéteurs. Cependant, « afin d’éviter un effet derebouclage immédiat de la sortie vers l’entrée », un retard, généralement de l’ordre de



Tableau 11 : caractéristique d’une liaison CAN d’après [GESPAC_URL ; Paret 1996]

1 Type dumédium de

paire torsadée différentielle

2 Topologie du réseauTerminaison de ligne

BUS

Terminaison : résistance de terminaison

3 Nombremaximal destations parsegment

30 sans répéteur

4 Nombremaximal derépéteurs

5 Longueur enmètres

10 km 6,7 km 3,3 km 1,3 km 620 m 530 m 270 m 130 m 40 m 10 m

6 Débit du réseau (*)

5kbit/s

10kbit/s

20kbit/s

50kbit/s

100kbit/s

125kbit/s

250kbit/s

500kbit/s

1Mbit/s

1,6Mbit/s

Codage NRZ avec bourrage de bit

Les correspondances entre débit et longueur maximale du médium de type « bus » sont données pour([Paret 1996]) :– des tolérances de l’oscillateur inférieures à 0,1 % ;– une vitesse de propagation de la ligne inférieure à 5 ns/m ;– une somme maximale des retards introduits par les circuits électroniques de l’émetteur et du récepteur de70 ns à 1,6 Mbits, 90 ns de 250 kbit/s à 1 Mbit/s et de 300 ns de 5 kbit/s à 125 kbit/s.* Deux couches physiques CAN sont normalisées pour l’automobile. La norme ISO 11519 d’avril 1995 estdédiée aux applications bas débit, soit inférieure à 125 kbit/s (« Véhicules routiers. Communication en sériede données à basse vitesse. Partie 1 : généralités et définitions. Partie 2 : réseau local à commande à bassevitesse (CAN). »). La norme ISO 11898 d’avril 1995 est dédiée aux applications haut débit, soit inférieure à1 Mbit/s (ISO 11898 : avril 1995, « Véhicules routiers. Échange d’information numérique. Gestionnaire deréseau de communication à vitesse élevée (CAN) »). Différents émetteurs/récepteurs CAN, conçus pourl’automobile, peuvent être trouvés dans le commerce, par exemple des transceivers tolérants aux fautespour des débits inférieurs à 125 kbit/s et un double médium cuivre, des transceivers haut débit pour desdébits supérieurs à 125 kbit/s et jusqu’à 1 Mbit/s sur double médium cuivre et enfin des transceivers pourun médium simple fil et des débits également inférieurs à 125 kbit/s.

200 à 300 ns, est introduit pour le passage du ‘0’ au ‘1’ et le plus rapidement possible pourcelui du ‘1’ vers ‘0’ [Paret 1996]. Cette introduction d’un retard supplémentaire par lerépéteur est à considérer comme une augmentation de la longueur physique apparente duréseau. Cette longueur est de l’ordre de 40 à 50 mètres de fil supplémentaire sur le réseaupour un médium standard où le signal se propage à environ 5 ns/m et pour un retardintroduit de 200 à 250 ns. Elle devient négligeable pour un réseau d’une longueur de unà quelques kilomètres qui fonctionne à des débits assez lents [Paret 1996]. Elle ne l’estpas pour un réseau CAN fonctionnant à 1 Mbit/s, soit dont la longueur maximale dumédium est d’environ 40 m.

La figure 28, extraite de [Paret 1996] est un exemple d’utilisation de répéteurs avecla technologie CAN. [Paret 1996] attire l’attention sur la « segmentation multiple enplusieurs tronçons, permettant de réduire apparemment l’influence d’un cumul sériel desretards [...] contrairement à leurs dispositions topologiques en parallèle. »

Figure 28 : exemple d’utilisation de répéteurs dans un réseau CAN (source [Paret 1996])



Les bits du protocole CAN sont codés en codage « NRZ avec bourrage de bit »(figure 29). Ce bit de bourrage est inséré à l’émission après le cinquième bit d’une séried’au moins six éléments binaires identiques. Il sert à distinguer cette information d’unsignal d’erreur (paragraphe 4.2.2 du chapitre 4) ou d’une fin de trame (sept bits récessifsplus trois bits récessifs de délai inter trame). Il permet également de remédier au manquede transitions du codage NRZ en cas de transmission d’une trop longue série d’un mêmeélément binaire. Un nombre minimal de transitions est donc garanti. Notons égalementque le protocole CAN définit aussi une plage de tolérance entre les horloges générées etcelle de la détection d’un bit. Enfin, le top de synchronisation entre l’émetteur et lerécepteur est donné par le champ SOF (Start of Frame) de début de la trame CAN. Cechamp, ainsi que le champ de fin de trame EOF (End of Frame) permettent lasynchronisation au niveau du bloc d’information transmis.

Bien que le codage du protocole CAN soit à la base un codage NRZ, le bourrage debit réalisé enlève au signal NRZ sa composante continue et permet alors une isolationgalvanique aussi bien par transformateurs que par optocoupleurs.

b. LONWORKS

La couche physique n’est pas spécifiée dans le protocole LonTalk du réseauLONWORKS. Par conséquent, le réseau accepte une large gamme de média telle que lapaire torsadée, les câbles d’alimentation en cuivre, les câbles coaxiaux, la fibre optique,l’infrarouge et la fréquence radio.

Le protocole LonTalk définit par contre des paramètres topologiques selon les médiade transmission choisis. Par exemple, ceux définis pour la paire torsadée sont lesparamètres de terminaison de bus et de « topologie libre ». Les deux topologies incluentune transmission du courant sur le lien. Pour cela, deux types de câble peuvent êtreutilisés. L’un a cinq fils, deux pour la transmission des données, deux pour l’alimentationet un pour le blindage. L’autre, utilisé dans les systèmes « link power », a seulement deuxfils pour le transfert des données et de l’alimentation.

Les caractéristiques de la paire torsadée, sans utilisation de répéteurs, sont données autableau 12.

Le circuit utilisé dans le projet franco-allemand FEBIS du frein électronique est lePLT-10A permettant une transmission sur courant porteur [Grasso et al. 2001]. Ce circuitoffrant un débit de 10 kbit/s (tableau 13) n’est plus en fabrication et n’a pas à ce jour deremplaçant.

Les émetteurs-récepteurs LONWORKS cités dans les tableaux 12 et 13 (à l’exceptiondu PLT-10 A) sont disponibles chez Echelon Corporation.



Figure 29 : codage NRZ des bits CAN avec bourrage de bits [Paret 1996]

Tableau 13 : médium courant porteur [Echelon_URL]

1

6

Type du médium detransmission

Courant porteur

Débit du réseau 10 kbit/s à 10 MHzPLT9-10 A

5 kbit/sPLT-22

Technique de transmission

DS (Direct sequence spread)spectrum

BPSK (Binary Phase Shift Keying)avec un récepteur DSP amélioré

Bande de fréquence 100-140 kHz (à 10 MHz) bande primaire : 125-140 kHzbande secondaire : 110-125 kHz

8 TPT : Twisted Pair Transceiver ; FTT : Free Topology Twisted pair transceiver ; LPT : LinkPower Twisted pair transceiver9 PLT : Power Line Transceiver



Tableau 12 : caractéristique de la paire torsadée LONWORKS

[Schickhuber et McCarthy 97a ; 1997b ; Echelon_URL]

1 Type du médiumde transmission

Paire torsadée(récepteur/émetteur TPT8/XF-78, TPT/XF-

1250, FTT/FT-10A, RS 485)

Paire torsadée transportantl’alimentation et les données

(LPT-11)

2 Topologie duréseau(« dénominationLONWORKS »)Terminaison deligne

3 Nombre maximalde stations parsegment

4 Nombre maximalde répéteurs

5 Longueur

6 Débit du réseau

BUSDouble terminaison

CombinaisonBUS et

ANNEAU(« topologie

libre »)

BUSDouble

terminaison

CombinaisonBUS,

ETOILE,ANNEAU

(« topologielibre »)

64sans répéteur

128sans répéteur

Fonction de la sortie du« transceiver » LPT-11 :

128 si sortie de 5 V et 25 mA64 si sortie de 5 V et 50 mA32 si sortie de 5 V et 100 mA

2 700 m 130 m 500 m 2 200 m 500 m

78 kbit/scomposantTPT/XF-78

1,25 Mbit/scomposant

TPT/XF-1250

78 kbit/scomposant

FTT/FT-10A

78 kbit/scomposant LPT-11

(codage Manchester différentiel)



Tableau 14 : codage des éléments binaire, synchronisation et isolation galvanique pour un médium paire torsadé

Réseau Codage en bande de base Synchronisation via lecodage

Isolation galvaniquepar transformateur

possible

MUX G ? ?

TORNAD HDB3 Oui, transitions garanties oui

Manchester(fibre optique)

Horloge codée

TCN MVB Manchester Horloge codée oui

WTB Manchester Horloge codée oui

WorldFIP Manchester Horloge codée oui

PROFIBUS PA Manchester Horloge codée oui

DP etFMS

NRZ Horloge non codée, maiscodage des caractères dela trame au format UARTavec bit start et bit stop,

d’où des transitionsgaranties

?(oui par optocoupleur)

BITBUS NRZI

CAN NRZ avec bourrage de bit

Oui, transitions garantiespar le bourrage de bit

oui

LONWORKS (pour lestransceivers cités autableau 12)

Manchester différentiel Horloge codée

4.3 Conclusion

Il est difficile d’effectuer une conclusion générale d’après les informations fourniesci-dessus. Les valeurs données pour les longueurs et débits sont en effet indicatives carse reportant chaque fois à un type de médium particulier. D’autre part, le choix des médiautilisés ou testés aujourd’hui dans le ferroviaire varient selon le choix du réseau. On peutciter par exemple les câbles UIC 568 ou UIC 558 en bande de base pour le bus train WTBde TCN ou encore un médium « courant porteur » pour un bus train LONWORKS.

Toutefois, nous reportons dans les tableaux ci-dessous, d’une part, les codages de cesréseaux et leur possibilité ou non d’accepter une isolation galvanique (tableau 14) et,d’autre part, les différentes valeurs des couples « longueur-débit » pour un médium detype paire différentielle (tableau 15).



Tableau 15 : bilan des longueurs et débits des réseaux comparés à ceux de TCN

Bus Véhicule (bus fermé, redondance du bus possible)

Nom du bus Nombre maximal de stations par segment ; (longueur du segment ; débit)

MVB (Bus) ESD : 32 ; (20 m ; 1,5 Mbit/s) EM : 32 ; (200 m ; 1,5 Mbit/s)

BITBUS 28 + 1 ; (F300 m ; 375 kbit/s)

WorldFIP 256 ; (F500 m ; 2,5 Mbit/s)

PROFIBUS type B : 32 ;(70 m ; 1,5 Mbit/s)

type A : 32 ;(200 m ; 1,5 Mbit/s

CAN 30 ; (10 m ; 1,6 Mbit/s)30 ; (40 m ; 1 Mbit/s)

30 ; (130 m ; 500 kbit/s)30 ; (270 m ; 250 kbit/s)

LONWORKS

Bus Train (bus ouvert, redondance du bus obligatoire)Utilisation d’une paire métallique torsadée blindée dédiée (du câble UIC 558 s’il existe)

Nom du bus Nombre maximal de stations par segment ; (longueur du segment ; débit)

WTB (Bus) UIC 558 : 32 ;(860 m ; 1 Mbit/s)

UIC 568 : 32 ;(860 m ; 500 kbit/s)

(1 ou 2 nœuds par véhicule, 22 véhicules, extension possible de la longueurdu bus et du nombre de nœuds connectés, jusqu’à 62, avec répéteurs)

BITBUS

WorldFIP 256 ; (1 000 m ; 1 Mbit/s)

PROFIBUS type A : 32 ; (1 000 m ; 187,5 kbit/s)

CAN 30 ; (620 m ; 100 kbit/s)30 ; (1 300 km ; 50 kbit/s)

LONWORKS 28 + 1 ; (1 200 m ; 62,5 kbit/s)

Chapitre 4

Méthodes d’accès au médium de communication

et trames de données

1. IntroductionLe contrôle de l’accès au médium de communication est assuré par la sous-couche

basse MAC (Medium Access Control) de la couche « liaison de donnée » (couche 2 dumodèle de référence OSI). Ce contrôle d’accès au médium a pour objectif un partageoptimal du canal de transmission entre les abonnés. Les méthodes d’accès au médiumsont variées et si quelques couches MAC sont normalisées IEEE, beaucoup de réseauxont la leur.

Les techniques de contrôle d’accès peuvent être synchrones ou asynchrones(figure 1).

Figure 1 : techniques de partage du médium de transmission (fait à partir des informations contenues dans [Summers 2000 ; Obracza et

al. 2000 ; Rolin 1990 et 1999 ; Lagrange et Seret 1998 ; Thomesse 1999])


Dans le cas d’une approche synchrone, une capacité spécifique du canal detransmission est réservée à un nœud. Cette technique, non optimale pour les réseaux LANet MAN en raison de leur trafic irrégulier, est utilisée dans la commutation de circuit parles techniques synchrones FDM (Frequency Division Multiplexing – technique de partagedu canal par multiplexage fréquentiel) et TDM (Time Division Multiplexing – techniquede partage du canal par multiplexage temporel).

Selon l’approche asynchrone, on peut distinguer les techniques d’accès contrôlésRound Robin et réservation et les techniques à accès aléatoires dites de contention.

– Dans l’approche Round Robin, chaque nœud possède un tour de transmission aucours duquel il a l’autorisation de transmettre une certaine quantité de donnéeslimitée soit en taille, soit par le temps de transmission maximal alloué pour chaqueéchange. Cette technique est efficace pour des charges de trafic élevées.

– La réservation est une technique proche de la technique synchrone TDM (TimeDivision Multiplexing), pour laquelle un nœud souhaitant transmettre des donnéesréserve au préalable des intervalles de temps pour une période étendue voireindéfinie. Cette technique est adaptée au transport de chaîne de données (voix,transmission de fichiers volumineux), mais ne l’est pas au trafic irrégulier des LAN.

– La troisième technique est la contention10 (la littérature parle également deprotocoles à compétition). Ici, les nœuds tentent d’émettre indépendamment les unsdes autres provoquant parfois des collisions11 qui nécessitent l’existence d’unestratégie de ré-émission ultérieure de l’information. Cette technique repose surl’algorithme CSMA (Carrier Sense Medium Access) pour lequel tout nœud avantd’émettre doit détecter une non-activité sur le bus pendant un intervalle de tempsdéfini par le protocole du réseau étudié. Cette technique, adaptée au trafic dedonnées événementiel, est efficace pour un trafic normal de données, mais le réseaupeut s’effondrer en cas d’avalanche d’événements d’exception (alarmes...).

Le contrôle d’accès au médium peut être centralisé ou décentralisé. Dans uneapproche centralisée, un contrôleur central gère l’accès au réseau des autres nœuds. Dansune approche distribuée, les stations réalisent collectivement une fonction de contrôled’accès au médium pour déterminer l’ordre dans lequel elles vont transmettre. Unavantage de l’approche centralisée est d’offrir un accès logique simple à chaque station en évitant les difficultés liées à la coordination distribuée des stations. Par contre, le contrôleur centralisé constitue un goulet d’étranglement pour lescommunications et entraîne en cas de défaillance l’arrêt du réseau [Summers 2000].L’approche décentralisée pallie ces deux difficultés, moyennant un accès logique pluscomplexe.



10 Contention : situation qui se produit lorsque plusieurs stations se mettent à transmettresimultanément sur le bus de communication [VAN 1989] ; état du bus lorsque deux stationsou plus émettent des niveaux différents [SAE_J1213/1 1991].11 Collision : phénomène de niveau physique qui intervient lorsqu’il y a superposition deplusieurs signaux d’origine interne (stations connectées au bus) ou externe (bruit).Synonyme : interférence [VAN 1989].

Parmi les trois techniques précédemment citées, les protocoles des réseaux decommunication filaires adoptés pour les matériels roulants ferroviaires utilisent lestechniques de multiplexage asynchrone suivantes :

– techniques Round Robin

• jeton sur anneau (TORNAD) et jeton sur bus (TORNAD*, PROFIBUS, MVB) ;

• scrutation (WorldFIP, MVB, WTB, PROFIBUS, BITBUS) ;

– techniques de contention CSMA (CAN, LONWORKS, MVB).

Nous allons considérer ces dernières plus en détail dans les prochains paragraphes.Ceux-ci vont présenter tour à tour :

– les techniques à passage de jeton ;

– les méthodes d’accès par scrutation ;

– les protocoles à compétition.

Dans chacun de ces paragraphes, une introduction rappellera les grandes lignes de cesprotocoles d’accès au médium. Ensuite, pour chacun des réseaux concernés par laméthode introduite, des caractéristiques propres à ces réseaux seront expliquées et leformat des trames de communication, au moyen desquelles se font les échanges sur lebus, sera donné.

2. Accès par passage de jeton (token)

2.1 Introduction sur les protocoles IEEE 802.4 et 802.5

Les deux topologies de réseaux adaptées à la technique d’accès au médium parpassage de jeton sont l’anneau (réseau token-ring ou à passage de jeton sur anneau) et lebus (réseau token-bus ou à passage de jeton sur bus).

Le réseau token-ring initialement développé par IBM dans les années 1970 a servipour la spécification de la norme IEEE 802.5 du réseau à jeton sur anneau. Cette normeet le réseau token-ring d’IBM ont quelques différences mais restent totalementcompatibles, la norme IEEE 802.5 suivant les évolutions du réseau IBM d’origine[CISCO_URL]. Le réseau token-bus, normalisé 802.4, utilise une politique d’accès aumédium par jeton sur une topologie bus (figure 2).

Dans les réseaux à passage de jeton, le contrôle d’accès est décentralisé et se fait parl’intermédiaire d’une trame dénommée le « jeton » qui circule de station en station àtravers le réseau. Le jeton symbolise le droit de parole. La possession du jeton par unestation lui donne donc le droit d’accès au médium. Aucune collision ne peut alors seproduire.

Dans le cas du réseau à jeton sur anneau, l’ordre de circulation est celui défini par laconnexion des stations. Dans celui d’un réseau à jeton sur bus, les stations sont organiséeslogiquement selon un anneau virtuel qui définit la place de chacune [Rolin 1990]. Chaquestation a un successeur logique qui ne dépend plus de la connectique mais qui est définien utilisant les adresses des nœuds.

Méthodes d’accès au médium de communication et trames de données


Deux types de trames sont définis pour ce protocole de communication, la trame jetonet la trame d’information. Une station ayant des données à émettre se saisit de la tramejeton lorsqu’elle lui parvient et modifie (protocole IEEE 802.5) un élément binaire decette trame qui la transforme en séquence de début de trame [CISCO_URL]. Lesinformations sont ensuite insérées dans la trame. La trame jeton ne sera ré-émise sur leréseau que lorsque la trame information aura parcouru l’anneau (réel ou virtuel) et serarevenue à la station émettrice. Lorsque la trame arrive à la station destination, celle-cirecopie localement l’information contenue. En fin de tour, la station émettrice la retire etpeut vérifier l’intégrité du contenu de cette trame retournée. Elle re-transmet à la placeune trame jeton (figure 3).

Figure 3 : méthode d’accès par passage de jeton sur anneau du protocole IEEE 802.5



Figure 2 : jeton sur anneau et jeton sur bus

Il existe des protocoles token-ring dont la gestion du jeton varie légèrement de cetteméthode. Par exemple, dans la méthode d’accès FDDI (Fiber Distributed Data Interface,standard ANSI X3T9.5 depuis 1980, [CISCO_URL]), le jeton est ré-émis immédiatementaprès la transmission de la trame d’information. Une autre station émettrice peut alors sesaisir du jeton et émettre une trame d’information à la suite d’une précédente avant quecelle-ci n’ait effectué le tour complet du réseau (figure 4). Conformément à la méthodeIEEE 802.5, chaque trame émise sera retirée par sa station émettrice après un tour.

Figure 4 : méthode d’accès par passage de jeton sur anneau du protocole FDDI



Le réseau IEEE 802.5 définit un système de priorité qui permet à des stations dehautes priorités d’accéder plus fréquemment au réseau. Pour cela la trame d’informationcontient deux champs contrôlant la priorité, l’un de priorité et l’autre de réservation.Seules les stations de priorité égale ou supérieure à celle indiquée dans la trame jetonpeuvent se saisir du jeton. Après que la trame jeton ait été saisie et changée en trame

d’information, seules les stations de plus grandes priorités que la station émettricepeuvent réserver le jeton pour le prochain tour. Quand le jeton suivant est généré, ilcontient alors la valeur de priorité la plus haute parmi les stations ayant souhaité leréserver. Les stations qui augmentent le niveau de priorité du jeton remettent l’anciennepriorité après avoir réalisé leur transmission [CISCO_URL].

Des fonctions de maintenance de la boucle sont dupliquées sur chaque station afin demaintenir les communications sur le réseau [Rolin 1990]. Ces fonctions sont celles del’initialisation de la boucle, de la régénération du jeton, de l’addition d’une nouvellestation et de la gestion du passage du jeton. Par exemple, dans le cas du réseau token-bus,l’opération d’addition d’une nouvelle station est réalisée à l’aide d’un algorithme decontention exécuté périodiquement. Afin de ne pas bloquer le réseau en cas de perte dujeton et de permettre un accès au réseau équitable à toutes les stations, un délai deretransmission d’une trame jeton, qui tient compte du délai de transmission et decirculation d’une trame d’information, est imposé dans le réseau IEEE 802.5.

2.2 Protocole d’accès aux réseaux TORNAD et TORNAD*

2.2.1 TORNAD

2.2.1.1 Méthode d’accès

Les communications sur l’anneau TORNAD se font selon un protocole à jeton suranneau [Duhot 1989]. La gestion du réseau TORNAD est assurée par un coupleurcontrôleur qui génère le jeton à l’initialisation du réseau et veille à le régénérer en cas dedisparition.

Lors de l’initialisation du système, un coupleur prend le statut de « contrôleur », unautre celui « d’Equipement potentiellement contrôleur » (EPC) de façon à pallier ladéfaillance du contrôleur : l’EPC devient contrôleur lorsqu’il détecte une non activitéprolongée sur le réseau. Lorsque deux rames sont accouplées, le train comporte uncontrôleur et trois EPC de priorités différentes. Le contrôleur étant dans la première rame,l’EPC le plus prioritaire se situe dans la seconde rame. Les priorités des EPC sont tellesque cette alternance contrôleur-EPC reste valable pour chaque dégradation du système.Cette alternance permet également la détection du découplage des rames et ainsi lareconfiguration du réseau en deux anneaux distincts.

L’ensemble des coupleurs a deux modes de fonctionnement :

– « le mode transparence » dans lequel un coupleur se comporte comme un répéteurbidirectionnel et mémorise les trames qui lui sont adressées,

– « le mode émission » dans lequel un coupleur passe pour émettre sa tramed’information après avoir récupéré celle du jeton qu’il régénérera en fin d’émissiondu message. En cas de disparition du jeton, c’est dans ce mode que le coupleur« contrôleur » passe pour initialiser ou reconfigurer le réseau.

La technique de passage du jeton sur anneau est différente de celle du protocole IEEE802.5. Comme dans le cas du protocole FDDI, le jeton n’est pas gardé après transmissionde la trame. Une station en mode émission saisit le jeton, transmet sa trame



d’information, restitue ensuite la trame jeton. Si une station suivante souhaite transmettreà son tour, elle se saisira en mode émission du jeton après avoir laissé passer la tramed’information. Elle émettra la sienne à la suite, puis transmettra le jeton. Une stationémettrice attend avant de passer en mode transparence que la trame qu’elle a émise luirevienne après un tour complet. Elle la retire alors du réseau.

En cas de défaillance et de façon à tolérer une ouverture dans la ligne de transmissionou un court-circuit, le réseau peut être reconfiguré en « mode Ping-Pong » (figures 5et 6). Dans ce mode, les équipements se trouvant de part et d’autre du défaut sont chargés



Figure 5 : circulation des messages dans TORNAD [Duquesnoy et Kieken 1986 ; Duhot 1989]

Figure 6 : mode « ping-pong » du régime perturbé de TORNAD [Duhot 1989]



de réfléchir le jeton lorsqu’il leur parvient en changeant sa parité [Duhot 1989]. Suite àune cassure de la boucle physique, l’opération de reconfiguration se fait dynamiquementde la façon suivante. Après une détection multiple de perte de jetons, une tentative dereconfiguration en boucle est effectuée en émettant un jeton trois fois dans un sens, puistrois fois dans le sens opposé. En cas d’échec, les coupleurs de part et d’autre de lacassure de l’anneau sont déterminés. Ils passent alors en « mode extrémité » (de bus). Lenouveau fonctionnement du réseau TORNAD avec une topologie bus (régime perturbé)est illustré en figure 6.

2.2.1.2 Format de la trame TORNAD

La trame TORNAD suit la structure de la trame HDLC (figure 7). Elle permet troistypes d’adressage, un adressage simple pour la diffusion d’un message auprès d’undestinataire (5 bits permettent d’adresser jusqu’à 32 entités), un adressage de groupe pourla diffusion du message auprès d’un ensemble d’équipements et enfin un adressagegénéral pour une diffusion du message à tous les équipements du réseau (3 bits utiliséspour la définition de 8 groupes) [Duhot 1989]. L’adressage de groupe autorise ladéfinition d’un maximum de sept groupes spécifiés statiquement à l’initialisation oudynamiquement en cours d’exploitation. TORNAD réserve le mode d’adressage généralaux applications de surveillance et de gestion du réseau.

2.2.2 TORNAD*

Le réseau TORNAD* est un réseau à jeton sur bus. Nous n’avons pas trouvé plusd’information sur ce réseau.

Figure 7 : structure de la trame TORNAD

2.3 Autres réseaux : les bus MVB et PROFIBUS

Nous verrons dans les paragraphes suivants qu’une technique de scrutation a étéégalement adoptée pour le protocole MVB du réseau TCN et le protocole PROFIBUS.Cette technique sert aux échanges entre la station maître et des stations esclaves.

Par contre, le protocole d’élection d’un nouveau maître du bus repose sur uneméthode d’accès par passage de jeton sur bus (figure 8). Le protocole MVB utilise cetteméthode pour assurer une redondance de l’administrateur de bus maître, soit ducontrôleur centralisé qui gère les échanges avec les esclaves sur le bus. Cette méthode està la base du protocole multi-maîtres de PROFIBUS (échange multi-maîtres multi-esclaves). Elle permet un partage des scrutations de différents groupes d’esclaves pardifférents maîtres en autorisant la prise de contrôle du bus tour à tour par les maîtres.

3. Accès par scrutation (polling)

3.1 Introduction

Les deux topologies de réseaux adaptées à cette technique sont le bus et l’étoile. Lecontrôle d’accès au médium est géré par une unité centrale (topologie étoile), qui donnela parole à tour de rôle aux stations, ou à un contrôleur unique (topologie bus), qui allouel’utilisation du bus. Une station (ou nœud) ne peut transmettre des données que surscrutation de ce contrôleur.

Les échanges sur ces réseaux sont de type mono-maître multi-esclaves (ou maître-esclaves). Seul le contrôleur maître du bus peut initier un échange d’informations,une entité esclave ne peut émettre sur le bus que sur requête du maître. Les communicationsse font alors sous forme de télégrammes, c’est-à-dire d’un ensemble de deux tramescomposé d’une trame de requête maître et d’une trame de réponse esclave (figure 9).



Figure 8 : techniques d’accès au médium choisies pour les bus MVB et PROFIBUS



Figure 9 : illustration d’un « télégramme »

La transmission des informations sur un bus exploite la capacité de diffusion de latechnologie bus. Elle repose sur les notions de « producteur » et de « consommateur »selon la dénomination WorldFIP ou de « source » et « puits » selon celle de TCN(figure 10). Ainsi, chaque station sur le bus est susceptible de remplir l’une ou l’autre desfonctions de consommation ou de production. A un instant donné, il ne peut exister qu’ununique producteur d’une variable identifiée au moyen du champ d’adresse de la requêtedu contrôleur. Ce producteur transmet la variable attendue en réponse à la requête. Cettevariable disponible sur le bus est « consommée » par toute station intéressée.

Figure 10 : « Stations » et « Arbitre de Bus » du protocole WorldFIP

La figure 11 montre comment le contrôleur (l’arbitre de bus selon la dénominationWorldFIP) invite le producteur d’une variable à la transmettre en utilisant l’adresselogique (l’idendificateur ID) de cette variable. Les algorithmes utilisés lors de la phasepériodique par les protocoles MVB et WTB sont similaires à celui-ci.

Figure 11 : protocole d’accès maître-esclaves de WorldFIP

Une redondance du contrôleur peut être mise en place afin de pallier sa défaillance.Un seul contrôleur pouvant contrôler le bus à un instant donné, une stratégie de reprisedevra alors exister.

Les réseaux utilisant une technique de polling (scrutation) sont WorldFIP, MVB etWTB du réseau TCN, PROFIBUS et BITBUS. La topologie utilisée pour les applicationsferroviaires embarquées est le bus dont les capacités de diffusion sont exploitées par lesprotocoles MAC.

3.2 Protocole des bus WorldFIP, MVB et WTB

3.2.1 Introduction

Les réseaux WorldFIP et TCN autorisent deux types de trafic sur le bus :

– un trafic périodique pour les variables nécessitant un rafraîchissement à intervallede temps déterminé ;

– un trafic apériodique (sporadique ou événementiel) pour les variables et messagesinitiés ponctuellement sur demande d’une entité esclave.

Pour que ces deux types de trafic soient possibles, le contrôleur du bus12 divisel’utilisation du bus en macro-cycles (WorldFIP) ou macro-périodes (TCN) (figure 12).Ces macro-cycles sont composés d’un ensemble de cycles élémentaires (WorldFIP) oupériodes de base (TCN) dont le nombre est fixé en fonction des besoins de l’applicationet en conformité avec les caractéristiques propre du protocole. Chaque cycle élémentaireou période de base est décomposé à son tour en deux phases, une première phase affectéeau trafic périodique, une seconde au trafic apériodique (ou sporadique).

Figure 12 : allocation du canal de communication par le contrôleur du bus



12 Le contrôleur de bus s’appelle « arbitre de bus » dans le protocole de WorldFIP,« administrateur de bus » dans celui de MVB et « contrôleur » dans celui de WTB.

La durée de chaque cycle élémentaire est identique. Elle est soit imposée par leprotocole, soit par les besoins de l’application en conformité avec les contraintes duprotocole (tableau 1). Cette durée correspond à la fréquence d’interrogation maximaled’une variable périodique.

Tableau 1 : durée d’un cycle élémentaire (ou période de base) des réseaux WorldFIP et TCN



Cycle élémentaireDébit ou période de base

WorldFIP ? > 2 ms

TCN MVB 1 Mbit/s 1, 2, 4 ou 8 ms (durée fixe programmable)

WTB 1,5 Mbit/s 25 ms ± 0,1 ms

Les durées des phases périodiques et apériodiques sont variables d’un cycle à l’autre.Celle de la phase périodique est déterminée par la durée des scrutations des variablespériodiques devant être rafraîchies lors du cycle considéré. Celle de la phase apériodiquel’est par la durée du cycle élémentaire restant disponible après la réalisation de la phasepériodique (figures 12 et 13).

Figure 13 : exemple WorldFIP d’allocation du médium

La liste des variables périodiques, dont les valeurs doivent être rafraîchies lors desphases périodiques d’un macro-cycle, est définie par le contrôleur à l’initialisation del’application. Cette liste définit la table de scrutation du contrôleur (figure 13). Elle estconstruite en fonction, d’une part, des périodes de rafraîchissement des informationsimposées par l’application et, d’autre part, de la durée des échanges nécessaires à laréalisation de ces rafraîchissements. Cette durée dépend du type de la variable échangée :entier sur 8 bits, 16 bits..., flottant, chaîne de caractère sur « n » bits... Etant donné leurscaractères événementiels, il n’existe pas de table de scrutation pour autoriser la

transmission des variables et messages apériodiques. Un autre mécanisme, propre àchacun des protocoles WorldFIP, MVB et TCN, est mis en œuvre pour la réalisation decet échange sous contrôle du maître.

La requête d’une entité pour une scrutation de variable ou d’un message apériodiquese fait dans le cas du protocole :

– WorldFIP

Lors de la phase périodique par indication par l’entité source de la variable scrutéeau moyen du champ de contrôle de la trame de réponse.

– WTB de TCN

Lors de la phase apériodique ou de la phase périodique. Lors des phasesapériodiques, le contrôleur maître scrute en séquence les nœuds à la recherched’une signalisation de messages en attente. Pour raccourcir cette recherche, unnœud esclave a la possibilité, lorsqu’il est scruté au cours de la phase périodique,de signaler dans le champ de contrôle de sa trame de réponse qu’il souhaite untransfert de données sporadiques. Le maître le scrutera alors de nouveau lors de laphase apériodique.

– MVB de TCN

Lors de la phase apériodique. Les bus MVB pouvant adresser jusqu’à4 096 équipements, la phase de scrutation des nœuds du protocole WTB estremplacée par une phase d’arbitrage exécutée sur un ensemble de phasesapériodiques (voir aussi le paragraphe 3.2.3.4 de ce chapitre). La recherche deséquipements à scruter se fait, dans un premier temps, par interrogation del’ensemble des entités. Cette interrogation collective peut engendrer des réponsessimultanées et provoquer ainsi des collisions destructives. Dans ce cas, unenouvelle interrogation est alors réalisée par l’administrateur de bus maître enréduisant de moitié le groupe destinataire (sous-groupe des stations paires parexemple). En cas de nouvelle collision, ce processus est réitéré jusqu’à obtentiond’une unique réponse...

3.2.2 Accès au bus WorldFIP

3.2.2.1 Méthode d’accès

Les phases périodiques et apériodiques d’un cycle élémentaire WorldFIP sontutilisées pour (figure 14) :

– le transfert de variables de contrôle temps critique (phase périodique etapériodique) qui permet de supporter le service MPS (Manufacturing Periodical/aperiodical Services) de la couche application,

– le transfert de messages non temps critique (phase apériodique) qui supporte leservice messagerie MMS (Messaging Services) de la couche application.

La configuration de la liste de scrutation de l’arbitre de bus se fait à l’initialisation, enfonction des caractéristiques des équipements connectés.



3.2.2.2 Format de la trame WorldFIP

Toutes les trames WorldFIP commencent, après un champ de début FSS, par unchamp de contrôle d’un octet qui permet aux abonnés de reconnaître la nature de la tramequ’ils reçoivent. Elles se terminent toutes par une séquence de contrôle d’intégrité de latrame (FCS de deux octets) suivie d’un délimiteur de fin de trame (figure 15).

Figure 15 : format de la trame WorldFIP



Figure 14 : allocation du médium du protocole WorldFIP

Plusieurs types de trames, construits sur le format de la figure 15, sont définis afin deréaliser les échanges de variables et de messages selon un trafic périodique etapériodique. Ces différentes trames sont résumées par le tableau 2.

La trame maître ID_DAT et sa trame de réponse RP_DAT en provenance de l’esclaveproducteur sont utilisées pour la scrutation des variables lors du trafic périodique etapériodique. Cet échange est initié par l’émission d’un identificateur, adresse logiqueinformant de la nature des données attendues, reconnue par le nœud producteur quitransmet les données et par les nœuds abonnés qui les consomment.



Tableau 2 : trames de requête-réponse définies par le protocole WorldFIP

Utilisation : Type de trafic (périodique / apériodique)

O Objet

Nom de la Trame de Requête ou précédente Nom de la Trame de Réponse

Objet

I Champ Information (contenu) Champ Information (contenu)

C Champ Contrôle (indication particulière) Champ Contrôle (indication particulière)

O Transmis à destination d’un producteur de lavariable « id »Requête : demande de données au producteurde « id »

Transmission des données en provenance de lacouche application par le producteur de « id »

Utilisation : Trafic périodique et apériodique

ID_DAT_id RP_DAT

I Identificateur sur 2 octets Les données attendues sur « n » octets, n F 128

C Peut indiquer s’il y a des requêtes de la sourcede l’identificateur pour un transfert de variableou de message apériodique, indique égalementla priorité (normale ou urgente) de cette requête

Utilisation : Trafic apériodique

ID_RQ_x RP_RQ

O Transmis à destination d’une station « x »ayant réalisé une requête pour un transfert devariableRequête : invite « x » à transmettre lesidentificateurs « id » des variables requises

Emission par « x » d’une liste d’identificateurs« id » de variables (de 1 à 64 identificateurs)

I Identificateur sur 2 octets

C

ID_MSG_x RP_MSG_NOACK ou RP_MSG_ACK

O Transmis à destination d’une station « x » ayantréalisé une requête pour un transfert de messageRequête : invite « x » à transmettre sonmessage à un destinataire identifié

Réponse sans demande d’acquittement(_NOACK) ou avec demande (_ACK)

I Adresses destinataire et source sur 3 octetschacunePuis message de longueur maximale de256 octets.

C Un bit du champ indique si le messagetransféré doit être acquitté ou non

RP_MSG_ACK RP_ACK

O Trame contenant un message à l’attention d’undestinataire identifiéRequête : demande d’un accusé de réception àce destinataire

Trame d’acquittement par le destinataire dumessage RP_MSG_ACK

I Vide

C Code l’acquittement

RP_ACK ou RP_MSG_NOACK RP_FIN

O Attente d’une fin de transaction Trame de fin de transaction de message émisepar l’émetteur du message, après réception del’acquittement si demandé.

I Vide

C Code la fin de transaction

Le champ de contrôle de la trame de réponse RP_DAT peut coder une demande del’esclave pour un trafic apériodique de variable ou d’un message. Dans le premier cas,une requête IR_RQ produite lors de la phase apériodique permettra de récupérer une listed’identificateurs à scruter. Dans le second cas, une trame ID_MSG permettra d’initier unéchange de message entre deux esclaves. La réponse à cette seconde interrogationRP_MSG_NOACK ou RP_MSG_ACK transmettra alors des informations de l’esclavesource à un esclave destination. Selon la nature de cette réponse (_NOACK ou ACK),l’esclave source n’attendra pas ou attendra un accusé de réception en retour de sonmessage. La transaction sera finalement close par l’esclave source au moyen d’une trameRP_FIN. Cet échange d’information point à point entre deux esclaves fait donc appel àdeux adresses physiques, celle du nœud qui est à la source du message et celle du nœuddestinataire.

3.2.3 Accès au réseau TCN

Le réseau TCN (Train Communication Network) est un système hiérarchique à deux niveaux d’interconnexions : l’interconnexion de véhicules à « un bus train » et, à l’intérieur des véhicules, l’interconnexion des équipements du véhicule à un ou plusieurs « bus véhicule ». Pour ces deux interconnexions, nous avons déjà vu que le réseau TCN spécifie deux bus, le bus train WTB (Wire Train Bus) et le bus véhicule MVB (Multifunction Vehicle Bus). Dans une architecture TCN, les protocoles de couches 1 et 2 de ces deux bus, mais également tout autre bus intégré à cettearchitecture, partagent les mêmes protocoles temps réel RTP (Real Time Protocols,couches 3 à 7). Ils doivent donc supporter les besoins en terme de services et deprotocoles des protocoles temps réel RTP (Real Time Protocols, couches 3 à 7), mais aussi du protocole de gestion de réseau TNM ou NM (TCN NetworkManagement) (figure 12 du chapitre 2). L’utilisation dans une communication TCN d’unréseau ne supportant pas les protocoles RTP nécessite alors une conversion de protocole[ROSIN_URLb]. Les services et protocoles nécessaires à une application pourcommuniquer avec d’autres applications sont, quant à eux, fournis par les protocoles RTP.

Le protocole TCN prévoyant de supporter l’interconnexion de réseaux non spécifiésdans son protocole, il serait dommage de parler des accès aux bus MVB et WTB sansévoquer l’accès au réseau TCN, bien que celui-ci fasse appel non seulement aux coucheshautes sur lesquelles sont définis les protocoles temps réel RTP, mais aussi au protocolede gestion du réseau TNM.

Le paragraphe suivant introduit donc les deux services de communication offerts par l’interface de la couche application de RTP aux applications utilisateur et gestionnaire du réseau TCN : le service « des variables » qui forment une base dedonnées distribuée temps réel, périodiquement rafraîchie par diffusion, et le service « des messages » qui sont transmis sur demande au moyen de messages multidestinataires ou de messages demande/réponse. Les données effectivement transmises sur le médium des bus MVB et WTB, l’allocation de ces bus, puis le format des tramesseront ensuite considérés.



3.2.3.1 Services « variable » et « messages » offerts à l’utilisateur ou au gestionnaire de réseau (couche 3 à 7)

Les équipements d’un train connectés à un réseau TCN produisent ou consomment desvariables. Ces variables sont maintenues à jour au sein de mémoires partagées(Traffic_Store) locales à chacun de ces équipements. Chaque mémoire Traffic_Storereprésente une copie partielle de la base de données globale produite par le système TCN.Au sein d’un même équipement, jusqu’à seize mémoires locales partagées peuvent co-exister, chacune étant structurée différemment. L’actualisation de leurs variables se fait par diffusion de leur valeur sur les bus véhicule et train. Les variables sont de petites tailles (1 ou 2 bits pour les valeurs binaires et 16 bits pour la plupart des valeurs analogiques). Elles sont regroupées dans une même trame de « données processus »ou de « données message » (Process_Data ou Message_Data). Elles sont transmises

– soit périodiquement, quel que soit l’état de leur valeur et à une période conforme àleur degré d’urgence (« variables processus »),

– soit sur demande après que leurs valeurs aient changé (« données messages »).

A cette fin, deux services sont offerts par l’interface de la couche application de RTPaux fonctions utilisateur et gestionnaire de réseau, le service « variable » lorsque latransmission doit être régulière et temps critique et le service « message » lorsqu’ellepeut être sporadique et pour une taille de données plus importante. Ces services sontmaintenant présentés.

a. Service « variable »

Le service « variable » sert à la transmission de données temps critique (ou« variables processus ») à travers le réseau TCN. Il repose sur la capacité des bus à diffuser des données identifiées par leur adresse source à tous les composants du réseau. Les « variables processus » sont transmises à des fins de surveillance, contrôle ou commande. Elles représentent l’état d’un processus physique, tel que celui de la valeur de la vitesse d’un axe, du courant moteur ou de la force de freinage[ROSIN_URLb].

Ces variables sont transmises lors des phases de transmission périodiques. A chaquephase périodique, le maître du bus considéré (MVB ou WTB) initie le rafraîchissementde variables processus en diffusant une trame maître comportant l’identificateur desdonnées processus attendues. En retour, l’équipement esclave éditeur (Publisher) desvariables identifiées diffuse la trame de données processus requise. Cette trame peutcomporter de 16 à 1 024 bits de données. Elle est récupérée par l’ensemble des abonnésà l’identificateur du réseau.

Le service « variable » ne dispose pas d’adressage de la couche réseau. Les variablesprocessus au sein d’un ensemble de données transmis sont identifiées dans le réseau TCNpar : l’identificateur de la mémoire partagée locale de l’équipement éditeur,l’identificateur de l’ensemble des données de cette mémoire et leur position(« Var_offset ») au sein de cet ensemble. Elles sont transférées d’un bus à l’autre via lesnœuds du bus train (WTB) qui réalisent chacun une passerelle filtrante (soit un pont)entre le bus train et les bus véhicule (figure 16).



La configuration de chaque passerelle est dépendante de l’application. Elle estréalisée par le programmeur de l’application à partir de la conception de deux listes devariables : l’une des variables à exporter du bus véhicule MVB au bus train WTB, l’autredes variables à importer du bus train au bus véhicule. La tâche application de la passerellefiltre les variables processus à transmettre cycliquement d’un bus à l’autre. Elle peutégalement traiter certaines d’entre elles pour ne transférer que le résultat (résultat de lavérification de la fermeture des portes du train par exemple) [ROSIN_URLb]. Ellerassemble enfin dans une même trame du bus train (trame WTB) les données processusen provenance d’un ensemble d’équipement d’un même bus véhicule.

Dans le cas d’un transfert apériodique de variables, les protocoles RTP utilisent unservice message sous la responsabilité de l’utilisateur.

b. Services « messages »

Les équipements capables de fournir les services « messages » sont appelés des« stations ».

Ces services « messages » servent à la transmission, sur demande d’une application àune autre application, de données de tailles importantes (telles que des informations dediagnostique) ou de messages courts à l’adresse d’un équipement spécifique (tels qu’unmessage d’ordre de fermeture d’une porte particulière). Les deux applicationscommunicantes peuvent être situées dans un même équipement, dans des équipementsdifférents, dans des véhicules différents. L’échange d’information sur les média se fait parl’intermédiaire d’un télégramme appelé « données messages » (Message_Data) qui estidentifié par son adresse destination.



Figure 16 : passerelle entre les bus WTB et MVB (nœud WTB) permettant le transfert de « variables processus »

Contrairement au service variable défini seulement sur la couche 7 de RTP, lesservices messages sont définis sur ses couches 3 à 7. Un nouveau schéma d’adressage estdonc défini pour le transfert de ces données messages (figure 17).

Figure 17 : trame de la couche liaison de données pour les services messages



Les télégrammes comportent deux types d’adresses correspondant à deux niveauxd’adressage différents : les adresses « équipement » et « réseau ». Les adresseséquipement sont les adresses « source » et « destinataire » spécifiques à la couche liaisonde données du bus utilisé. Elles identifient les équipements communicants « source » et« puits » au sein d’un même bus. Les adresses « réseau » sont les adresses « origine » et« finale » spécifiques à la couche réseau de RTP. Elles identifient les entitéscommunicantes au sein du réseau TCN, soit le « producteur » et le(s)« consommateur(s) ».

Le service message (Message_Data) offert par la couche liaison de données pourl’échange de données ou d’informations de contrôle est utilisé par les applications« processus utilisateur » (User Processus) et « processus application »(Application_Processus) présentées maintenant.

– Les « processus utilisateur » exécutent des « fonctions » correspondant aux tâchescourantes d’un système de contrôle (telles que les tâches de contrôle des portes, del’air conditionné, des freins...).

Ces fonctions sont réalisées par des équipements connectés à un bus véhicule oudirectement à un nœud du bus train, chaque véhicule du train supportant un certainnombre de fonctions de l’application. Elles peuvent être celles spécifiées dans« UIC 556 leaflet » et supportées par tous les trains conformes à l’UIC. Dans unsystème fermé (par exemple le métro), ces « fonctions » sont définies par legestionnaire et l’opérateur du système.

Pour les applications utilisateur, le réseau est perçu comme un ensemble de nœudssupportant chacun un ensemble de « fonctions » (figure 18). Les applications nespécifient pas, normalement, la station devant exécuter une « fonction ». L’accès àla fonction se fait par son « adresse utilisateur ». Cette adresse est uneconcaténation d’une adresse nœud, d’un identificateur de fonction etéventuellement d’un identificateur de la station voisine (figure 20).

Figure 18 : vue du réseau par une « application utilisateur » [ROSIN_URLb]



– Les « processus application » sont dédiés au gestionnaire de réseau. Ils font appelà des « agents » (Agents) et à un « gestionnaire » (Manager). Un agent exécutelocalement des « fonctions » de gestion. Il en existe un par station. Le« gestionnaire », uniquement présent dans la station de gestion du réseau(Management Station), initie les requêtes devant être exécutées par l’agent de sastation ou d’une autre station.

La perception du réseau par le gestionnaire de TCN est celle d’un ensemble destations attachées aux nœuds WTB (figure 19). Chaque station est reconnue par sonidentificateur de station. Il peut y en avoir jusqu’à 254. Le gestionnaire du réseaudonne ainsi accès aux équipements lors de la mise en service du système ou de sondéboggage.

Figure 19 : vue du réseau par une « application système » [ROSIN_URLb]

Le gestionnaire du réseau identifie un « agent » à l’adresse de son nœud et àl’identificateur de sa station. Il peut accéder simultanément à plusieurs stations dedifférents nœuds en utilisant une adresse de groupe à la place d’une adresse denœud (figure 20). Les stations sont accessibles par leur « adresse système »composée de l’adresse du nœud de la station ou d’une adresse de groupe (cas d’unaccès simultané à plusieurs stations par une diffusion), de l’identificateur de la

station et, éventuellement, de l’identificateur de la station voisine (si laspécification d’une station routeur ou encore l’accès à un équipement spécifique estnécessaire). Le gestionnaire du réseau accède ainsi aux équipements parl’identificateur de leur station plutôt que par leur adresse équipement. Pour que sonschéma d’adressage puisse être indépendant des bus du train, un répertoire desstations effectue une correspondance entre l’identificateur des stations (adressagesystème) et l’adresse des équipements (adressage de la couche liaison de données).

Figure 20 : adresses utilisateur et système (adressage de la couche réseau) [ROSIN_URLb]



Trois familles de messages permettent les différents types de communications surdemande. Ce sont les « messages système », les « messages utilisateur » et les « messagesgestion ». Les « messages système », identifiés par leur « adresse système », servent auxéchanges entre le gestionnaire et les agents à des fins de gestion du réseau. Les « messagesutilisateur », identifiés par leur « adresse utilisateur », sont échangés entre des applicationsutilisateurs. Enfin, les « messages gestion », identifiés par une « adresse système » ou une« adresse utilisateur », sont envoyés à un agent à des fins de gestion du réseau.

Lors d’une demande de transfert d’une application à une autre, un protocole decommunication entre les stations distantes « source » et « destinataire » du message estexécuté au sein de chacune de ces stations par un « messager » (Messager). Ce protocoleest maintenant expliqué [ROSIN_URLb].

– Le messager reçoit de l’interface de sa couche application un « message d’appel ».

– Sa couche session ouvre une connexion (qu’il fermera par la suite).

Lorsque les deux applications distantes résident dans une même station, la couchesession court-circuite le réseau et évite la segmentation en paquet : il n’y a alors pasd’accès aux couches basses du réseau et donc aux média.

– Sa couche transport divise le message en paquets de taille convenant aux trames dedonnées qui les transporteront. Elle les transmet ensuite à la couche réseau.

Le protocole de transfert du message entre la couche transport d’un producteur etcelle d’un consommateur réalise un contrôle des flux de bout en bout et unrecouvrement d’erreur pour éviter une perte ou une duplication de paquets.

– Sa couche réseau consulte ses répertoires « fonction » et « station » afin de traduireles adresses des paquets et faire suivre ces derniers à la couche liaison.

Les nœuds du bus train agissent comme des routeurs pour les services messages(figure 21). TCN transmet les paquets (données, acquittement ou trames decontrôle du message) de bus en bus sans connexion préalable. Les paquets routéspar la couche réseau sont transférés à la couche liaison de données dans des trames.

Figure 21 : passerelle entre les bus WTB et MVB (nœud WTB) permettant le transfert de « messages » d’après [ROSIN_URLb]



– Sa couche liaison de données assure la transmission des trames entre deséquipements situés sur un même bus. Cette couche est spécifique au réseau utilisé(WTB, MVB,...). Mais son interface avec la couche réseau doit être la même pourchacun des bus utilisés par TCN.

La couche liaison est sans connexion, toutes les trames « Données Message »contenant l’adresse complète nécessaire à la transmission de bout en bout. Elle negère pas le flux de données et ne reconnaît pas les trames perdues. Elle reçoit justeles trames sur la base de leur adresse destination et les place dans une file d’attente.

Son entête de contrôle des données comporte les adresses source et destinationd’équipements situés sur un même bus. Par conséquent, lorsqu’un message estenvoyé à destination d’un autre bus, l’adresse destination est celle du nœud derattachement au bus train. Inversement, lorsqu’un nœud du bus train reçoit unmessage à transmettre en provenance d’un autre véhicule, il insère son adresseéquipement en tant qu’adresse source de la trame. Une adresse de diffusion peutêtre utilisée en tant qu’adresse destination.

– A la réception complète du message, le messager local à la station destinatairedistante en informe l’application concernée qui émet alors un « message deréponse » dans la direction opposée.

Dans ce paragraphe 3.2.3.1, les deux services « variable » et « message » offerts auxapplications utilisateur et gestionnaire de réseau par l’interface application des protocolestemps réel RTP ont donc été présentés. Le service « variable » utilise les propriétés dediffusion périodique des bus train et véhicule et de filtrage des nœuds du bus train pourla transmission de données temps critique à travers le réseau TCN. Les services« messages » exploitent les propriétés de transmission apériodique des bus train etvéhicule et de routage des nœuds du bus train pour l’échange, sur demande d’uneapplication à une autre application, de données de tailles importantes ou de messagescourts à l’adresse d’un équipement spécifique. Afin de pouvoir supporter ces deuxservices, nous expliquons ci-après les services offerts par l’interface de la couche liaisonde données des protocoles MVB et WTB au protocole RTP et NM.

3.2.3.2 Données transmises et allocation des média des bus MVB et WTB (couche 2)

Afin que les protocoles RTP puissent fournir les services « variable » et « messages »précédemment présentés, les deux bus MVB et WTB supportent d’une part unetransmission de données périodique et apériodique et offre d’autre part aux protocolesRTP et NM les services de transmission pour les « données processus » (Process_Data –utilisé par RTP et NM), les « données message » (Message_Data – utilisé par RTP) et les« données de supervision » (Supervisory_Data – utilisé par NM) (figure 22).

Figure 22 : couche liaison de données de TCN d’après [TCNspecifications1998]



Ces données sont :

– données processus (Process_Data)

Ce sont des données périodiques identifiées par une adresse logique. Elles sontproduites par un équipement écrivain (Publisher) et consommées par un certainnombre d’équipements abonnés (Subscriber). Pour chacune des données processuspouvant être reçues ou émises par un équipement, l’équipement dispose d’unemémoire tampon appelée « port », configurée soit en entrée (s’il en est abonné) soiten sortie (s’il en est l’écrivain). Une trame de données processus (Process_Data)contient les variables éditées par un port source.

Les ports sont définis différemment pour les équipements des bus véhicule MVBet les nœuds du bus train WTB. Un équipement d’un bus MVB peut contenirjusqu’à 256 ports configurés ou en source ou en puits. Le nombre maximal de portssur l’ensemble des équipements d’un bus véhicule est de 4 095. Chaque nœud dubus train WTB possède, d’une part, un unique port source gérant l’ensemble desvariables processus éditées par le nœud et, d’autre part, un unique port puits pourla réception des trames de données processus des équipements du bus. La trame dedonnées processus d’un nœud WTB et chacun de ses deux ports peuvent contenirjusqu’à 128 octets.

Les données processus transportent l’ensemble des données utilisées par leprotocole RTP pour fournir le service Process_Variable à l’interface application.

– données message (Message_Data)

Ce sont des données transmises sur demande et émises par un équipement source àl’adresse d’un équipement destinataire. Pour recevoir ou transmettre ces données,les équipements doivent disposer, en plus des ports configurés en entrée ou ensortie, de deux files d’attentes, l’une pour les messages en réception, l’autre pourles messages en émission.

Ces données message transportent l’ensemble des paquets utilisés par le protocoleRTP pour fournir le service Message à l’interface application.

– données de supervision (Supervisory_Data)

Ce sont des données transmises périodiquement ou sur demande. Elles sontutilisées à des fins de supervision des équipements interconnectés à un même bus.Elles permettent par exemple la surveillance de l’état des équipements, la détectiondes équipements silencieux, le transfert du rôle du maître d’un équipement à unautre, l’inauguration13 du bus train (WTB)...

A ces trois services de transmission correspondent trois types de télégrammes qui sedistinguent les uns des autres par le codage du champ de contrôle de leur trame maître(champ LC dans le cas du protocole WTB et F_code dans celui de MVB) (tableau 3, voirégalement les tableaux 4 et 5 des paragraphes 3.2.3.3 et 3.2.3.4 suivants).



13 Le terme inauguration se rapporte à l’ensemble des opérations d’initialisation du bus trainaux cours desquelles est notamment nommé le maître du bus, sont numérotés les nœudsesclaves du bus train, construites la liste de scrutation... (voir le paragraphe 3.2.3.3 de cechapitre).

De la même façon que dans le protocole WorldFIP, les maîtres des bus MVB et WTBdivisent l’activité du bus en une phase périodique et apériodique.

La phase périodique permet le transfert de données processus et de données desupervision à une période de durée constante multiple de la période de base du bus considéré (période de 25 ms dans le cas du bus WTB et de 1, 2, 4 ou 8 ms dans le casdu bus MVB (figure 23). Les données périodiques à scruter à chaque période de base sontdéfinies dans la liste de scrutation du maître du bus. La configuration de cette liste se fait :

– de façon dynamique, dans le cas du protocole WTB uniquement, à chaquechangement dans la composition du bus WTB ou du train (couplage, découplage).Pour cela, chaque nœud annonce, lors de la phase sporadique, la période à laquelleil doit être scruté. La phase périodique augmente alors, respectivement diminue,avec le nombre de véhicules, tandis qu’inversement la phase sporadique diminue,respectivement augmente, ce qui rend les délais de délivrances des donnéesprocessus indépendants du nombre de nœuds.

– à l’initialisation, en fonction des besoins des applications programmées (protocolesWTB et MVB).

La phase apériodique permet le transfert de données message et également de donnéesde supervision. Cette seconde phase est subdivisée en trois phases (figure 23) :

– les phases « Supervision », « Evénement » et « de garde » pour le protocole MVB ;

– les phases « Supervision », « Message » et « de garde » pour le protocole WTB.

Les phases de garde sont des phases « tampon » qui permettent de garantir une duréeconstante pour chaque période de base.



Télégramme Process_Data (« Données_Processus »)

Tableau 3 : définition des télégrammes des bus de TCN

Données diffusées périodiquement identifiées par une adresse source en relation avec latransmission d’une variable processus exprimant l’état d’un processus (cf. vitesse,...)

Télégramme Message_Data (« Données_Messages »)

Données transmises sur demande d’un esclave entre une entité source et une entité destinataire

Télégrammes Supervisory_Data (« Données_Supervision »)

Données transmises sur un bus pour des besoins de supervision Echange de données notamment dans le cas :

bus train WTB bus véhicule MVB• d’une inauguration du bus (suite à unchangement de configuration) ;

• d’une résolution d’événement (suite à unecollision provoquée par une réponse simultanéeà une requête du maître) ;• d’un changement de maître) ;• d’une transmission de l’état d’un appareil.

Après cette présentation générale du réseau TCN, nous nous intéressons dans lesparagraphes qui suivent à quelques particularités des protocoles WTB et MVB et auformat de leurs trames de communication. Dans le cas du protocole WTB, nousprésentons la procédure d’« inauguration » qui répond, pour le bus train, à un besoinspécifique de l’application ferroviaire embarquée. Dans le cas du protocole MVB, nousprésentons la gestion des événements et la procédure de changement de maître.

3.2.3.3 Particularité du protocole WTB

Les nœuds WTB jouent le rôle de passerelle pour les « variables processus » entre lebus train et les bus véhicule. Ils jouent également celui de routeur pour les messages duservice « messages » des protocoles RTP. Contrairement aux bus véhicule dont le nombred’équipements connectés est prévu lors de la conception, le bus train est un bus« ouvert ». Le nombre de nœuds connecté peut évoluer en cours d’exploitation,notamment en cours de couplage de trains (ajout de nœuds) ou de découplage(suppression de nœuds). Ces deux actions ont pour conséquence un changement deconfiguration du bus train qui nécessite en particulier de redéfinir dynamiquement lecontrôleur maître du bus et sa table de scrutation pour la réalisation de la phasepériodique... Ainsi, suite à un changement de configuration du bus train provoqué par unedéfaillance ou une modification d’exploitation du train, une phase d’initialisation appelée« inauguration » est nécessaire.

Les paragraphes suivants présentent la phase d’inauguration, la phase périodique et laphase sporadique. Le format des trames WTB est ensuite indiqué.



Figure 23 : allocation du médium des bus véhicule MVB et train WTB par leur maître respectif

a. Inauguration du bus train

Au cours de la procédure d’inauguration du bus train, les opérations suivantes sontréalisées :

– les nœuds connectent électriquement leurs sections de câbles pour ne former qu’unseul segment avec une terminaison de ligne à chaque extrémité,

– chaque nœud reçoit une adresse unique qui identifie sa position et son orientationrelativement à celle du nœud maître (figure 24) et informe ce dernier de la périodede scrutation individuelle qu’il désire avoir,

– chaque nœud reçoit un descripteur, appelé topographie, qui lui indique l’adresse, laposition et le descripteur des autres nœuds. Chaque descripteur de nœud indique, lataille de la trame émise par le nœud, la période individuelle choisie pour le nœud(période de 2n x T_Bp, où T_Bp est la période de base et « n » est compris entre 0 et7) et enfin le type et la version du nœud. Ces deux dernières informations caractérisentle format de la réponse du nœud à une requête de données processus. Un descripteurest défini en accord avec l’équipementier et l’utilisateur pour une application donnée.Le format de ceux-ci pour les nœuds UIC est défini dans la fiche « UIC 556 ».

Pour la réalisation de cette procédure d’inauguration, deux types de nœuds sontconsidérés, le « nœud fort » qui est désigné par l’application pour devenir le maître du bus(celui où est insérée la clef du conducteur) et les « nœuds faibles » dont l’un est susceptiblede devenir un nœud fort maître du bus suite à un changement d’exploitation du train(changement du lieu d’insertion de la clef du conducteur suite à un changement dedirection par exemple) ou de devenir un maître faible en cas de défaillance du nœud fort.

Une des premières opérations réalisées est l’attribution des adresses des nœuds.Indépendamment de la direction de voyage du train, le nœud maître du bus nomme lesnœuds en fonction de leur position relative. Pour cela il définit arbitrairement une« direction 1 » et une « direction 2 » de part et d’autre de son nœud qu’il définit commeétant à l’adresse 01 (figure 24). Il numérote alors séquentiellement et par décrémentationd’adresse les nœuds se trouvant dans sa « direction 1 » en commençant par l’adresse 63.Les nœuds se trouvant dans « sa direction 2 » sont par contre nommés séquentiellementet par incrémentation d’adresse en commençant par l’adresse 02. Les deux nœudsterminant le bus train (l’un en tête et l’autre en queue de train, soit en début et fin deréseau – figure 25 du chapitre 3) sont respectivement identifiés comme « nœud du bas »dans la « direction 1 » et « nœud du haut » dans la « direction 2 ».

Figure 24 : numérotation des nœuds WTB



Chaque nœud connaît son adresse et sa position relative au maître selon la « direction1 » ou la « direction 2 » en fonction de la façon dont il a été nommé (façon ascendante oudescendante). Il sait s’il est en « haut » ou en « bas » du maître. Chaque nœud reconnaîtégalement son propre sens « haut » et « bas » relativement aux autres nœuds et sait ainsisi son véhicule a la même orientation ou l’orientation opposée à celle du véhicule oùréside le maître (position de son côté A et B par rapport à celui du maître). Il a égalementconnaissance de la topographie du train indiquant l’adresse, la position et le type de tousles nœuds. La connaissance de l’orientation des nœuds, permet par exemple à ceux-ci,lorsque le nœud maître demande la fermeture des portes sur son côté A, de fermer leursportes A lorsqu’ils ont la même orientation que le maître ou leurs portes B lorsque leurorientation est à l’opposée. Ceci se fait sans avoir connaissance de la direction du voyage,les positions A et B du nœud maître étant relatives aux directions 1 et 2.

La configuration d’un nœud nécessite l’usage de quatre télégrammes de supervision(Status, Detect, SetInt, Naming) qui prennent chacun environ 250 µs. D’autre part, laconnexion électrique des sections de câbles des nœuds au cours de cette procédurenécessite un temps d’attente de 10 ms au cours duquel le bus est indisponible. Un seulnœud peut donc être configuré à chaque période de base de 25 ms, ce qui signifie unedurée de 800 ms pour nommer 32 nœuds [ROSIN_URLb].

Au cours de cette procédure d’inauguration, les cas de conflits suivants sont pris encompte et résolus par le protocole WTB par une gestion locale de temporisateur et unenotion de force (Strength) associée à chaque nœud :

– conflit dû à la présence de deux nœuds forts : ce cas est possible, lors du couplagede deux trains, lorsque les conducteurs des deux trains ont leur clef insérée,

– conflit entre deux nœuds faibles qui deviennent maître en même temps[ROSIN_URLb ; TCNspecifications 1998].

b. Phase périodique

Pour terminer la phase d’inauguration, le maître calcule la nouvelle liste périodique(de scrutation) et les périodes individuelles de chaque nœud à partir des périodes désiréeset de la taille des trames des nœuds. La période individuelle annoncée la plus longue vadéfinir la macro-période. Pour chaque période de base, le temps non utilisé par lascrutation de la liste périodique est disponible pour la phase sporadique. Ce temps doitêtre au moins de 40 % celui de la période de base. Si ce n’est pas le cas, le maîtredoublera la période la plus longue, si ce n’est pas encore suffisant la seconde période laplus longue et ainsi de suite jusqu’à ce que 40 % du temps des périodes de base reste libreen moyenne sur la macro-période. Le maître construit alors la topographie. Latopographie est une structure de données contenant pour chaque nœud son adresse, sontype et sa version, une « topographie maître » identifiant de façon unique l’inaugurationdu maître. La période individuelle alors optée pour chacun des nœuds leur est alorscommuniquée au moyen de requêtes « topographie ».

Pendant la phase périodique au cours de laquelle la liste de scrutation est exécutée, undes deux nœuds de fin de bus (figure 25 du chapitre 3) est également alternativementscruté par le maître à chaque période de base. Cette scrutation est réalisée par l’envoi



d’une trame de requête de présence dont la réponse est diffusée, permettant ainsi àl’ensemble des nœuds WTB de surveiller l’intégrité du bus et au maître de détecter laprésence d’un changement dans la composition du train.

Enfin, un nœud défaillant qui ne répond pas à la scrutation de son nœud ne sera pasretiré de la liste périodique. Seule une nouvelle inauguration permettra de ne pas leprendre en compte. Un nœud, qui serait l’abonné d’un nœud défaillant, doit être capablede signaler sa disparition à son application, passé un délai de trois scrutations, voire saré-apparition en cas de son recouvrement.

c. Phase apériodique

Lors des phases apériodiques, le contrôleur maître scrute en séquence les nœuds à larecherche d’une signalisation de messages en attente. Pour raccourcir cette recherche, unnœud esclave a la possibilité, lors de sa scrutation périodique, d’effectuer cettesignalisation par l’intermédiaire de sa trame de réponse.

L’annonce d’un événement par un nœud se fait au cours des phases périodiques ouapériodiques par le positionnement des éléments binaires A et C du champ de contrôleLC de la trame de réponse à un télégramme de « données processus » ou de « donnéesmessage ». Le bit A est positionné pour une requête de « données message » et le bit Cpour une requête de « données supervision » (voir le champ LC de la trame WTB donnéen tableau 4). Les nœuds ayant fait une telle demande ont leur adresse mise dans la filed’attente des requêtes « message données » (si bit A) ou « message supervision » (si bitC). Ils en sont retirés dès réception par le maître de la réponse à la requête adéquate(« données message » ou « requête status »).

d. Format de la trame WTB

Les échanges sur le bus WTB, à l’image de ceux sur le bus MVB, se font parl’intermédiaire de télégrammes selon un protocole d’échange mono-maître multi-esclaves (ou maître-esclaves). Un télégramme est l’ensemble constitué d’une trame derequête maître à un esclave et de la trame de réponse de l’esclave adressé. Le formatd’une trame WTB est donné à la figure 25.

Figure 25 : format de la trame WTB du réseau TCN



Le type de requête du maître et, par conséquent, la nature de la réponse attendue enprovenance d’un esclave sont identifiés par le contenu du champ de huit bitsLink_Control (LC) de la trame maître. Parmi ces huit bits, le bit de poids fort « M » sertà distinguer une trame maître d’une trame esclave. Trois autres bits A, C et I (ou RI) dece champ de contrôle LC permettent à un esclave de signaler au maître un événementlorsque celui-ci est scruté au moyen d’une trame Process_Data ou Message_Data. Lesévénements signalés sont :

– Bit A (Attention), la transmission d’un message (Message_Data) est requise ;

– Bit C (Changement), l’état du nœud a changé, une requête status est requise ;

– Bit I ou RI (Inhibition), l’inauguration n’est pas permise.

Comme le protocole MVB, le protocole WTB spécifie trois types de télégrammes(tableau 4). Par exemple, un ensemble de télégrammes pour l’échange de données desupervision (Supervisory_Data) permet la détection d’un changement de composition dutrain et l’inauguration du bus. Plus d’informations sur les trames citées dans le tableau 4pourront être trouvées dans [TCNspecifications 1998].

Tableau 4 : définition des télégrammes du bus WTB



Télégramme Process_Data (« Données_Processus ») LC : M 0 ACI 000

Requête Process_Data (M = 1)/Réponse Process_Data (M = 0)

Télégramme Message_Data (« Données_Messages ») LC : M 0 ACI 111

Requête Message_Data (M = 1)/Réponse Message_Data (M = 0)

Télégrammes Supervisory_Data (« Données_Supervision ») LC : M 1 0 0/RI 0/I xxx

Selon lecodagede xxx :

Requête Detect (M = 1) / Réponse Detect (M = 0) Requête Status (M = 1) / Réponse Status (M = 0) Requête SetInt (M = 1) / Réponse SetInt (M = 0) Requête SetEnd (M = 1) / Réponse SetEnd (M = 0) Requête Unname (M = 1) / Réponse Unname (M = 0) Requête Naming (M = 1) / Réponse Naming (M = 0) Requête Topography (M = 1) / Réponse Topography (M = 0) Requête Presence (M = 1) / Réponse Presence (M = 0)

(la formulation « 0/RI » signifie état 0 ou RI, le bit RI n’est utilisé que dans deux des 8 télégrammesde supervision, le bit I dans l’un de ces deux.)

3.2.3.4 Particularité de MVB

Le bus MVB interconnecte des équipements du véhicule entre eux. Il est relié au bustrain WTB par un nœud WTB jouant le rôle de passerelle. Une particularité du bus MVBréside dans sa façon de gérer les événements sur son bus. Le protocole d’échange mis enjeu se rapproche alors du protocole CSMA/CRCD (variante déterministe du protocole detype contention CSMA/CD). Une seconde particularité du protocole est sa gestion duchangement de maître qui fait cette fois appel à un protocole de jeton sur anneau logique.Ce sont ces deux aspects particuliers de la phase apériodique que nous expliquonsmaintenant.

a. Résolution d’événements (phase apériodique)

Entre deux phases périodiques, le nœud maître traite les événements en attente (unévénement étant une demande par un équipement d’une scrutation spécifique). Ceprocessus qui comporte la recherche d’événements et leurs traitements va durer surplusieurs phases apériodiques (il ne fait pas intervenir la phase périodique des périodesde base).

Il peut exister jusqu’à 4 096 ports à scruter sur un bus MVB. En l’absence de touteconnaissance des ports en attente d’une scrutation spécifique, la station maître vaprocéder par interrogation successive à l’adresse de groupe de ports. Le début d’un « tourde scrutation des événements » (Event_Round) débute ainsi par une trame de requêted’événements à l’adresse de tous les équipements (trame General_Event_Request).Cette trame invite les nœuds à lui rapporter les événements en attente. Lorsque plusieurs équipements répondent à cette interrogation, une collision destructive seproduit. La procédure d’arbitrage consiste alors en une recherche dichotomique : lemaître restreint alors de moitié le groupe précédemment interrogé en jouant sur la parité des adresses, il adresse ainsi successivement des groupes toujours plus réduitsjusqu’à l’obtention d’une réponse individuelle. La trame Group_Event_Request derequête d’événements sert à cette adressage de groupe d’équipements (figures 26 et 27).Une priorité basse ou haute pouvant être affectée aux messages de données par les équipements, le maître peut être configuré pour n’interroger que les événements d’uneou l’autre des priorités.

A la réception d’une réponse individuelle contenant une adresse à scruter, le maîtreinterroge cette adresse par l’intermédiaire d’une requête de lecture d’évenement (trameEvent_Read_Request). L’esclave adressé lui répond alors par une trameEvent_Read_Response contenant une information consommée par les équipements enattente de cette donnée. Ces équipements suppriment alors de leur liste d’événements enattente ce dernier événement. La station maître repart ensuite à la recherche d’autresréponses individuelles en diffusant une nouvelle requête Group_Event_Request àl’adresse d’un autre groupe...

Lorsque l’ensemble des événements en attente a apparemment été traité, afin de clorele tour actuel de scrutation des événements Event_Round et pour prévenir desperturbations ayant pu avoir lieu sur le bus, le maître renvoie une trameGeneral_Event_Request qui n’autorise pas la signalisation des nouveaux événements.Elle permet par contre aux équipements qui auraient des anciens événements non encorescrutés de les signaler. Si aucun équipement ne répond, le maître commence un nouveautour de recherche d’événement Event_Round. Il lit alors l’événement en cas d’une uniqueréponse ou débute une phase d’arbitrage en cas de collisions. Les figures 26 et 27illustrent cet algorithme de recherche d’événements.





Figure 26 : protocole d’accès au médium du protocole MVB réparti sur plusieurs phases apériodiques



Figure 27 : protocole MVB – Recherche d’événements (algorithme réparti sur plusieurs phases apériodiques)

b. Changement d’administrateur de bus maître (phase apériodique)

La fonction de maître peut être assurée par deux ou plus administrateurs du bus MVB, un seul administrateur ayant cette fonction à un instant donné et pour la durée d’un tour. La durée d’un tour est un multiple de 1 024 ms et ne doit pas excéder 256 x 1 024 ms. Ceci permet notamment un transfert de la fonction de maître en cas de défaillance. A cet effet, les administrateurs de bus sont organisés selon unanneau logique. Un algorithme de passage du jeton assure qu’il n’existe qu’un uniquemaître à un instant donné (figure 28).

Figure 28 : redondance de l’administrateur du bus MVB



Deux types de nœuds maîtres sont distingués : les maîtres en attente(Standby_Master) et le maître régulier (Regular_Master). Le maître régulier est l’arbitre de bus possédant le jeton et par conséquent la maîtrise des échanges sur le bus. Chaque administrateur de bus maintient une liste circulaire de tous lesadministrateurs. Cette liste des arbitres de bus ordonnance la circulation du jeton. Elle ordonne de préférence les adresses des équipements selon l’ordre ascendant. Outre cette liste, les administrateurs de bus possèdent également la même liste descrutation périodique. Un administrateur maître en attente deviendra le maître du bus régulier après acceptation du jeton qui lui est transféré en fin de tour du maîtrecourant. Le transfert effectif de la fonction de maître se fait par l’intermédiaire dutélégramme Mastership_Transfer. Un administrateur maître en attente peut égalementdevenir l’administrateur maître suite à une défaillance du précédent maître. Cettedéfaillance est détectée par un trop long silence sur le médium. De façon à éviter lescollisions entre maîtres en attente essayant de prendre la fonction de maître suite à la misesous tension ou la perte du maître courant, les temporisations (time-out) de chacun desmaîtres potentiels sont échelonnées de façon à assurer que seulement un desadministrateurs du bus devienne le maître.

c. Format de la trame MVB

Un télégramme MVB est constitué d’une trame de requête du maître et d’une tramede réponse de l’esclave destinataire (figure 29). Trois types de télégrammes, décrit autableau 3, ont été définis pour permettre l’échange d’informations périodiques etapériodiques. A ces télégrammes correspondent différentes requêtes émises par l’entitéadministrateur du bus maître. Une requête émise à l’adresse d’une ou plusieurs entités estidentifiée par le code F_code de la trame maître. A chacune d’elles correspond une tramede réponse spécifique en provenance d’une ou plusieurs entités esclaves. Ces requêtessont décrites au tableau 5.



Tableau 5 : description des requêtes de l’administrateur maître du bus MVBd’après [ROSIN_URLb]

Télégramme Process_Data (« Données_Processus »)Trafic Périodique

F_code : 0 à 7

Requête Process_Data (« Données_Processus ») utilisée pour une demande de données de 16,32, 64, 128 ou 256 bits à une entité esclave

Télégramme Message_Data (« Données_Messages »)Trafic Apériodique, phase Message

F_code : 12

RequêteMessage_Data

(« Données_Message ») utilisée pour donner la possibilité à une entitéesclave d’en adresser une autre

Télégramme Supervisory_Data (« Données_Supervision »)Trafic Apériodique, phase Supervision et Evénement

F_code : 8, 9, 13, 14 et 15

Transfert de la fonction maître d’un administrateur de bus à un autre (Phase supervision)

RequêteMastership_Transfer

(« Transfert_Maître ») utilisée pour une demande de transfert de lafonction maître à un autre administrateur de bus

Recherche d’événements (Phase Evénement)

RequêteGeneral_Event

(« Evénement_Général ») utilisée lors d’une recherche des nœuds ayantdes données apériodiques à transférer (soit lors d’une « recherched’événements »). Cette requête, diffusée à l’ensemble des nœuds du busest cause d’une collision nécessitant une « résolution d’événements »lorsque plusieurs nœuds signalent des données apériodiques en attente.

Requête Group_Event utilisée par le mécanisme de résolution d’événements suite à unecollision, causée par l’utilisation d’une précédente requêteGeneral_Event ou Group_Event, lors d’une recherche des nœuds ayantdes données apériodiques à transférer. Elle est à destination d’un sous-ensemble du groupe de nœuds adressé par la précédente requête.

Requête Single_Event utilisée lors de l’adressage d’une unique entité esclave.

Requête Status Demande d’état



3.3 Protocole du réseau PROFIBUS

3.3.1 Méthode d’accès

Le protocole PROFIBUS utilise un « accès au médium contrôlé réalisé par uneméthode d’accès au médium décentralisé selon le principe du passage de jeton ». Cetteméthode est elle même « à la base d’une méthode d’accès centralisée selon le principed’un protocole maître-esclave ». Ce protocole est basé sur la définition d’une stationactive et de stations passives. Les stations passives sont les stations esclaves qui nepeuvent transmettre que sur requête d’une station active. La station active est la stationqui, parmi les stations maîtres du bus, possède le jeton. Elle gère par scrutation les accèsau médium d’un ensemble de stations passives durant l’intervalle de temps défini depossession du jeton. Le jeton est transmis sur le bus de station maître en station maîtreselon le parcours d’un anneau logique (figure 30).

Figure 30 : mode de transmission cyclique du bus PROFIBUS

Figure 29 : format des trames maîtres et esclaves du bus MVB

L’échange de messages entre une station active et un ensemble de stations passivesprend place à l’intérieur de cycles. Un cycle message est un ensemble constitué d’unetrame d’« action » en provenance d’une station maître (trame de requête – Request – oud’envoi accompagné d’une requête spécifique – Send/Request) et de la trame

d’acquittement ou de réponse d’une station maître ou esclave (figure 31). Les tramesd’action et de réponses peuvent contenir des données utilisateur. La trame d’acquittementn’en contient pas. En cas de non-réponse à une interrogation, un cycle message comprendégalement des « ré-essais ».

Figure 31 : définition d’un cycle message PROFIBUS



Ce cycle message n’est pas respecté dans deux cas de figure, celui de la transmissionde jeton d’une station maître à une autre et celui de la diffusion de données à l’ensembledes stations esclaves d’une station maître. Dans ces deux cas, il n’y a ni tramed’acquittement, ni trame de réponse.

Toutes les stations hormis l’initiateur (la station active) doivent gérer les requêtesqu’elles reçoivent. Cependant, seules les stations « nominativement » adressées émettent,après réception d’une trame d’action, un acquittement ou une réponse devant parvenir aumaître dans un intervalle de temps prédéfini. En cas de non-respect de cet intervalle,l’initiateur répétera sa requête après l’expiration d’une période d’attente. En cas de non-réponse après un nombre défini de tentatives, la station incriminée sera reconnue comme« non-opérationnelle ».

L’utilisateur de l’interface FDL (couche application) peut choisir entre une priorité basse ou haute pour les cycles messages. La priorité est transmise à la couche FDL par l’intermédiaire du service requête. Quand une station maître reçoit le jeton, il réalise toujours tous les cycles messages de priorité haute d’abord et ceux de priorité basse ensuite. Lorsqu’un cycle message de priorité basse ou haute a débuté, il est toujours entièrement réalisé, avec une ré-itération de l’interrogation en cas de non-réponse de la station scrutée, même si le temps imparti pour la possession du jeton a été atteint. Si ce temps est dépassé, le temps imparti pour latransmission des cycles messages à la prochaine réception du jeton est raccourci enconséquence.

La séquence temporelle des cycles messages est définie par les modes d’opération detransmission pour lesquels quatre types sont distingués :

– la gestion du passage de jeton ;

– l’« opération Request ou Send/Request » acyclique ;

– l’« opération Send/Request » cyclique, soit la scrutation (polling) ;

– l’enregistrement de stations.

3.3.1.1 Gestion du passage du jeton

Le contrôle du passage de jeton est géré par chaque station maître à partir de laconnaissance de son prédécesseur (Previous Station, PS), la station de laquelle il reçoit lejeton, de son successeur (Next Station, NS), la station à laquelle le jeton sera transmis etenfin de sa propre adresse (This Station, TS) (figure 32).

Figure 32 : relation logique entre les adresses des stations maîtres d’après [EN_50170_2 1996]



Les adresses PS et NS sont déterminées par chacune des stations maîtres à partir del’initialisation des paramètres d’exploitation. Elles sont par la suite corrigéesdynamiquement en fonction des changements de configuration du réseau (ajout,suppression, défaillance d’une station). Le jeton passe d’une station à l’autre selon l’ordrenumérique ascendant des adresses des stations au moyen de la trame jeton, sauf lorsquele jeton arrive à la station ayant l’adresse la plus élevée. Dans ce cas, cette station letransmet à la plus petite adresse pour fermer l’anneau.

Si l’anneau ne comporte qu’un seul maître et plusieurs esclaves alors le systèmePROFIBUS devient un système maître-esclaves (mono-maître multi-esclaves).

Le système prend en compte les conditions d’erreur suivantes [EN_50170_2 1996] :

– jeton multiple ;

– perte du jeton ;

– erreur dans le passage du jeton ;

– adresses de station dupliquées ;

– stations dont les émetteurs-récepteurs sont défaillants ;

– ajout ou suppression de stations en cours d’opération ;

– toutes combinaisons de stations maître et esclaves.

3.3.1.2 Mode « Request » ou « Send/Request » acyclique

Dans ce mode, des cycles messages isolés sont réalisés sporadiquement. Le contrôleurFDL de la station maître initialise ce mode en raison d’une requête locale d’utilisation surréception du jeton. S’il y a plusieurs requêtes, ce mode d’opération peut continuer jusqu’àce que le temps de rotation du jeton permis expire.

3.3.1.3 Mode « Send/Request » cyclique

Lors de la scrutation, la station maître adresse cycliquement les stations avec larequête « send and Request Data flow », selon une séquence prédéfinie dans une liste descrutation. Cette liste de scrutation est fournie au contrôleur FDL par l’utilisateur localFDL. Toutes les stations maîtres et esclaves à scruter sont marquées dans cette liste. Lesstations ne répondant pas malgré plusieurs tentatives sont identifiées comme non-opérationnelles. Elles continuent de faire l’objet d’interrogation dans le prochain cycle,mais pas de re-tentative d’interrogation. En cas de réponse, elles redeviennent« opérationnelles ».

Après réception du jeton, le maître traite en premier lieu les cycles messages depriorité haute. Il réalise ensuite le cycle de scrutation en conformité avec la liste descrutation. Cette réalisation peut être segmentée sur plusieurs intervalles de temps depossession du jeton. Après réalisation complète, les cycles messages de priorité bassesont exécutés. Un nouveau cycle de scrutation peut ensuite commencer.

Si exigé, la scrutation est à l’origine de cycles messages de priorité basse additionnelstels que le cycle d’une requête acyclique...

3.3.1.4 Enregistrement des stations

Le protocole PROFIBUS prend en charge l’ajout ou la suppression de stations sur sonréseau.

A cette fin, chaque station maître dans l’anneau logique du jeton maintient en local uneliste d’adresses, appelée « GAP List », comportant l’ensemble des adresses des stations duréseau comprises dans l’intervalle d’adresses (le « GAP ») défini par sa propre adresse TS etcelle de la prochaine station maître active NS. Chaque station maître est alors responsable del’ajout et de la suppression de stations dont les adresses appartiennent à cet intervalle GAP.Le cycle de maintenance du GAP d’une station maître consiste en un examen périodique desadresses GAP et une recherche de tout changement parmi les stations maîtres et esclaves àl’aide de « requêtes de demande d’état » (Request FDL Status). Une station maître l’effectue,après réception du jeton, s’il reste du temps libre après réalisation de tous les cycles messages.S’il n’en reste pas, elle s’en chargera à la prochaine ou encore à la suivante réception de jetonen fin de réalisation des cycles messages de priorité haute. La norme [EN_50170_2 1996]remarque qu’il doit être fait attention, lors de réalisation, que les cycles de maintenance duGAP et de message de priorité basse ne se bloquent pas les uns et les autres.

3.3.2 Format de la trame PROFIBUS

Le format général de la trame PROFIBUS est représenté figure 33 d’après[Schickhuber et McCarthy ; Siemens 1999].

Dans [EN_50170_2 1996], PROFIBUS définit plusieurs format de trames : destrames de format fixe sans données (trame de requête, d’acquittement ou encore celled’acquittement court constitué d’un seul caractère) ; des trames de longueur fixe avec desdonnées (trame Send/Request, trame de réponse) ; des trames de longueur variablecomportant un champ longueur redondé (trame Send/Request, trame de réponse) ; unetrame jeton sans données, sans champ longueur, sans FCS et fin de trame.



Les différents formats de la trame sont annoncés par une valeur particulière du ou deschamps SD. Le type de la trame, par exemple celle d’une trame d’action Request ouSend/Request, d’acquittement ou de réponse, est identifié par le codage de l’octet decontrôle FC.

Signalons encore que chaque trame est constituée d’un ensemble de caractères auformat UART. Ces caractères de 11 bits, définis pour la transmission asynchrone,comportent un bit start, 8 bits d’information, un bit de parité et se terminent enfin par unbit stop. L’utilisation par PROFIBUS de ce type de caractères permet la synchronisationbinaire rendue difficile par le codage NRZ (voir le chapitre 3).

3.4 Protocole du réseau BITBUS


Nous avons peu d’informations sur le protocole du réseau BITBUS si ce n’est quel’accès au bus se fait selon un protocole d’interrogation mono-maître multi-esclaves. Unesclave n’accède au bus qu’en réponse à une interrogation du maître, une communicationentre esclaves ne peut avoir lieu qu’avec l’intermédiaire du maître. L’interrogation desdifférents esclaves par le maître se fait régulièrement par scrutation selon une séquenceprogrammée [Ciame 1999].

3.4.2 Format de la trame BITBUS

La trame BITBUS est conforme au format de la trame SDLC (sous-ensemble de latrame HDLC pour lequel le champ information est organisé en octet) (figure 34).

Figure 34 : format de la trame BITBUS [Ciame 1999]



Figure 33 : format de la trame PROFIBUS d’après [Schickhuber et McCarthy ; Siemens 1999]

4. Accès par compétition (contention, CSMA)

4.1 Introduction : le protocole IEEE 802.3

Le protocole à compétition le plus connu est le protocole CSMA/CD (Carrier SenseMedium Access with Collision Detection). Il a été développé et breveté à l’origine parXerox pour son réseau local Ethernet. Il a par la suite servi de base pour la norme IEEE802.3 [Lagrange et Seret 1998].

Le principe du protocole d’accès CSMA/CD est le suivant (figure 36). Un nœudsouhaitant émettre regarde l’état du médium de transmission. Si celui-ci est inoccupé(libre), alors il transmet. Sinon, il continue d’écouter le canal de transmission jusqu’à cequ’il soit libre et transmet alors immédiatement. En cas de détection de collision lors dela transmission (par détection d’interférences), il transmet un signal de brouillage dedurée suffisante pour que l’ensemble des nœuds détecte la collision et cesse d’émettre.Après ce signal de brouillage, le nœud attend alors pendant un certain temps avant detenter de ré-émettre selon le protocole décrit. Ce temps d’attente est tiré aléatoirement dela loi exponentielle binaire dont la moyenne est fixée pour la première ré-émission et estdoublée après chaque collision [Rolin 1990].

Figure 35 : algorithme CSMA/CD



Les protocoles à compétition CSMA mettent en œuvre différentes stratégies de reportde transmission lorsque le canal est trouvé occupé. La figure 36 illustre trois exemplesd’algorithmes :

– algorithme Non-persistant : transmission immédiate si le bus est trouvé libre. Sinonou en cas de collision, attente d’un délai constant ou variable avant re-tentative.L’utilisation d’un temps d’attente aléatoire réduit le risque de collision.

– algorithme 1-persistant : transmission immédiate dès que le canal est libre. En casde collision, attente que le canal soit libre puis transmission immédiate (soit unetransmission avec une probabilité de collision de « 1 » si plusieurs nœuds sont prêtsà émettre). Cet algorithme réduit le temps d’attente.

– algorithme p-persistant : attente de la libération du bus s’il est occupé, sinontransmission avec une probabilité « p » ou attente d’un intervalle de temps avec uneprobabilité « 1-p » (typiquement intervalle de la durée du délai maximum depropagation). En cas de délai de transmission d’un intervalle de temps, re-tentativeconformément à cet algorithme.

Les algorithmes CSMA mis en œuvre par les protocoles CAN et LONWORKS sontencore différents. Ils sont expliqués dans les paragraphes suivants.

Figure 36 : protocoles CSMA – quelques stratégies de report de transmission[Misic 1999]



4.2 Protocole d’accès au bus CAN

Dans cette partie, nous présentons la méthode d’accès du protocole CAN (couche 2)et le format de ses trames. A titre de conclusion, nous évoquons alors un cas particulierd’utilisation de ce protocole CAN avec la couche application CANopen.


Le protocole CAN est un protocole multi-maîtres qui supporte un accès spontané etsimultané de plusieurs stations maîtres. Ces accès concurrents sont réalisés selon unprotocole CSMA. Contrairement au protocole CSMA/CD, la collision produite est nondestructive pour l’information transmise prioritaire. Le protocole a aussi la faculté defonctionner selon un mode maître-esclave. A cette fin, une trame de « requête de donnéesà distance » (Remote transfer request) lui permet d’initier l’émission d’une trame deréponse en provenance d’une station esclave (paragraphe 4.2.2 de ce chapitre).

En cas d’accès simultané de plusieurs stations maîtres sur le bus, et donc de contention,la non-destruction de la trame prioritaire est réalisée par un arbitrage bit-à-bit sur le champd’arbitrage de la trame [Dang et Wahl 1994]. La notion de priorité d’accès et de non-destruction repose sur la définition de deux états (figure 37) : l’état « récessif » (niveaulogique ‘1’) et l’état « dominant » (niveau logique ‘0’). L’état dominant impose son étatsur l’état récessif. Il est celui qui résulte d’une collision entre un état dominant et un étatrécessif14. Dès détection de collision par une station émettrice d’un état récessif (détectiond’un niveau dominant sur le bus), cette station arrête immédiatement sa transmission desorte à ne pas gêner la transmission des bits de la trame prioritaire (figure 37). Elle retented’émettre lorsque le bus est libre après un temps T constant. Cette station a perdu lapriorité. La définition des deux états est obtenue pour une ligne de transmission en bandede base sur un médium en cuivre par un câblage de type Et-câblé.

Le champ d’arbitrage sur lequel se fait l’arbitrage bit-à-bit est composé du champd’identification et d’un bit, nommé bit RTR (voir le paragraphe 4.2.2 suivant). Salongueur est de 12 bits ou de 32 bits si le format étendu est choisi. Ce champd’identification identifie le contenu de la trame et doit être attribué de façon unique. S’ilne l’est pas, la station émettrice qui détecte une collision en dehors de ce champ bloquetoute émission sur le bus par la transmission d’un signal d’erreur (6 états dominantsconsécutifs) : dès que le bus est de nouveau libre les deux stations vont retenter d’émettreaprès le délai T, ce qui occasionnera de nouveau une collision...

A titre de comparaison entre les méthodes CSMA/CD et « CSMA avec accès nondestructif pour la trame prioritaire par arbitrage bit à bit », le schéma de la figure 38illustrant le protocole CSMA avec arbitrage bit à bit du CAN utilise le même format quele schéma de la figure 35 illustrant le protocole d’accès CSMA/CD.

Figure 38 : méthode d’accès CSMA avec arbitrage bit à bit et accès prioritaire



Figure 37 : arbitrage bit à bit sur le champ d’arbitrage de la trame CAN

14 Pour un support cuivre en bande de base, l’état dominant du protocole CAN (niveau logique‘0’) est représenté par un niveau de tension bas (0V), l’état récessif (niveau logique ‘1’) par unniveau de tension haut. Pour un support fibre optique, l’état dominant est caractérisé par laprésence d’émission de lumière (visible ou non) et le niveau récessif par son absence, demême pour un support infrarouge.

4.2.2 Format de la trame CAN

Les différentes trames CAN sont [Paret 1996] :

– la trame de données dont le format est donné en figure 39.

Figure 39 : trame de donnée CAN [Bosch 1991]



La trame de données permet le transfert de 0 à 8 octets de données identifiées parun identificateur de 11 ou 29 bits (selon le format choisi pour le réseau). Une telletrame émise sur le médium est acceptée ou refusée en réception par les stations dumédium sur filtrage de la valeur de son identificateur.

Elle est composée des champs suivants : un champ début de trame ; un champd’arbitrage sur lequel est réalisé, lors d’accès simultanés de plusieurs stations aumédium, l’arbitrage bit à bit donnant un accès prioritaire à la trame possédantl’identificateur de plus petite valeur ; un champ de contrôle spécifiant notammentle nombre d’octets de données de la trame ; un champ de données de 0 à 8 octets ;un CRC sur 15 bits calculé sur l’ensemble constitué des champs d’arbitrage, decontrôle et de données ; enfin, un champ fin de trame suivi d’un délai inter-trame.Après écoulement de ce délai inter-trame à la suite de l’émission d’une trame, lebus est considéré comme libre par l’ensemble des stations. Le champ d’arbitragecomprend un identificateur qui identifie de façon unique le contenu de la trame etun bit RTR au niveau dominant pour une trame de données. Le champ acquittementpermet à un récepteur de la trame d’acquitter sa bonne réception par insertion d’unniveau dominant dans la trame de l’émetteur.

– la trame de requête (remote frame)

Elle permet d’effectuer une demande d’information. La nature de cette demande estidentifiée de façon unique par la valeur de l’identificateur. De même format que latrame de données illustrée en figure 39, elle s’en distingue par la valeur du bit RTR(remote transfer request), cette fois au niveau récessif. D’autre part, son champ dedonnées est toujours vide (0 octet).

– la trame d’erreur

Elle est constituée de deux champs, un champ de drapeaux d’erreurs et undélimiteur de champ. Elle peut être une trame d’erreurs actives (émission de sixniveaux dominants). Dans ce cas, toutes les stations présentes sur le médiumdétectent l’existence d’une erreur et transmettent à leur tour une telle trame (la

longueur totale des trames d’erreurs actives cumulées est limitée). Elle peut aussiêtre une trame d’erreurs passives (émission de six niveaux récessifs). Dans ce cas,elle ne gêne pas les transmissions sur le bus. De façon à ne pas bloquer le réseau,un contrôleur CAN ayant émis consécutivement plusieurs trames d’erreurs activespeut être amené à se mettre dans un état d’erreurs passives [Paret 1996].

– la trame de surcharge (overload)

Elle a un format proche de la trame d’erreur. Elle est transmise dans plusieurs casde figures, notamment lorsque le récepteur a besoin de plus de temps pour traiterles données et demande de retarder la prochaine transmission d’un message.

4.2.3 Exemple particulier d’utilisation du protocole CAN

Alors que les protocoles à accès au médium par scrutation tels que TCN ou WorldFIPvont privilégier l’aspect « délai à respecter »15 en définissant une zone de trafic périodiqueet une autre apériodique, le protocole CAN privilégie les accès événementiels etnotamment les accès événementiels prioritaires. Il est alors coutume de dire que si lesdélais d’accès au médium et les temps de réponse sont calculables pour les messagesprioritaires, ils ne le sont pas toujours pour les messages moins prioritaires. Ceci nécessitealors une définition, au niveau de l’application, d’identificateurs adéquats permettant untrafic équitable entre les communications prioritaires et non prioritaires. C’est en partie lerôle des couches application disponibles sur le marché. Ces couches application spécifient,au dessus du protocole CAN, un fonctionnement particulier du réseau.

A titre d’illustration, nous donnons ici l’exemple du réseau CANopen. Ce protocolepropose un modèle d’équipement composé de trois parties [CANopen 2000]. Toutd’abord, une interface et un protocole logiciel de communication fournissent les servicesde transmission et de réception des objets communicants à travers le bus. Ils sont situésentre la couche 2 du protocole CAN et un dictionnaire d’objet. Le dictionnaire d’objetdécrit ensuite l’ensemble des types de données, d’objets de communication et d’objetsapplication utilisés par l’équipement. Il constitue l’interface avec un logiciel application.Enfin, le logiciel application fournit les fonctionnalités de contrôle interne et l’interfaceaux différentes fonctionnalités des matériels de traitements (soit des entrées/sorties). Lapartie qui nous intéresse ici est le protocole de communication. Il transmet un ensembled’objets sur le bus CAN qui sont décrits par leurs services et protocoles.

Ces protocoles sont :

– ceux des objets PDO (Process Data Objects – données processus) pour le transfertde données temps réel ;

– ceux des objets SDO (Service Data Objects – données services) pour l’accès enlecture et écriture des entrées du dictionnaire d’objets ;



15 Nous n’employons pas, volontairement, le terme de déterministe pour les réseaux decommunication, [Thomesse 1999] faisant remarquer d’une part que cette notion « n’existe pasen général si on n’a pas précisé les hypothèses en particulier de bon fonctionnement, de délaisupposé, etc. » et d’autre part que « ce paradigme doit s’appliquer d’abord au comportementdes applications qui doit être déterministe, quelles que soient les conditionsenvironnementales ».

– ceux des objets Special Function (fonction spéciale) pour le protocole desynchronisation spécifique à l’application cible, le protocole de datation (timestamping) et pour la transmission de messages urgents (Emergency Protocol) ;

– ceux de gestion de réseaux qui fournissent les services d’initialisation, de contrôled’erreur et de contrôle d’état des équipements.

Les trois modèles de communication utilisés sont le modèle producteur-consommateur, le modèle client-serveur et le modèle maître-esclave. Le modèleproducteur-consommateur est rendu possible par la diffusion de message et la faculté desstations à l’écoute du réseau de consommer (d’accepter) ou non un message surreconnaissance de son identificateur. Le modèle client-serveur est utilisé pour le transfertde données de taille supérieure au champ d’information de 8 octets de la trame CAN : lesdonnées sont segmentées en paquets émis successivement avec le même identificateur detrame. Pour ce modèle, une trame de confirmation est envoyée par le serveur à chaquerequête du client. Enfin, le modèle maître-esclave autorise la diffusion de données surinitiation d’un maître, dans le cas des communications non confirmées.

[CANopen 2000] décrit en outre les trois profils de communication suivants :

– la transmission de message

Elle est déclenchée par l’occurrence d’un événement spécifique à un objet enconformité avec la définition du profil de l’équipement. Périodiquement, latransmission des nœuds est déclenchée sur fin de temporisation, même si aucunévénement ne s’est produit.

– la transmission de PDO synchrone (protocol data object)

Elle est déclenchée après l’expiration d’une période de transmission synchroniséepar la réception d’un objet de synchronisation (l’objet « SYNC », figure 40). Les PDO synchrones sont transmis à l’intérieur d’une fenêtre temporelleconsécutive à l’objet de synchronisation SYNC. Leur priorité d’accès au médiumest supérieure à celle des objets de la transmission asynchrone (i.e. identificateursprioritaires). La transmission synchrone est divisée en un mode de transmissioncyclique et un acyclique. La transmission cyclique est périodique, celle acycliqueest déclenchée par une application. Toutes deux ont obligatoirement lieu dans lafenêtre synchrone.

– la transmission de PDO (ou SDO – service data object) asynchrone

Elle est initialisée sur réception d’une requête distante en provenance d’un autreéquipement. Cette transmission peut avoir lieu à n’importe quel moment, hors oudans une fenêtre synchrone, en conformité avec la priorité d’accès des PDOasynchrones associée à la définition de leurs identificateurs. Afin de ne pas gêner latransmission synchrone, elle doit utiliser une priorité moindre que celle affectée àla transmission synchrone [CANopen 2000].

L’exemple de CANopen montre donc qu’il est également possible d’imposer unfonctionnement particulier au protocole CAN de manière à définir des fenêtrestemporelles de communication dans lesquelles prennent place des transmissionscycliques et acycliques.



4.3 Protocole d’accès au réseau LONWORKS (protocole LonTalk)

Dans un premier paragraphe, nous rappelons ci-après la définition des six coucheshautes des réseaux LONWORKS, d’après le standard [ANSI/EIA-709.1-A 1999], encommençant par la partie inférieure de la couche application jusqu’à la couche liaison dedonnées. Le paragraphe suivant présentera alors plus en détail l’algorithme d’accès aumédium « CSMA prédictif p-persistant » de la couche liaison de données. Cetteprésentation rapide de l’ensemble des couches du protocole LonTalk permettra de mieuxcomprendre l’espace d’adressage du réseau qui sera présenté avec le format de la trameLonTalk dans un troisième paragraphe. Nous verrons à cette occasion que contrairementaux autres réseaux décrits dans cette étude, ce protocole ne dispose pas d’adressage auniveau de la couche 2. Enfin, à titre de conclusion, nous évoquerons un cas particulierd’utilisation du réseau LONWORKS.

4.3.1 Accès au réseau LONWORKS (rappel sur les couches 7 à 2)

L’accès à un réseau LONWORKS se fait via les services offerts par la partie inférieurede la couche application.

Cette partie inférieure de la couche application (couche 7) et la couche présentation(couche 6) fournissent des services pour l’envoi et la réception des messages application.Ces services incluent des variables réseau et d’autres types de messages tels que ceux degestion de réseau et de diagnostics. La mise à jour d’une variable est possible parinterprétation de l’unité de protocole application (APDU) conformément auxinformations contenues dans l’entête de l’APDU. Cette interprétation des données,indépendante de l’application, permet de les partager parmi des nœuds sans arrangementau préalable.

[ANSI/EIA-709.1-A 1999] définit les couches session et transport comme le cœur dela hiérarchie du protocole. Une sous-couche commune « de contrôle de transaction »(Transaction Control Sublayer) gère l’ordonnancement de la transaction et la détectionde duplication. La couche transport est sans connexion et assure une livraison fiable des



Figure 40 : communication synchrone cyclique et acyclique et communicationasynchrone de CANopen [CANopen 2000]

messages à destinataires multiples ou uniques. L’authentification de l’identité del’émetteur est incluse comme un service de la couche transport pour être utilisé lorsquela sécurité le nécessite. Pour accomplir cette fonction, le serveur d’authentification faitseulement appel à la sous-couche contrôle de transaction. Par conséquent, les messagesdes couches transport et session peuvent être authentiques en utilisant tous les modesd’adressage autres que la diffusion.

La couche session (couche 5) fournit un mécanisme de Requête-Réponse pour l’accèsà des serveurs distants. Ce mécanisme permet de construire des appels à des procéduresdistantes spécifiques aux besoins de l’application. Le protocole de gestion du réseau EIA-709 dépend de ce mécanisme de Requête-Réponse.

Un message d’acquittement de la couche transport (couche 4) attend l’indication delivraison en provenance du ou des destinataires distants. Un message de Requête de lacouche session attend l’indication de réalisation des tâches distantes spécifiques àl’application. Un message donné utilise l’un ou l’autre type de service mais pas les deux.

La couche réseau (couche 3) gère la livraison des paquets à l’intérieur d’un domaine(paragraphe 4.3.3). Son service est sans connexion, sans acquittement et ne supporte ni lasegmentation, ni le ré-assemblage des messages. L’algorithme de routage qu’elle utilisepour apprendre la topologie suppose une topologie du réseau en arbre. Cependant, lesrouteurs qui possèdent des tables configurées peuvent opérer sur des topologiescomportant des boucles physiques tant que le chemin de communication logique estorganisé selon une topologie arbre. L’utilisation de tables configurées supporte aussi bienun adressage à une adresse donnée (unicast – mono-destinataire) qu’à un grouped’adresses. [ANSI/EIA-709.1-A 1999] signale que dans de nombreuses applications unsimple acheminement par inondation (flooding) de messages à l’adresse d’un groupe estsuffisant.

Enfin, la sous couche MAC de la couche liaison de données (couche 2) utilise unalgorithme d’évitement de collision appelé « Predictive p-persistent CSMA » (CarrierSense, Multiple Access). La sous-couche LLC supporte un service sans connexion. Sesfonctions sont la mise sous forme de trame, le codage de la trame, la détection d’erreursans recouvrement par retransmission. L’algorithme « CSMA Predictif p-persistent » estmaintenant présenté.

4.3.2 Méthode d’accès au médium (couche 2)

L’accès au médium d’un réseau LONWORKS se fait selon un algorithme CSMA/CA(Carrier Sense Multiple Access/ Collision Avoidance), appelé CSMA prédictif p-persistant. Cet algorithme donne à chaque nœud les mêmes droits d’accès au médium.

La méthode CSMA se réfère à une méthode d’accès au médium non déterministe.L’algorithme CSMA prédictif p-persistant se réfère à un schéma d’évitement de collisionqui rend aléatoire les accès au médium en utilisant la connaissance de la charge attenduedu réseau. L’algorithme ci-après décrit n’empêche cependant pas toutes les collisions,collisions alors destructives.

Un nœud ne peut tenter d’émettre que lorsque le bus est libre. Il vérifie donc avanttoute tentative que le canal de transmission est en veille pendant une durée minimale de



}1. Après avoir détecté un bus libre, le nœud génère alors un retard de transmissionaléatoire comportant un nombre d’intervalles de temps aléatoire de durée }2. Ce nombred’intervalles varie de 16 intervalles, pour un trafic peu chargé, à 1 008 intervalles, dans lecas d’une charge du bus maximale (figure 41). Si le bus est toujours à l’état de veille aprèsle retard aléatoirement généré, le nœud transmet. Si ce n’est plus le cas, il attend denouveau la libération du bus, puis laisse passer un nombre aléatoire d’intervalles de tempset, enfin, retente l’émission.

Figure 41 : intervalle de temps aléatoires du protocole CSMA prédictif p-persistant [ANSI/EIA-709.1-A 1999 ; Schweins et Heffernan 1998]



Lorsque le trafic du réseau augmente, chaque nœud communique aux autres l’état deses arriérés. Chaque nœud est alors capable de prédire dynamiquement le nombre depaquets par nœuds restant à transmettre et d’ajuster en conséquence le nombred’intervalles d’attente. Ainsi, un nœud transmet un paquet dans un intervalle de tempsaléatoire avec une probabilité « p » qui est fonction de la charge du bus.

Cet algorithme permet au réseau de continuer à travailler dans sa capacité maximalemalgré des conditions de surcharge [Schweins et Heffernan 1998]. Le nombre decollisions (la probabilité de collisions) est à cette fin réduit par l’augmentation du nombred’intervalles aléatoires sur lequel se fait le tirage aléatoire. Cependant, ce protocolen’élimine pas la possibilité que plusieurs nœuds tirent un même nombre d’intervalles detemps aléatoires à un instant donné, ce qui cause des collisions destructives.

Le protocole LonTalk offre un « service d’acheminement des données avecacquittement » et un « service sans acquittement ». Par défaut, le mode opératoire reposesur le service réseau avec acquittement. Dans ce mode, l’émetteur d’un paquet attend unacquittement du nœud destinataire informant de la bonne réception du paquet. Si l’attenteexcède un intervalle de temps déterminé, le paquet envoyé est supposé avoir subi unecollision et le nœud émetteur doit le ré-émettre à nouveau. En utilisant le service réseaunon-acquitté, le nœud émetteur d’un paquet n’a pas à attendre la réception del’acquittement. Cette option ne garantit pas le bon acheminement des données, maispermet de s’affranchir des délais aléatoires de transmission qui peuvent ne pas convenirà certaines applications temps critique.

Une autre option de LonTalk est celle de la « détection de collision ». Elle permet àla couche physique de notifier à la sous-couche MAC une détection de collision lors de

l’émission d’un message. L’utilisation de cette option permet à la couche MAC deretenter la transmission. Lorsque 256 tentatives d’émission d’un même message mènentà une collision, celui-ci est finalement détruit par le nœud émetteur.

Enfin, pour améliorer le temps de réponse des messages temps critique, le protocolede la couche MAC de LonTalk inclut une « option de priorité » basée sur une gestion desaccès. Quand un message prioritaire est généré, il quitte le nœud dans un intervalle detemps prioritaire, alors que les messages non prioritaires du nœud restent en mémoirepour une prochaine transmission.

Pour cela, des intervalles de temps prioritaires d’une durée }2 sont définisimmédiatement après le délai }1 et avant les 16 à 1 008 intervalles de temps aléatoires quiseront utilisés par les messages non prioritaires (figure 42). Il peut exister de 0 à127 intervalles prioritaires qui définissent une bande passante dédiée disponible pour unaccès prioritaire. Par exemple, un nœud transmettant avec la priorité quatre transmettra sonpaquet lors du quatrième intervalle prioritaire et n’aura ainsi pas à attendre un nombrealéatoire d’intervalles. Ces intervalles sont assignés exceptionnellement à des nœuds ducanal de communication. Un nœud ne peut être affecté qu’à un intervalle prioritaire, unintervalle prioritaire peut l’être à plusieurs nœuds. Ce dernier cas est, par exemple, utilisépour une communication mono-maître multi-esclaves. Les nœuds auxquels un intervalleprioritaire a été affecté n’ont pas à l’utiliser pour tous leurs messages. Seuls les messagesdont le bit de priorité de l’entête de la trame LPDU est positionné (bit du champ decontrôle de la trame représentée figure 43) sont émis par un nœud « prioritaire » avec lapriorité du nœud. Une application peut décider qu’un message a une priorité haute et tenterde l’émettre comme tel. Si aucun intervalle prioritaire n’est assigné à ce nœud, le messageest émis selon le protocole courant sans tenir compte de cette priorité, cependant indiquéedans l’entête de la trame LPDU. Si, par la suite, ce message passe par un routeur auquelest affecté un intervalle prioritaire sur le canal destinataire, le message est transmis enutilisant la priorité du routeur. Si le routeur n’a pas d’intervalle prioritaire affecté, il esttransmis selon le protocole usuel avec le bit de priorité maintenu positionné dans la trame.

Lorsque l’option « détection de collision » est également choisie et qu’une collisionest détectée deux fois de suite par un nœud tentant d’émettre dans son intervalleprioritaire, la prochaine tentative de transmission de son message prioritaire est réaliséeselon l’algorithme d’accès au médium non prioritaire.

Figure 42 : protocole CSMA prédictif p-persistant avec des intervalles de tempsprioritaires [ANSI/EIA-709.1-A 1999 ; Schweins et Heffernan 1998]



4.3.3 Format de la trame LonTalk et espace d’adressage

Le format de la trame LONWORKS de la couche physique (i.e. du PPDU – PhysicalProtocol Data Unit) est représenté figure 43. Cette trame comporte cinq champs. Lesdeux premiers champs ne sont pas définis dans la norme ANSI/EIA-709.1-A du protocoleLonTalk [ANSI/EIA-709.1-A 1999]. Leur spécification dépend de celle de la couchephysique choisie. Ces deux champs servent à la synchronisation émetteur-récepteurs auniveau des éléments binaires et du bloc d’information octet. Un troisième champ, lechamp de contrôle, dépend de la couche liaison de données. Il est suivi du champ NPDUqui contient les données de la couche réseau. La trame se termine par un Code deRedondance Cyclique (CRC) défini sur 16 bits.

Le protocole LonTalk, contrairement aux protocoles que nous avons déjà parcourus,ne dispose pas d’adresse de niveau 2 (couche liaison de donnée). Le champ adresse estdéfini dans la trame NPDU (Network Protocol Data Unit). Il contient une combinaisond’adresses de niveau 3 et 4 (couches réseau et transport) (figures 43 et 44). Parconséquent, toute trame transporte une adresse source et destination.

Figure 43 : format d’une trame LONWORKS d’après la norme [ANSI/EIA-709.1-A 1999]



L’adressage dans un réseau LONWORKS est structuré hiérarchiquement. Il repose surla définition des entités hiérarchiques suivantes :

– le domaine (Domain), niveau de hiérarchie 1,

– le sous-réseau (Subnet) et le groupe (Group), niveau de hiérarchie 2,

– le nœud (Node), le membre (Member) et l’« identificateur unique d’un nœud »(Unique_Node_ID), niveau de hiérarchie 3.

Ces entités permettent de définir trois types d’adresses élémentaires (figure 44) :

– l’adresse « Domaine, Sous-réseau, Nœud » ;

– l’adresse « Domaine, Sous-réseau, Unique_Node_ID » ;

– l’adresse « Domaine, Groupe, Membre ».

Figure 44 : format du champ « adresse » de la trame LONWORKS [ANSI/EIA-709.1-A 1999]



Le domaine (Domain) peut être considéré comme un « réseau virtuel » dans lequel lescommunications sont limitées en son sein. Les adresses destination et source des unitésde données de protocole réseau et transport (NPDU et TPDU) appartiennentobligatoirement à un même domaine. La communication entre domaines de taillesdifférentes n’est possible qu’avec l’utilisation d’une passerelle définie au niveauapplication. Le domaine est donc, à l’échelle d’un système, considéré comme l’unité degestion et d’administration. La taille de l’adresse du domaine est variable (0, 1, 3 ou6 octets). Elle dépend du contexte de l’application étudiée. Si celle-ci est à l’échelle dumonde, une adresse sur 6 octets sera nécessaire. Pour une application embarquée surmatériel ferroviaire guidé roulant, elle pourra être plus petite.

A l’intérieur d’un domaine peuvent être définis des sous-réseaux et des groupes. Unsous-réseau (Subnet) est un sous-ensemble d’un domaine qui contient de 0 à 127 nœudset dans lequel il n’y a pas de routage de l’information. Ce sous-ensemble logique,indépendant du canal physique, est utilisé par le protocole de routage. Jusqu’à 255 sous-réseaux d’un domaine peuvent être identifiés par une adresse sur 8 bits. Un nœud logique(Node) d’un sous-réseau est identifié à l’intérieur de ce sous-réseau par un identificateur.Un nœud physique peut appartenir au plus à deux sous-réseaux de deux domainesdifférents ; il a alors deux identificateurs différents. Les nœuds d’un sous-réseau peuvent

être séparés par des répéteurs et des ponts (bridge). La définition de groupes comportantjusqu’à 63 nœuds à l’intérieur d’un domaine permet de supporter un adressagefonctionnel au sein de ce domaine. Chaque membre d’un groupe est identifié au sein dugroupe par son numéro de membre (Member). Un champ d’adresse de 8 bits permet despécifier jusqu’à 256 groupes dans un domaine.

Chaque nœud possède un « identificateur de nœud unique » (Unique_Node_ID).C’est une adresse sur 48 bits attribuée à chaque circuit « Neuron » lors de leurfabrication. Cette adresse, différente pour chaque circuit conçu, est définie en conformitéavec l’accord « Lontalk Protocol Patent License Agreement ». Elle identifie donc uncircuit « Neuron » de façon unique à l’échelle mondiale et, par conséquent, le nœud quil’intègre. En plus de cette adresse Unique_Node_ID, un nœud peut se voir assigner uneou deux adresses « domaine, sous-réseau, nœud » et de zéro à quinze adresses « domaine,groupe, membre ».

4.3.4 Exemples particuliers d’utilisation du protocole LONWORKS

Le réseau LONWORKS, comme le réseau CAN, possède un protocole d’accès aumédium construit sur une méthode d’accès CSMA qui ne permet pas facilement ettoujours de déterminer avec précision les temps d’accès et de réponse du réseau. Les deuxexemples suivants présentent brièvement deux utilisations particulières du réseauLONWORKS, l’un non dédié aux applications ferroviaires, l’autre construit à l’occasion dela collaboration entre la SNCF et la DB sur le frein électronique.

4.3.4.1 Exemple non dédié ferroviaire

Dans [Schweins et Heffernan 1998], les auteurs présentent un cas particulier etexpérimental de fonctionnement du réseau LONWORKS auquel ils ont imposé de pouvoirgarantir les temps de réponse. Pour cela, ils ont construit un ordonnanceur périodique encombinant des techniques matériels et logiciels (figure 45), pour compenser l’absenced’entrée d’interruption matérielle temps réel des composants « Neuron-Chip ». Cetordonnanceur transmet périodiquement un signal de synchronisation matériel et logicielaux nœuds. Sur réception de ce signal, chaque nœud est autorisé à transmettre lesmessages de sa file d’attente en respect avec l’intervalle prioritaire qui lui est affecté[Schweins et Heffernan 1998]. Dans cette configuration, chaque nœud possède unintervalle prioritaire différent.

4.3.4.2 Exemple européen d’expérimentation pour le freinélectronique (FEBIS)

Le projet FEBIS (Freight Electronic Brake and Information System) est un exemplede développement d’un système de communication, devant notamment supporterl’application de freinage électronique, pour des trains de fret de longueur 2 250 m, de125 wagons au maximum et de 4 locomotives [Tione 2001]. Il est mené par la SNCF etla DB en partenariat avec les industriels SAB Wabco et Alstom. Le protocole decommunication FEBIS développé repose sur l’utilisation de la technologie LONWORKS.Quelques caractéristiques de ce protocole maître-esclaves sont décrites ci-après d’aprèsles articles de [Grasso et al. 2001 ; Witte et al. 2001].



Le protocole FEBIS met en œuvre trois types de nœuds connectés :

– l’unité de contrôle maître (MCU – Master Control Unit), située dans la locomotivemeneuse et en charge du réseau ;

– les unités de contrôle local (LCU – Local Control Unit), nœuds esclaves situés danstout type de véhicule (wagon ou locomotive) et contrôlant en local leurs fonctions ;

– enfin, les deux unités de communication terminant les deux extrémités du réseauen bus (ECU – End Communication Unit), nœuds esclaves qui ont pour tâched’assurer l’intégrité du train, à la fois pour la sécurité opérationnelle et la sécuritéélectrique (l’un des média courant porteur de LONWORKS transporte un courant de230 VDC, l’autre de 48 VDC).

Les nœuds esclaves (LCU ou ECU) sont appelés « serveurs de communication ». Lenœud maître (MCU) abrite la tâche de « gestionnaire de communication ». Nœudsesclaves et nœud maître peuvent accueillir plusieurs applications distribuées. Pourpermettre cela, le protocole FEBIS distingue les tâches « maîtres d’applications » de latâche « maître du réseau » :

– les maîtres d’applications sont chargés chacun de coordonner les échanges d’uneapplication distribuée (« DA » – Distributed Application), c’est à dire d’uneapplication dont l’exécution met en jeu plus d’un nœud du réseau decommunication. Certaines applications peuvent avoir leur maître redondé.

– la tâche « maître du réseau », appelée « gestionnaire de communication » (CM –Communication Manager), est chargée de l’ordonnancement des communicationssur le bus, soit du partage du canal.



Figure 45 : exemple d’utilisation particulière de LONWORKS, non dédié ferroviaire, par [Schweins et Heffernan 1998]

Des exemples d’applications distribuée sont celles de « contrôle de frein », « tractionen unité multiple », « intégrité du train » et « diagnostic du train » [Grasso et al. 2001]. Latâche maître d’une telle application gère les communications entre les différents nœuds encharge de l’exécution locale d’une partie de l’application selon un protocole maître-esclaves : elle génère les commandes, attend des réponses quand cela est nécessaire.Chaque application distribuée est identifiée sur le réseau par un unique identificateurd’application (ID). Cet identificateur est partagé par l’ensemble des nœuds participant àl’exécution de l’application distribuée ainsi reconnue. Afin d’assurer l’interopérabilité desapplications courantes d’un train avec celles futures, [Grasso et al. 2001] soulève lanécessité d’un standard définissant les règles d’attribution de ces identificateurs.

La tâche maître du réseau ou « gestionnaire de communication CM » est une destâches de l’unité de contrôle maître (MCU). Elle configure et gère les services decommunications synchrones et asynchrones pour chaque application distribuée du bustrain. Cette gestion se fait en tenant compte des priorités des applications, de leurpériodicité, de la bande passante disponible sur le canal et des échanges de donnéesrequises pour ces applications distribuées. L’ensemble de ces informations sont collectéeslors de la phase d’initialisation des applications distribuées et sont alors utilisées pourconstruire chaque période de communication (de 400 ms dans l’exemple donné [Grassoet al. 2001]). Cette phase d’initialisation des applications distribuées prend place aprèscelle de l’inauguration du train qui correspond à l’initialisation du réseau (recherche desnœuds de fin de réseau, numérotation des nœuds....).

Chaque période de communication, construite par le gestionnaire de communication,comporte trois phases de communication :

– une première phase est dédiée au service synchrone,

– une seconde phase au service asynchrone,

– enfin une troisième est réservée aux alarmes. Cette dernière occupe au moins 30 %de la période de communication (figure 46).

La phase synchrone débute par une trame de synchronisation suivie d’intervalles decommunication, chacune dédiée à une application identifiée. La trame de synchronisationspécifie le nombre d’intervalles de communication de la phase synchrone courante et,pour chacun de ces intervalles, un paramètre et l’ID d’une application. Le paramètretransmis avec l’ID de l’application distribuée sert au calcul par le maître de l’applicationID du délai d’attente préalable à sa tentative de préemption du bus. Le protocole FEBISgarantit, à l’aide de ces paramètres, l’échelonnement des tentatives de transmission et,ainsi, la phase synchrone de toute collision. La trame de synchronisation diffère lorsquele maître des tâches applicatives mentionnées est localisé dans le même nœud que celuiresponsable de la tâche de gestion du réseau (soit le nœud MCU). Elle transporte alorségalement les commandes aux esclaves des applications mentionnées. Par contre, lemaître d’une application distribuée ID localisé dans un autre nœud que le MCUtransmettra, seulement après préemption du bus, sa liste de commandes à l’adresse desesclaves participant à l’application ID (figure 46).

D’après [Grasso et al. 2001], le service asynchrone permet aux applicationsd’échanger des paquets de données sur le bus train « d’une façon quasi aléatoire », c’est



à dire qui font suite à une demande de ce service par un événement temps réelasynchrone. Ce service n’est pas conçu pour les échanges lors des modes d’initialisationet de maintenance du réseau, mais pour ceux ayant lieu lors du mode de fonctionnementcourant (en cours d’exploitation). [Grasso et al. 2001] ne précise pas comment legestionnaire du réseau CM prend en compte les requêtes des applications distribuées pource service et affecte les fenêtres de communication entre les applications distribuéesdemandeuses.

Le service « alarme » permet aux applications distribuées de transmettre des paquetsde données hors contrôle du gestionnaire de communications. Ce service utilise lesfonctionnalités de compétitions et de priorités du protocole LONWORKS. Il est utilisé pourdes messages d’alarmes courts signalant l’occurrence en temps réel d’un événement àrisque sur le système.

Figure 46 : partage du canal (protocole FEBIS)



5. ConclusionDans ce chapitre ont été présentées les différentes méthodes d’accès au médium des

réseaux de communication actuellement d’intérêt pour les communications embarquéesdans les matériels roulants guidés. Ces méthodes montrent le choix de solutionsalgorithmiques très différentes. Toutes les solutions implémentées par la couche 2 desprotocoles de ces réseaux, à l’exception de celle du protocole LonTalk, sont implantéesen matériel et possèdent un adressage de niveau MAC. Ces solutions sont des protocolesd’accès au médium par passage de jeton, par scrutation, par contention, voire unecombinaison de ces protocoles.

Pour les applications ferroviaires temps critique, les constructeurs cherchent àgarantir le déterminisme de leurs applications. Pour cela, la définition de deux types detrafics, synchrone et sporadique, comme les spécifient les protocoles WorldFIP et TCNpar exemple, semble intéressant afin de garantir aux variables temps critique des délaisd’acheminement connus. Si les protocoles de communication par scrutation ou jetonpermettent a priori d’ordonnancer plus facilement les tâches de communication par ladéfinition de cycles de transmission composés d’une phase périodique et apériodique,l’exemple de la couche application CANopen, fondée sur l’utilisation du protocole àaccès aléatoire CAN, montre que ce réseau peut également supporter sans difficulté cettedécomposition en cycle. Ceci semble un peu plus compliqué avec le protocoleLONWORKS [Schweins et Heffernan 1998]. Pour ces deux protocoles, l’ordonnancementdes communications se fait par l’émission cyclique d’une trame de synchronisation, quimarque les débuts de transmission, et par une bonne gestion des priorités d’accès aumédium.



Chapitre 5

Quelques mots sur la sûreté defonctionnement dans le ferroviaire

1. Introduction

Le secteur ferroviaire est soumis à de fortes contraintes en terme de sûreté defonctionnement. Un incident non prévu intervenant sur un train pourrait être générateurd’événements graves. C’est pourquoi, avant de clore cette synthèse, nous présentons ci-après les différentes normes européennes ferroviaires relatives à la sûreté defonctionnement, puis celles concernant la sûreté de fonctionnement des communicationsembarquées à bord des trains. Les informations ci-dessous sont reprises de [Wahl 1999].

2. Normes relatives à la sûreté de fonctionnement des applications ferroviaires

Afin de pouvoir se conformer aux exigences de la sûreté de fonctionnement dessystèmes, un ensemble de normes a été spécifié. Ces normes sont relatives aux systèmes,sous-systèmes ou équipements de sécurité, c’est-à-dire à tous systèmes, sous-systèmes ouéquipements dont le dysfonctionnement pourrait engendrer un incident grave (parexemple un système de signalisation, de contrôle de la vitesse...). Le cas des systèmes quine sont pas de sécurité (par exemple un système de climatisation, d’éclairage...) ne fontpas l’objet de ces standards.

Dans les années 80, chaque pays de la communauté européenne a défini ses propresexigences sur la sécurité des systèmes à partir des recommandations définies dans lescodes de l’Union Internationale des Chemins de fer (UIC code 738R) [Hirao et Watanabe1998]. La Commission Electrotechnique Internationale (IEC – InternationalElectrotechnical Commision), de son côté, a développé un standard (IEC 61508) sur lasécurité pour les systèmes de traitements automatisés non dédiés. Ce standard introduitles cycles de vie de la sécurité et adopte des niveaux d’intégrité qui définissent lesmesures à mettre en place pour l’obtention du niveau de sécurité exigé. Sur la base desdocuments IEC 61508, le Comité Européen pour la Normalisation Electrotechnique(CENELEC) a défini à son tour des normes pour la sécurité des applications ferroviaires,des systèmes de contrôle de trains et de signalisation ferroviaire. Ces normes[NF_EN_50126 2000], [NF_EN_50128 2001] et [XP_ENV_50129 1999], soutenues parla communauté européenne, remplacent celles des pays de l’union. Elles sont la référencede base pour le développement des systèmes de contrôle de train et de signalisation[ElKoursi et al. 1998].


Les normes prEN 50126 et prEN 50129, basées sur les cycles de vie du système,définissent respectivement les processus pour la spécification et la démonstration desprescriptions de sûreté de fonctionnement (fiabilité, disponibilité, maintenabilité etsécurité) pour l’industrie ferroviaire [NF_EN_50126 2000] et les conditions à respecterpour qu’un système, un sous-système ou un composant d’un équipement soit acceptécomme étant de sécurité [XP_ENV_50129 1999]. La norme prEN 50128 spécifie lesprocédures et exigences techniques pour le développement des logiciels des systèmesélectroniques programmables dédiés à toutes les applications de commande et deprotection ferroviaires (applications ayant ou non des implications sur la sécurité).

Une quatrième norme en deux parties (prEN 50159-1 et prEN 50159-2) s’intéresseaux communications en sécurité pour les systèmes de signalisation, detélécommunication et de traitement. La figure 1 montre les domaines couverts parl’ensemble des ces références.

Figure 1 : les références ferroviaires concernant la sécurité dans le ferroviaire [XP_ENV_50129 1999]



3. Normes relatives aux communications embarquéesLes normes prEN50159-1 et -2 concernent les communications en sécurité entre

équipements qui utilisent un système de transmission fermé prEN 50159-1[prEN_50159-1 1998] ou ouvert prEN 50159-2 [NF_EN_50159-2 2001]. Un système detransmission est dit fermé lorsque les conditions suivantes sont réunies : seuls les accèsautorisés sont permis, il y a un nombre maximal connu d’entités connectables, le médiumde transmission est connu et restera inchangé toute la durée de vie du système. Lesystème de transmission est dit ouvert quand au moins une des trois conditionsprécédentes n’est pas remplie.

Ces normes ne définissent pas, ni ne font de recommandations sur le choix d’unsystème de transmission particulier. Elles insistent sur le fait que tout système detransmission est à considérer comme non sûr. La connaissance des propriétés et ducomportement du système de transmission est seulement utilisable pour la définition desperformances du système. Les aspects de sécurité doivent être couverts par l’application

de procédures et de codes de sécurité implantés au sein des équipements liés à la sécurité[NF_EN_50159-2 2001]. Dans le cas d’un système ouvert par exemple, la norme[NF_EN_50159-2 2001] recommande de considérer quatre types de services pour réduireles risques de mauvaises transmissions (répétition, destruction, insertion, re-séquencement, corruption ou retardement) : les services d’authentification, d’intégrité,d’actualité (timeliness) et de séquence des messages. Pour cela l’ensemble des moyenssuivants peut être utilisé : numéro de séquence, horodatage, temporisateur (time-out),retour de message, identificateur de la source et du destinataire, procédured’identification, code de sécurité, techniques de cryptographie.

Notons que, sur le marché, des couches sécurité sont à l’étude pour différents réseauxde communication. On peut citer SafetyBus bus de terrain fondé sur le protocole CAN etle protocole ProfiSafe utilisant PROFIBUS.

4. Maintenabilité d’un systèmeLa « maintenabilité » est l’un des quatre attributs de la sûreté de fonctionnement d’un

système définis par la norme prEN 50126 (les autres étant la fiabilité, la disponibilité etla sécurité). Pour un système de traitement de données, [EuroDicAutom_4] donne lesdéfinitions de la « maintenabilité » suivantes :

a) « facilité avec laquelle un logiciel peut être entretenu ; »

b) « facilité avec laquelle la maintenance d’une unité fonctionnelle peut être assuréeconformément à des consignes d’entretien ; »

c) « aptitude d’un élément à être, dans des conditions déclarées, entretenu ou ramené,pendant un temps donné, dans un état spécifique propre à assurer les fonctions requisesquand l’entretien est exécuté dans des conditions précises en utilisant des procédures etdes moyens prescrits. »

Les préoccupations concernant ces différents aspects de la maintenabilité sont trèsfortes aussi bien dans le secteur ferroviaire que pour les concepteurs de réseaux decommunication.

En ce qui concerne les réseaux, les constructeurs mettent en œuvre et offre dans lecommerce des outils d’aide au développement d’applications et au diagnostique. Desliens vers des vendeurs de tels produits sont disponibles sur les pages web desconstructeurs (soit [Echelon_URL ; Lonmark_URL] pour le réseau LONWORKS,[CAN_cia_URL] pour les protocoles CAN et les couches application disponibles sur lemarché pour la technologie CAN, [WorldFIP_URL] pour le protocole WorldFIP,[PROFIBUS_URL] pour le protocole Profibus). Ces outils permettent généralementd’avoir accès aux objets gérés par la couche liaison de données des réseaux considérés,objets caractéristiques du réseau ou des applications implantées par les équipements.

Cette maintenabilité est également un des objectifs du projet européen« TrainCom16 » (Train-ground communication infrastructure) débuté en décembre 2000.

Quelques mots sur la sûreté de fonctionnement dans le ferroviaire


16 Les partenaires du projet TrainCom sont le co-ordinateur SIEMENS Aktiengesellschaft(Allemagne), les partenaires DaimlerChrysler Rail Systems GmbH, ADTRANZ (Allemagne), et

Ce projet, qui prend en compte les résultats du projet ROSIN, doit notamment permettreune gestion de la flotte de trains fondée sur une maintenance et un diagnostique effectuésà distance [TrainCom_URL]. Il a ainsi pour objectif la définition d’un lien standard entreles réseaux numériques embarqués (TCN, FIP,...) et les services au sol. Un tel système,qui fournit une passerelle entre un système embarqué à bord d’un matériel roulant et unposte de contrôle de l’infrastructure ferroviaire via des communications sans fils(figures 2 et 3), nécessitera de faire intervenir notamment des techniques d’authen-tification et de cryptographie de l’information afin d’en garantir l’origine et l’intégrité.

Figure 2 : exemple d’un ensemble de systèmes de communication embarqué mis en œuvre pour l’envoi d’information à une station [Adtranz 2001]



son partenaire associé italien DaimlerChrysler Rail Systems S.p.A., ADTRANZ, ANSALDOTrasporti S.p.A. (Italie), et son partenaire assistant ATOS S.p.A., les partenairesConstrucciones y Auxiliar De Ferrocarriles S.A. (Espagne), FAR SYSTEMS SpA (Italie),FIREMA Trasporti S.p.A (Italie), SC Silogic srl,SILOGIC (Roumanie) ; Deutsche BahnReise&Touristik AG (Allemagne) ; Ferrovie dello Stato Società di Trasporti e Servizi S.p.A.(Italie) ; Österreichische Bundesbahnen,OEBB (Autriche) ; Red Nacional de FerrocarrilesEspañoles (Espagne) ; Alstom Transport SA (France)

5. ConclusionBien que la sûreté de fonctionnement n’ait pas été l’objet de ce rapport, nous avons

souhaité avec ces quelques mots attirer l’attention sur l’importance qu’elle revêt dans ledomaine ferroviaire, importance traduite notamment par les différentes normeseuropéennes dans ce domaine. Si chacun des protocoles cherche à mettre en œuvre dansleurs spécifications un certain nombre de mesures pour l’obtention d’une certainedisponibilité et fiabilité, ceci ne suffit pas pour une application sécuritaire donnée. Quelque soit le réseau choisi, la sécurité d’une telle application ne pourra être garantie qu’avec

Quelques mots sur la sûreté de fonctionnement dans le ferroviaire


l’implantation de procédures particulières au-dessus du protocole de transmission. Al’occasion des extensions des applications de communication aux communications train-infrastructure, on comprend également qu’une couche sécurité devra égalementsuperviser les échanges du nouveau système. Un réseau TCP/IP sécuritaire semble êtreen développement à l’occasion du projet européen [TrainCom_URL].

Figure 3 : architecture globale de communication train-infrastructure en étude [Adtranz 2001]

Conclusion

Afin de répondre aux besoins du groupe contrôle commande ferroviaire du« Programme national de REcherche et D’Innovation dans les Transports terrestres »(« groupe 4.4 : contrôle commande ferroviaire » du PREDIT 1996-2000), nous avonsprésenté ci-dessus un état de l’art des réseaux de communication embarqués au sein dematériels ferroviaires guidés. Des discussions préliminaires avec la SNCF ont permis derecenser les réseaux de communication d’intérêt. A partir de ces informations, unerecherche bibliographique a pu être menée. Elle a montré très peu voire pas d’informa-tions sur les réseaux propriétaires spécifiquement conçus pour le ferroviaire (liaisonMUX G, TORNAD, TORNAD*) et sur l’adaptation de réseaux du commerce aux besoinsdu ferroviaire (BITBUS, WorldFIP, CAN, LONWORKS). La décision d’étudier l’utilisationde PROFIBUS pour les applications embarquées sur matériels roulants est trop récentepour faire l’objet d’écrit public. Par contre, le protocole TCN fait l’objet de nombreusespublications dans diverses langues. Dans ces conditions, il était difficile d’effectuer uneétude de l’utilisation de ces réseaux dans les véhicules guidés. Nous avons alors choisi deréaliser une description progressive et transversale de chacun des réseaux, en privilégiantcelle des couches basses du modèle de référence hiérarchique OSI (Open SystemInterconnection) de l’ISO (International Standardization Organisation). La descriptiondes réseaux spécifiques au domaine ferroviaire nous a alors permis également d’introdui-re progressivement cette problématique.

Ainsi, dans le chapitre 1, nous avons introduit la problématique des réseaux de com-munication embarqués à bord des véhicules roulants guidés. Les applications candidatesau multiplexage et les différents « réseaux de communication ferroviaires » y ont été pré-sentés. Une des raisons du multiplexage a été la réduction de câble entre les véhiculesd’un train. Un des besoins exprimé est l’interconnexion possible de trains de paysd’origines différents. Ce chapitre a également montré un ensemble de réseaux d’originestrès variées et une implantation dans des matériels en relation avec leur origine et celle des matériels. Les réseaux déjà embarqués sont les réseaux dédiés « liaison MUX G »,TORNAD, TORNAD*, TCN et les réseaux non-dédiés du marché BITBUS, WorldFIP,CAN, LONWORKS. Malgré ce large éventail de réseau, c’est encore un autre réseau, leréseau PROFIBUS, qui a été choisi et est aujourd’hui à l’étude pour les applications decontrôle-commande ERTMS.

Le modèle de référence sur l’Interconnexion des Systèmes Ouverts (OSI en anglais)de l’Organisation Internationale de Standardisation (ISO en anglais) a été présenté dansle chapitre 2. Ce modèle a été créé entre 1977 et 1984 afin de répondre à l’impossibilitéd’interconnexion de différents réseaux de différents constructeurs. Le modèle de référen-ce IEEE 802 propre aux réseaux de communication locaux et dont les couches 1 et 2 sontgénéralement très développées a ensuite fait l’objet du paragraphe suivant. Enfin, aprèsun rappel des différentes méthodes d’interconnexion de réseaux, une comparaison desreprésentations des différents réseaux selon ce modèle de référence a alors été possible.Elle montre une grande hétérogénéité parmi les solutions retenues et met notamment


en valeur la difficulté d’une approche commune des problèmes de communication inter-systèmes. Les paragraphes sur les équipements d’interconnexion et l’hétérogénéitédes solutions technologiques retenues à ce jour montrent l’importance du développementde passerelles pour permettre l’interconnexion de ces solutions et donc de véhiculesferroviaires de pays d’origine différents.

Les chapitres 3 et 4 ont été l’occasion d’une étude des différentes couches physiquesde ces réseaux et de leur méthode d’accès.

Après un rappel sur les topologies des réseaux de communication locaux et des diffé-rents média de transmission, le chapitre 3 a mis en évidence une structure hiérarchique àdeux niveaux de bus. Cette hiérarchie repose sur la définition de plusieurs bus véhiculepour l’interconnexion d’équipements à bord de chaque véhicule et celle d’un bus trainpour l’interconnexion des véhicules. Ce bus assure une communication entre les diffé-rents bus véhicule du train. L’étude de la longueur des média filaires en cuivre et desdébits sur ces média pour chacun des réseaux a alors montré des valeurs de couples « longueur-débit » très différents. Ces différences proviennent de celles des caracté-ristiques physiques des média de transmission considérés par chacun des réseaux maiségalement des protocoles d’accès propres à ces réseaux.

Les méthodes d’accès au médium de communication ont alors été étudiées au cha-pitre 4. Les techniques utilisées par les réseaux considérés sont des techniques roundrobin ou des techniques de contention CSMA (CAN, LONWORKS). Parmi les techniquesround robin, on note d’une part la méthode de passage de jeton sur anneau (TORNAD)ou de jeton sur bus (TORNAD*, PROFIBUS, MVB) et celle de la scrutation (WorldFIP,MVB, WTB, PROFIBUS, BITBUS). Les méthodes de passage de jeton sur bus et descrutation sont souvent combinées. Outre les méthodes d’accès au médium de transmis-sion, les accès aux réseaux TCN et LONWORKS définis sur les sept couches du modèle deréférence OSI ont été considérés. Pour des applications temps critique ferroviaire, desréseaux de types scrutation qui définissent un trafic périodique pour les variables tempscritique et un trafic apériodique pour les autres variables ou des messages semblent êtreprivilégiés. Cette méthode est parfois associée à la technique du passage de jeton qui per-met une redondance du contrôleur maître du bus. Bien que les protocoles à accès aléa-toires CAN et LONWORKS ne définissent pas de trafics périodiques et apériodiques, lesexemples du protocole CANopen et de [Schweins et Heffernan 1998] ont montré l’exis-tence (CANopen) ou la faisabilité ([Schweins et Heffernan 1998]) d’une telle spécifica-tion au niveau de la couche application (protocole CANopen) ou de l’application utilisa-teur ([Schweins et Heffernan 1998]). La solution expérimentée pour le protocoleLONWORKS nécessite une adaptation matérielle. Le protocole CANopen est un exempled’une couche application pour le protocole CAN disponible dans le commerce.

Les systèmes ferroviaires étant soumis à de fortes perturbations électromagnétiques etmécaniques, le chapitre 5 a introduit la notion de sûreté de fonctionnement dans les sys-tèmes embarqués intégrant des réseaux de communication. Les principales normes ferro-viaires y ont été rappelées. Quelles que soient les mesures particulières prises dans lesprotocoles des réseaux de communication, les normes prEN 50159-1 et -2[NF_EN_50159-1 2001 ; NF_EN_50159-2 2001] imposent qu’une couche sécurité soitconstruite au-dessus du système de communication pour les applications de sécurité. La



sûreté de fonctionnement des systèmes ferroviaires intégrant des communications ne vacesser de prendre de l’importance avec l’extension des communications embarquées etdes échanges entre les installations embarquées et celles de l’infrastructure.

Nous conclurons enfin cette étude, en remarquant que, si les réseaux MUX G, TORNADet TORNAD* ne sont plus embarqués dans les nouveaux matériels ferroviaires, il estaujourd’hui très difficile de prévoire l’ensemble des solutions qui le seront sur les maté-riels à venir. L’existence de ces réseaux pourrait être plus liée à celle du développementdes passerelles adéquates qu’à celui des composants des réseaux qui, à l’exception duréseau TCN, sont des réseaux largement utilisés dans des applications d’automatisation.

Conclusion


Références bibliographiques

Abou, Malville (1997). – « Le Bus VAN – Vehicle Area Network – Fondements duprotocole », Bruno Abou et Joël Malville, Ed. Dunod, ISBN : 2-10-003160-0,166 pages.

Adtranz (2001). – Présentation de Adtranz (groupe Daimler Chrisler) sur le systèmeMITRAC, disponible sur www.tsd.org.

ALS_50414b-en (1998). – « WORLDFIP : design and installation Manual – ALS 50414b-en », Première version : mars 1993, version actuelle : mars 1998.

ANSI/EIA-709.1-A (1999). – « Control Network Protocol Specification », EIA-709.1-A,Revision de EIA-709.1 d’Avril 1999, Standard EIA (Electrical IndustriesAlliance), Approuvé le 22 octobre 1999.

Avery, Crawshaw (1984). – « Remote control of traction power over two wires », C.R. Avery et G. Crawshaw, IEE Proceedings, vol. 131, Pt. B, No. 4, juillet 1984.

Azevedo, Cravoisy (1998). – « WorldFIP protocol », J. De Azevedo (Version 1), N. Cravoisy (Version 2), 2 octobre 1998.

Berbineau et al. (1990). – « Les transmissions voie-machine dans les transportsterrestres », Marion Berbineau, Yves David et Marc Heddebaut, Rapport finalde convention DTT-INRETS, étude bibliographique (120 références Europe,Amérique du Nord, Japon), décembre 1990.

Berbineau (2001a). – « ESTUTEE – Etat de l’art et Synthèse Technique concernantl’Utilisation de systèmes de Télécommunication Existants ou Emergeants dans ledomaine des transports guidés », Marion Berbineau, Rapport de contrat PREDIT.

Berbineau (2001b). – « Synthèse INRETS n˚ 40 – Les systèmes de télécommunicationexistants ou émergeants et leur utilisation dans le domaine des transportsguidés », Marion Berbineau, Les Collections de l’INRETS, ISBN 2-85782-562-5, novembre 2001.

BEUG_URL. – « BITBUS European User Group », www.bitbus.org/.

Bosch (1991). – « CAN Specification – Version 2.0, Partie A et B », Robert BoschGmbH, Postfach 50, D-7000 Stuttgart 1, disponible sur www.can.bosch.com,33 pages, septembre 1991.

Boutonnet, Chateaureynaud (1989a). – « Le multiplexage et la télécommande deslocomotives à la SNCF », Jean-Claude Boutonnet, Michel Chateaureynaud,Chemin de Fer, n˚ 397, juillet/septembre 1989.

Boutonnet, Chateaureynaud (1989b). – « Multiplexing und Fernsteuerung vonLokomotiven bei des SNCF », Jean-Claude Boutonnet et MichelChateaureynaud, Hestra-Verlag – Darmstadt, ETR 38 (1989), H.5, p. 265-269,mai 1989.


Brisou (2002). – « Quelques notions sur le frein pneumatique AAR », Florent Brisou,http ://perso.wanadoo.fr/florent.brisou/Freinage%20AAR.htm, disponible le30.10.2002.

Brun et al. (1994). – « Les rames EUROSTAR », Daniel Brun, Marc Provoost et ClaudePujol, Revue Générale des Chemins de Fer, n˚ 2, pages 103 à 115, février 1994.

CAN_cia_URL. – Site web de CAN in Automation, URL : www.can-cia.de/.

CANappl (2000). – « CAN Application Fields », fichier « CANappl.pdf », 21 pages, surle site www.can-cia.de/ de CAN in Automation, page mise à jour le29 septembre 2000.

CANimpl (2000). – « CAN Implementations », fichier « CANimpl.pdf », 33 pages, sur lesite www.can-cia.de/ de CAN in Automation, page mise à jour le29 septembre 2000.

CANopen (2000). – « CiA CANopen », fichier « CANopen.pdf », 125 pages, sur le sitewww.can-cia.de/ de CAN in Automation, page mise à jour le 28 juillet 2000.

Carrere et al. (1994). – « Modification de locomotives pou la réversibilité V2N », Yves Carrere, Christian Martin, Hubert Granjon, Marcel Henriet, BernardMacor, Michel Tardivat et René Baton, Revue Générale des Chemins de Fer,n˚ 3, p. 5 à 21, mars 1994.

Chervet (1998). – « Network management in Rail Transit Applications Using LonWorksControl Networks », Alex Chervet, www.lonmark.org/solutiontrans/train5.pdf, 10 pages.

Ciame (1999). – « Réseaux de terrain – description et critères de choix », Groupe detravail CIAME – Instrumentation Intelligente et Sûreté de Fonctionnement,203 pages, ISBN 2-86601-724-2, Ed. Hermes, Paris, janvier 1999.

CISCO_URL. (1992-2001). – « Internetworking Technology Overview », Documentaiondisponible sur www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/,copyright Cisco Systems, INC.

Corradi et al. (1996). – « IEC TC9 WG22 Train Communication Networks Conformanceand Interoperability Concepts. A Proposal of a Test Bed », G. Corradi ;G. Fadin ; G. Cau ; A. De Curtis, Proceedings 16th conference on TransportSystems Automation in Transportation’96, p. 92-95, Split, Croatia, 27-29novembre 1996.

Dang, Wahl (1994). – « Rapport d’expertise sur les notions d’identificateur et d’arbitragebit à bit », Michel Dang et Martine Wahl, Etude faite sur demande de PSA,Laboratoire LGI/IMAG, 4 pages, 22 juin 1994.

Deufrako (1993). – Fachwörterbuch Schnellbahnen, Technical Dictionary of High-speedGuided Transport, Dictionnaire Technique des Transports Guidés à GrandeVitesse, DEUFRAKO, Dornier GmbH & INRETS-Arcueil.

DeLinares, VanCaeyseele (1989). – « Equipements de communication – Micropanoraman˚ 53 », Bénédicte de Linares et Alain Van Caeyseele, Minis & Micros n˚ 320,17 avril 1989.



Desgeorge (2000). – « Le journal des réseaux », Guillaume Desgeorgewww.guill.net/reseaux/index.html.

Desodt (1997). – « Fiche Technique : chapitre 1 couche physique », Philippe Desodt,CiMax : édition Terrain, n˚ 14, p. 19-22, septembre-octobre-novembre 1997.

Dohen (1985). – « Le métro de San Francisco », Hervé Dohen, Revue Générale desChemins de Fer, n˚ 12, pages 657 à 662, décembre 1985.

Duhot (1989). – « Le réseau informatique ferroviaire TORNAD », Denis Duhot, RevueRTS (Recherche Transport Sécurité), n˚ 22, Dunod, juin 1989.

Duquesnoy, Kieken (1986). – « Microprocesseurs et automatismes sur les rames du TGVAtlantique », J.-N. Duquesnoy et J.-P. Kieken, Revue Générale des Cheminsde Fer – 105e année, vol. 105, n˚ 12, p. 719-730.

EB161 (1993). – « LONTALKTM Protocol », LONWORKSõ Engineering Bulletin, EchelonPart Number 005-0017-01 REV C, EB 161, p. EB-117 à EB-143, avril 1993.

Echelon (1997). – « LONWORKS FFT-10A Free Topology Transceiver user’s Guide »,Echelon corporation, www.echelon.com/Products/technical/pdf/manuals/fft10ard.pdf, 63 pages.

Echelon_URL. – www.echelon.com/.

Echelon (1999). – « Interoperable Networked Control for Rail Transit Systems withLONWORKS Technology », www.echelon.com/Solutions/Markets/trans/rail.htm, Echelon Corporation, 26 pages.

ElKoursi et al. (1998). – « Certification des automatismes numériques dans les transportsguidés : projets européens CASCADE et ACRuDA », El Miloudi El Koursi,Philippe Meganck, Bao Le Trung, Swapan Mitra, Henrich Krebs, RechercheTransports Sécurité, n˚ 60, p. 54-66, juillet-septembre 1998.

ELZET_80_URL. – « ELZET 80 MIKROCOMPUTER », « BITBUS Installation »,http ://www.elzet80.com/bitbusinst.htm

EN_50170_1 :3 (1996). – European Standard EN 50170, FieldBus, Volume 1 : P-Net,Volume 2 : PROFIBUS, Volume 3 : WorldFIP, CENELEC, décembre 1996.

EN_50170_2 (1996). – « European Standard EN 50170, FieldBus », Volume 2 :PROFIBUS, CENELEC, décembre 1996.

ERTMS_URL. – www.ertms.com.

EuroDicAutom_1. – « 1) Interconnexion de systèmes ouverts, 2) OSI » ; Terminologyand Computer Applications, European Commission ; Réf. : NF Z 70-001(1, 2, DF) et Dict. du multimédia, AFNOR, 1994 (1, 2, NT) ; Recherchesur EuroDicAutom : europa.eu.int/eurodicautom/login.jsp.

EuroDicAutom_2. – « Interconnexion des systèmes ouverts », Terminology Office,European Commission, Luxembourg ; Réf. : CCITT, Livre rouge, Rec. I.112 ;Recherche sur EuroDicAutom : europa.eu.int/eurodicautom/login.jsp.

EuroDicAutom_3. – « protocole(N) » ; Terminology Office, European Commission,Luxembourg ; Réf. : CCITT, Livre bleu, X.200 ; Recherche surEuroDicAutom : europa.eu.int/eurodicautom/login.jsp.



EuroDicAutom_4 – « maintenabilité » ; Terminology and Computer Applications,European Commission ; Réf. : Z 61-000, décembre 1980, Vocabulaireinternational de l’informatique ; Recherche sur EuroDicAutom :europa.eu.int/eurodicautom/login.jsp.

Fabri et al. (1999). – « Use of the Internet for remote train monitoring and control : theROSIN project », A. Fabri, T. Nieva, P. Umiliacchi, Rail Technology’99,Londre, septembre 1999.

FIP (1984). – « Livre blanc FIP », première version provisoire du sous-groupe FIP dugroupe de travail « Réseau Locaux Industriels » réalisée par Messieurs Cour,Dang, Duby, Galara, Le Gallais, Peinturier, Powell, Taillebois, Thomesse,46 pages.

Furrer (1998). – « BITBUS Fibre Optique Media Specification – ABEUGRecommandation », Frank J. Furrer, 8 pages, July 21.

GESPAC_URL. – « FILBUS, BITBUS, WorldFIP, Profibus and CAN Fieldbuscomparison tables », http ://www.gespac.ch/htmpl/fieldbus_select.html,imprimé le 5/01/2001.

Grasso et al. (2001). – « Description of the FEBIS wire protocol », Angelo Grasso,Ouzounis Dionisios, Stefan Witte, Alain Launay, World Congress on RailwayResearch (WCRR), Cologne, novembre 2001.

Heffernan (1997). – « A Technical Overview of Fieldbus Developments from Origins toPresent Day Standards », Donal Heffernan, Keynote Adress ETCI Conference,Dublin, Ireland, 8 octobre 1997.

Hirao, Watanabe (1998). – « Safety Guidelines for Computerised Train Control andProtection Systems », Yuji Hirao, Ikuo Watanabe, Quaterly report of RTRI,vol. 39, No. 4, p. 186-190, Décembre 1998.

I2c_URL. – Philips Semiconductors – I2C-bus ; About the I2C-bus,http ://www.semiconductors.philips.com/i2c/facts/.

IEC_TCN_URL. (1999). – TCN Technology, http ://www.iec-tcn.org/technology.html,dernier changement : 26 septembre 1999, Markus Strässler, Andreas Fabri.

IEC_URL. – « International Electrotechnical Commission », http ://www.iec.ch/.

IEEE_1473 (1999). – « 1473-1999 IEEE Standard for Communications Protocol AboardTrains », 20 pages, ISBN : 0-7381-1648-3.

IEEE_Std_802 (1990). – « IEEE Standards for Local and Metropolitan Area Network :Overview and Architecture », Sponsor Technical Comittee on ComputerCommunications of the IEEE Computer Society, ISBN : 1-55937-052-1,approuvé le 31 mai 1990.

ISO 11519-1 :4 (1994). – « Road vehicles – Low-speed serial data communication »,« Part 1 : General and definitions », 4 pages, 1994 ; « Part 2 : Low-speedcontroller area network (CAN) », 52 pages, 1994 ; « Part 3 : Vehicle areanetwork (VAN) », 104 pages, 1994 ; « Part 4 : Class B data communicationnetwork interface (J1850) ».



ISO_11898 (1993-1995). – « ISO 11898 1993 : Road vehicles – Interchange of digital information – Controller area network (CAN) for high-speed communication », 58 pages, « ISO 11898 : 1993/Amd 1 : 1995 »,9 pages.

IXXAT_URL. (2003). – pages « Overview of actual CAN Chips », « CANopen –Introduction » et CANopen Protocol Software » sur le site www.ixxat.com,juin 2003.

Julien et al. (1994). – « Les wagons des navettes tourisme LE SHUTTLE », Louis Julien,Yves Machefer Tassin et Daniel Wallet, Revue Générale des Chemins de Fer,n˚ 2, février, p. 71 à 91.

Kirrmann, Zuber (0000). – « The IEC/IEEE Train Communication Network », HubertKirrmann (ABB Corporate Research) et Pierre A. Zuber (Adtranz), 14 pages,disponible sur tsd.org/wg1, 14 pages.

Lagrange, Seret (1998). – « Introduction aux réseaux », Xavier Lagrange et DominiqueSeret, 361 pages, ISBN 2-86601-698-X, Ed. Hermes (Collection pédagogiquede télécommunication), Paris.

Linux_URL. – www.linux-france.org/prj/jargonf/P/ paire_torsadeacutee.html.

Lonmark_URL. – « LonMark Interoperability Association’s website »,www.lonmark.org/

Lorin (1995). – « LONWORKS (Local Operating Network) », G. Lorin, CiMax : EditionTerrain, n˚ 3, p. 15-17, mars-avril.

Lozac’h et al. (1998). – « Etude d’une commande électronique de frein et d’un systèmede communication embarqué pour le Fret – Cahier des charges fonctionnel »,Jean-Philippe Lozac’h, Alain Bonnet, Dietmar Gralla, Marc Guigon, CarstenDorn, Référence du rapport SN.FR.CC.001.A, SNCF et Deutsche Bahn,confidentiel, 36 pages, 7 mai.

Machefer, Tassin, Julien (1994). – « Les locomotives électriques des navettes », YvesMachefer Tassin, Louis Julien, Revue Générale des Chemins de Fer, n˚ 2,p. 41-60, février.

Mackenzi, Bettaz (1988). – « La communication dans les réseaux d’ordinateurs –principes et exigences (Cours sur les réseaux d’ordinateurs) », LewisM. Mackenzie et Mohamed Bettaz, Office des publications universitaires,1, place centrale de Ben-Aknoun (Alger), 164 pages.

Madec E7430. – « Transmission numérique sur câble à paires métalliques », YvonMadec, Techniques de l’Ingénieur, Traité Electronique, 19 pages, référenceE7430.

McGean (1999). – « Communications Protocol Interface Proposal » preparée par TomMcGean, www.tsd.org/rsc/CPIProposal.doc (TSD – Transportation SystemDesign Inc.), 5 pages.

Menoux (1993). – « Les voitures à deux niveaux V2N », Jean Menoux, Revue Généraledes Chemins de Fer – 112e année, n˚ 1, p. 13-20, janvier.



Misic (1999). – « COMP 361 Computer Communication Networks – Spring 1999 »,Jelena MISIC (Professeur Assistant de l’Université de Belgrade), coursdisponible sur www.cs.ust.hk/faculty/jmisic/comp361/comp361.html.

MOTOROLA_LonWorks. –« LonTalk Protocol », MOTOROLA LonWorks Technology,MC143150-MC143120 Section 8, p. 8-1 à 8-6.

NF_EN_50126 (2000). – « Applications ferroviaires – Spécification et démonstration dela fiabilité, de la disponibilité, de la maintenabilité et de la sécurité (FDMS) »,indice de classement F00-126, NF EN 50126 : 2000 : version française deEN 50126 : 1999, norme CENELEC, 80 pages, janvier 2000.

NF_EN_50128 (2001). – « Applications ferroviaires – Systèmes de signalisation, detélécommunication et de traitement – Logiciels pour systèmes de commandeet de protection ferroviaire », indice de classement F74-128, NF EN 50128 :2001, version française de EN 50128 : 1991, norme CENELEC, 109 pages,juillet 2001.

NF_EN_50159-1 (2001). – « Applications ferroviaires – Systèmes de signalisation, detélécommunication et de traitement – Partie 1 : Communication de sécurité surdes systèmes de transmission fermés », indice de classement F74-159-1, versionfrançaise de EN_50159-1 : 2001, norme CENELEC, 16 pages, août 2001.

NF_EN_50159-2 (2001). – « Applications ferroviaires – Systèmes de signalisation, detélécommunication et de traitement – Partie 2 : Communication de sécurité surdes systèmes de transmission ouverts », indice de classement F74-159-2,version française de EN_50159-2 : 2001, norme CENELEC, 46 pages,septembre 2001.

Nicolas (2000). – « Cours de réseaux en Maîtrise d’informatique de Universitéd’Angers », Pascal Nicolas, U.F.R. Sciences de l’Université d’Angers, Web :www.info.univ-angers.fr/pub/pn, 2000.

Obracza et al. (2000). – « EE450 – Introduction to computer Networks », KatiaObraczka, Junsoo Lee, Kenneth Shum, Rajeev Shah, www-classes.usc.edu/engr/ee-s/450o/,University of Southern California (USC),printemps.

Paret (1996). – « Le bus CAN – Controller Area Network », Dominique Paret, 277 pages,ISBN 2-10-003164-3, Ed. Dunod (Collection Réseaux Locaux), Paris.

Poitevin (2000). – « Sécurité des réseaux informatiques embarqués dans le ferroviare »,Jean-Pierre Poitevin, Rapport de stage n˚ INRETS/RE-00-700-FR, 7 février.

Profibus (1997). – « PROFIBUS, Manuel Technique », PROFIBUS Brochure, n˚ 4.002-FR, édité par PROFIBUS Nutzerorganisation e.V., Haid-und-Neu-Str. 7, D-76 131 Karlsruhe, 32 pages, avril.

Profibus (1999). – « PROFIBUS, Manuel Technique », PROFIBUS Brochure, n˚ 4.002-FR, 35 pages, septembre.

Profibus (2002). – « Théorie et pratique de la technologie PROFIBUS, ManuelTechnique », PROFIBUS Brochure, n˚ 4.003-FR, 40 pages, octobre.

PROFIBUS_URL. – http ://www.profibus. com/.



Rolin (1990). – « Réseaux locaux – normes et protocoles », Pierre Rolin, 3e édition revueet augmentée, 581 pages, ISBN 2-86601-234-8, Ed. Hermes (Traité desNouvelles Technologies – série Automatique), Paris.

Rolin (1999). – « Réseaux haut débit », Pierre Rolin, 2e édition revue et augmentée,718 pages, ISBN 2-7462-0001-5, Ed. Hermes (Réseaux et télécommunication),Paris.

ROSIN (2001). – « TCN Standard », www.labs.it/rosin/gistanda.htm.

ROSIN_URLa. – « Railway Open System Interconnection Network »,http ://www.labs.it/rosin/.

ROSIN_URLb. – « TCN Tutorial », www.labs.it/rosin/tcncorso/tutindex.htm.

ROSIN_URLc. – « TCN on existing UIC cable : Objectives », www.labs.it/-rosin/trobject.htm.

ROSIN_URLd. – « Projects in progress », www.labs.it/rosin/gistanda.htm.

SAE_J1213/1 (1991). – « Glossary of vehicle networks for multiplexing and datacommunications – SAE J1213/1 JUN91 », SAE Information Report dans vol. ,p. 23.01-23.12 de SAE Handbook 1997, juin.

SAE_J1850 (1995). – « Class B Data Communications Network Interface – SAEJ1850 », SAE Standard dans vol. 2, p. 23.388-23.405 de SAE Handbook 1997,juillet.

SAE_URL. – « Society of Automotive Engineers », www.sae.org/.

Sauvestre (1993). – « Utilisation d’automates programmables pour la rénovation deslocomotives BB9600 », Jean Sauvestre, Revue Générale des Chemins de Fer,n˚ 5, p. 27 à 37, mai.

Scheinder, Vitins (1996). – « Micas-S2 traction control for motive power units », HeinzScheinder et Dr Janis Vitins, ABB Daimler Benz Transportation (Switzerland)ltd (Zurich), 12 pages.

Schickhuber, Mc Carthy (1997a). – « Distributed Fieldbus and Control NetworksSystems », Gerald Schickhuber et Olivier Mc Carthy, IEE Computing andControl Engineering Journal, février.

Schickhuber, Mc Carthy (1997b). – « Distributed Fieldbus and Control NetworksSystems », Gerald Schickhuber et Olivier Mc Carthy, LonUsers InternationalProceedings, Santa Clara, USA, mai.

Schweins, Heffernan (1998). – « Retrofitting a Deterministic Access Control Policy to aNon-deterministic Control Network », Hubertus Schweins et Donal Heffernan,Irish Signal and Systems Conference, Dublin, juin.

Selectron (1999). – « The control system for mobile automation – SELECONTROLMAS Traffic »,Classeur Sélectron Transport, SIG Positec Selectron, édition,mai.

Siemens (1999). – « PROFIBUS DP », Diaporama de Siemens, Chapitre 2,http ://www.profibus. com/ ; 11 avril.



SNCF (1999). – « Nouveaux concepts de trains Fret », recherche.sncf.fr/

Sullivan (1998). – « A Revolution in serial trainline communications » Tom Sullivan,disponible sur www.lonmark.org/solution/trans/arevolut.htm, ô 1999LonMark Interoperability Association ; Railway Age : p. 63-74, Aug..

Summers (2000). – « Communications and Systems Software – Lecture notes », WayneSummers, www.cs.waikato.ac.nz/~312/lectures/.

Tanenbaum (1997). – « Réseaux », Andrew Tanenbaum, Texte français de Jean-AlainHernandez et René Joly, (version originale anglaise « Computer Networks »publiée en 1996 par Prentice Hall), 3e édition, 792 pages, ISBN 2-7296-0643-2, Ed. InterEditions – Paris et Prentice Hall International – London.

TCNspecifications (1998). – « TCN Specifications » (Train Communication Protocol),version avant normalisation IEC 61375-1 disponible en 1998 sur le sitewww.labs.it/rosin/tcnstand/, version de septembre 1998.

Thomesse (1998). – « A review of the fieldbuses », Jean Pierre Thomesse, AnnualReviews in Control 22 (1998), p. 35-45.

Thomesse (1999). – « Histoire, état de l’art et perspectives des réseaux de terrain », JeanPierre Thomesse, Colloque Européen sur les Réseaux de Capteurs etcommunications de l’association PROCAP, p. 7-22, INNOCAP 99, Grenoble,28-29 avril.

Thomesse_R7574. – « Réseaux locaux industriels – Typologie et caractéristiques », Jean-Pierre Thomesse, Techniques de l’Ingénieur, Traité Mesures et Contrôle,Référence R7574, 15 pages.

Tione (2001). – « Test bench in Piossasco for the FEBIS-development », Roberto Tione,World Congress on Railway Research (WCRR), Cologne, novembre 2001.

Toutain (1999). – « Réseaux locaux et Internet : des protocoles à l’interconnexion »,Laurent Toutain, 2e édition revue et augmentée, 733 pages, ISBN 2-7462-0000-7, Paris, Hermès Science Publications, janvier.

TrainCom_URL. – « Train-ground communication infrastructure », projet européenn˚ IST-1999-20096, date de début : 1/12/2000, www.traincom.org/.

TSD_URL. – « TSD’s Rail Standards Page, Transportation Systems Design, EmergingStandards », Inc., http ://www.tsd.org/standards/index.htm.

UIC556. – « Projet de fiche UIC 556, Transmission d’information dans le train – bus detrain », Union Internationale des Chemins de fer (Paris).

UIC558 (1996). – « Fiche UIC 558 : Ligne de télécommande et d’information –Caractéristiques techniques unifiées pour l’équipement des voitures RIC »,Union Internationale des Chemins de fer UIC (Paris), 35 pages, janvier.

UIC568 (1996). – « Fiche UIC 568 : Sonorisation et téléphone des voitures RIC –Caractéristiques techniques pour l’équipement des voitures RIC unifiées »,Union Internationale des Chemins de fer (Paris), 25 pages, janvier.

VAN (1989). – « Projet de norme VAN – ISO/TC22/SC3/WG1 », France, Version du31 octobre présentée à Tokyo.



VAN_URL. – « Vehicle Area Network », www.van-mux.org.

Wahl (1999). – « Réseaux de terrain embarqués et problématique ferroviaire », MartineWahl, Acte de la Conférence CAPTEURS du 6 octobre 1999 intitulée « Sûretéde fonctionnement et Réseaux de terrain « , dans le cadre de la Semaine del’Electronique et de la Physique 1999 (SEP 1999), Parc des Expositions, Paris,6 octobre.

Witte (1998). – « CAN in Güterzügen ; Feldbus-Technik – grundstock derAutomatisiereung in der Bahntechnik », Stefan Witte, Elektronik, vol. 47,n˚ 20, p. 86-93.

Witte et al. (2001). – « FEBIS system aspects », Stefan Witte, Alain Launay, RobertoTione, Christian Coulange, World Congress on Railway Research (WCRR),Cologne, novembre 2001.

WorldFIP_News (1995). – « WorldFIP News », Issue 7 : sept. 1995, disponible surwww.worldfip.org/, septembre.

WorldFIP_News (1999). – « WorldFIP News », Issue 23 : sept. 1999, disponible surwww.worldfip.org/, septembre.

WorldFIP_URL. – www.worldfip.org/.

XP_ENV_50129 (1999). – « Applications ferroviaires – Systèmes électroniques desécurité pour la signalisation », indice de classement F74-129, XP ENV 501291999,version française de la prénorme CENELEC, 128 pages, décembre.

Yoon (1998). – « CS440 Data Communication Classnote », Prof. Hyunsoo Yoon,disponible sur http ://camars.kaist.ac.kr/~hyoon/courses/cs440/note_index.html.



Imprimé en France - Jouve, 11, bd Sébastopol 75001 PARISN° 332735T - Dépôt légal : Février 2004

Documents

L Martine WAHL - ifsttar.fr · fret en 1990 et Tornad dans le TGV A et ... synthesis relating to the use of wire communication networks on-board guided ... 1.2 Evolution des topologies