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 Prix : 15,24 €

a nécessité de réduire l’espace occupé par Martine WAHL L le câblage des équipements embarqués dans les transports guidés a motivé le passage de techniques de câblage filaire et parallèle à l’utilisation de réseau de terrain. Un réseau local de communication peut ainsi remplacer une centaine de lignes de commande parcourant le train. Différentes technologies ont été testées, certaines spécifiquement conçues pour les trains (Mux G, Tornad, Tornad* et TCN – LES RÉSEAUX DE TERRAIN EMBARQUÉS MVB et WTB), d’autres adaptées de solutions du marché (CAN, LONWORKS, Bitbus, DANS LES TRANSPORTS GUIDÉS WorldFip, Profibus). Cet ouvrage fait état des applications concer- nées par une mise en réseau à l’intérieur des transports guidés et présente les protocoles des réseaux de terrain mis en œuvre.

Synthèse INRETS n°45

Janvier 2004 GUIDÉS TRANSPORTS TERRAIN EMBARQUÉS DANS LES LES RÉSEAUX DE Prix : 15,24 € Martine WAHL est Chargée de Recherche au Laboratoire Electronique, 5 ° 4 Ondes et Signaux pour les Transports N (INRETS-LEOST). E S

Y S

ISSN 0769-0274 ISBN 2-85782-591-9 Synthèse INRETS n°45 LES COLLECTIONS DE L’INRETS Conformément à la note du 04/07/2014 de la direction générale de l'Ifsttar précisant la politique de diffusion des ouvrages parus dans les collections éditées par l'Institut, la reproduction de cet ouvrage est autorisée selon les termes de la licence CC BY-NC-ND. Cette licence autorise la redistribution non commerciale de copies identiques à l’original. Dans ce cadre, cet ouvrage peut être copié, distribué et communiqué par tous moyens et sous tous formats.

Attribution — Vous devez créditer l'Oeuvre et intégrer un lien vers la licence. Vous devez indiquer ces informations par tous les moyens possibles mais vous ne pouvez pas suggérer que l'Ifsttar vous soutient 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 cette Oeuvre, tout ou partie du matériel la composant. (CC BY-NC-ND 4.0) Pas de modifications — Dans le cas où vous effectuez une adaptation, que vous transformez, ou créez à partir du matériel composant l'Oeuvre originale (par exemple, une traduction, etc.), vous n'ê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 du savoir et pour contribuer à l'innovation et au développement socio-économique. Pour que les résultats des recherches soient plus largement diffusés, lus et utilisés pour de nouveaux travaux, l’Ifsttar a entrepris la numérisation et la mise en ligne de son fonds documentaire. Ainsi, en complément des ouvrages disponibles à la vente, certaines références des collections de l'INRETS et du LCPC sont dès à présent mises à disposition en téléchargement gratuit selon les termes de la licence Creative Commons CC BY-NC-ND.

Le service Politique éditoriale scientifique et technique de l'Ifsttar diffuse différentes collections qui sont le 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 Transports 14-20 Boulevard Newton, Cité Descartes, Champs sur Marne F-77447 Marne la Vallée Cedex 2 Contact : [email protected] Martine WAHL

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

Synthèse n˚ 45 Juillet 2003 L’auteur : Martine Wahl, Chargée de Recherche à l’INRETS-LEOST [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 Cedex Té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 Polytechnique de Grenoble, Directeur de l’Ecole Supérieure d’Ingénieurs en Systèmes industriels Avancés Rhône-Alpes (INPG-ESISAR) ; – Marion Berbineau, Directrice de Recherche à l’Institut National de Recherche sur les Transports et leur Sécurité, Directrice du Laboratoire Electronique Ondes et Signaux pour les Transports (INRETS-LEOST) ; – Alain Launay, SNCF, Division Informatique Embarquée de la Direction du Matériel et de la Traction ; – Jean-Philippe Lozac’h, SNCF, unité de recherche « Activité Fret » de la Direction 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-Joinville 94114 ARCUEIL CEDEX Tél. : 33 (0)1 47 40 70 74 – Fax : 01 45 47 56 06 www.inrets.fr

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

UR (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 – 9935 PREDIT 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 de techniques conventionnelles de câblage filaire et parallèle à l’utilisation de réseau de terrain. Le domaine des systèmes embarqués sur les matériels ferroviaires roulants ne fait pas exception à la règle. Les réseaux de terrain introduits peuvent remplacer une centaine de fils parcourant l’ensemble du train. En France, les premières solutions embarquées étaient dédiées (Mux G dans les locomotives de trains de fret en 1990 et Tornad dans le TGV A et 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 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 travail en unité multiple des locomotives. Les applications candidates au multiplexage ont alors augmenté avec l’expérience des technologies des réseaux de terrain. Ainsi, à une époque où les constructeurs ferroviaires 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 2 a souhaité l’entreprise et la diffusion d’un travail de bibliographie et de synthèse relatif à l’utilisation des réseaux de communication filaires embarqués dans le domaine des transports guidés. Cet ouvrage rend public les résultats de cette étude PREDIT ATUTEG. Il présente les applications candidates au multiplexage 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 ».

Synthèse INRETS n° 45 3 Publication data form

UR (1st author) Projet N° INRETS synthesis N˚ 45 Laboratoire Electronique Ondes et CNS-2T Signaux 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 – 9935 PREDIT 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 conventional parallel wire techniques to the use of fieldbus technologies. This is also true for the systems embedded into 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, and Tornad in the TGV A and the D-line of the Magaly subway in Lyon, 1988). Since then, several solutions have been tested. Some have been designed for trains (Mux G, Tornad, Tornad*, or TCN - MVB and WTB). Others have been adapted from standard technologies (CAN, LONWORKS, Bitbus, WorldFip, or Profibus). 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 be multiplexed. Thus, at a time when railway manufacturers are interested in the multiplexing of braking equipment (ECP brake –Electronically Controlled Pneumatic brake), the “4.4” railway control-command group of the PREDIT2 organization wished to make available the result of this work of bibliography and synthesis relating to the use of wire communication networks on-board guided transport. This publication makes public the results of this “PREDIT ATUTEG” study. It presents the applications which can be multiplexed 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

4 Synthèse INRETS n° 45 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 ? 25 2. Les applications embarquées dans les matériels ferroviaires roulants 26 3. Quelques réseaux embarqués ou candidats au multiplexage 30 3.1 Exemples de réseaux embarqués 30 3.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 41 2. Modèle de référence IEEE 802 pour les réseaux locaux 45 3. Equipements d’interconnexion pour les réseaux locaux 48 4. Décomposition en couches OSI des réseaux de communication « ferroviaires » 49 4.1 Observation générale 49 4.2 Réseau TORNAD 50 4.3 Réseaux CAN et CANopen 51 4.4 Réseau LonWorks 57 4.5 Réseau WorldFIP 58 4.6 Réseau TCN 61 4.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 65 1.1 Topologie des réseaux de communication locaux 65

Synthèse INRETS n° 45 5 Les réseaux de terrain embarqués dans les transports guidés

1.2 Evolution des topologies des réseaux embarqués sur des matériels guidés ferroviaires 69 2. Supports de transmission filaires 72 2.1 Introduction 72 2.2 Le cuivre 72 2.3 La fibre optique 74 2.4 Autres média 75 3. Techniques de transmission et de codage des informations 75 3.1 Introduction 75 3.2 Méthodes de synchronisation entre deux équipements terminaux 76 3.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 86 4.2 Supports de transmission et codage de l’information prévus par les réseaux 87 4.3 Conclusion 103

Chapitre 4 : Méthodes d’accès au médium de communication et trames de données 105 1. Introduction 105 2. Accès par passage de jeton (token) 107 2.1 Introduction sur les protocoles IEEE 802.4 et 802.5 107 2.2 Protocole d’accès aux réseaux TORNAD et TORNAD* 110 2.3 Autres réseaux : les bus MVB et PROFIBUS 113 3. Accès par scrutation (polling) 113 3.1 Introduction 113 3.2 Protocole des bus WorldFIP, MVB et WTB 115 3.3 Protocole du réseau PROFIBUS 140 3.4 Protocole du réseau BITBUS 144 4. Accès par compétition (contention, CSMA) 145 4.1 Introduction : le protocole IEEE 802.3 145 4.2 Protocole d’accès au bus CAN 146 4.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

6 Synthèse INRETS n° 45 Table des matières

2. Normes relatives à la sûreté de fonctionnement des applications ferroviaires 163 3. Normes relatives aux communications embarquées 164 4. Maintenabilité d’un système 165 5. Conclusion 166

Conclusion 169

Références Bibliographiques 173

Synthèse INRETS n° 45 7

Table des illustrations

Table des figures

Chapitre 1 : Figure 1 : représentation simplifiée d’un réseau de communication [Summers 2000] ...... 26 Chapitre 2 : Figure 1 : les sept couches du modèle de référence OSI ...... 42 Figure 2 : la communication entre couches OSI ...... 42 Figure 3 : taille relative des informations manipulées par chacune des sept couches du modèle OSI [Rolin 1990] ...... 43 Figure 4 : décomposition de la couche liaison de données selon le modèle de référence IEEE 802 ...... 46 Figure 5 : les groupes de travail IEEE 802 d’après [IEEE_Std_802 1990] ...... 48 Figure 6 : représentation des couches OSI des « réseaux embarqués ferroviaires » 49 Figure 7 : couches OSI et réseau TORNAD [Duhot 1989] ...... 51 Figure 8 : organisation du protocole CAN selon le modèle ISO d’après [Paret 1996 ; CANimpl 2000] ...... 52 Figure 9 : architecture d’un composant CAN [CANimpl 2000] ...... 53 Figure 10 : différentes architectures de nœud CAN [Philips 1995] ...... 54 Figure 11 : modèle de référence CANopen [CANopen 2000] ...... 56 Figure 12 : profil CANOpen [IXXAT_URL] ...... 56 Figure 13 : architecture du réseau de communication LONWORKS d’après [MOTOROLA_LonWorks] ...... 57 Figure 14 : exemple d’architecture d’un « Neuron chip » ...... 58 Figure 15 : le protocole WorldFIP [Azevedo & Cravoisy 1998 ; WorldFIP_URL] . 58 Figure 16 : exemple d’architecture d’un nœud WorldFIP avec FULLFIP2 (source : « FIPWARE : ALSTOM technology for WorldFIP » ) ...... 60 Figure 17 : exemple d’architecture d’un nœud WorldFIP avec MICROFIP (source : « FIPWARE : ALSTOM technology for WorldFIP » ) ...... 60 Figure 18 : couches du réseau TCN [TCNspecifications 1998] ...... 61 Figure 19 : architecture de communication de PROFIBUS d’après [Profibus 1997] ...... 62 Figure 20 : architecture de communication de PROFIBUS d’après [Profibus 1999] ...... 63 Figure 21 : architecture de communication de PROFIBUS d’après [EN_50170_2 1996] ...... 64

Synthèse INRETS n° 45 9 Les réseaux de terrain embarqués dans les transports guidés

Chapitre 3 : Figure 1 : exemple de topologies multipoints et point à point ...... 66 Figure 2 : jonction de deux segments de bus par un répéteur ...... 67 Figure 3 : état possible du coupleur dans une topologie anneau ...... 68 Figure 4 : le réseau Tornad d’Alstom [Duquesnoy & Kieken 1986] ...... 69 Figure 5 : notion de bus train et bus véhicule ...... 70 Figure 6 : exemple d’utilisation d’un bus train et d’un bus véhicule WorldFIP d’après [WorldFIP_News 1995 ; 1999] ...... 70 Figure 7 : configuration du réseau TCN d’après [Corradi & al 1996 ; ROSIN_URLa] ...... 71 Figure 8 : exemple de configuration du réseau LONWORKS d’après [Chervet 1998] ...... 71 Figure 9 : gamme de fonctionnement des média dans le spectre électromagnétique d’après [Summers 2000] ...... 73 Figure 10 : techniques de connexion d’un nœud à une fibre optique ...... 75 Figure 11 : représentation d’un système de transmission de données [Lagrange & Seret 1998 ; Mackenzie & Bettaz 1988] ...... 76 Figure 12 : technique de transmission asynchrone ...... 77 Figure 13 : technique de transmission synchrone ...... 78 Figure 14 : codage de données digitales dans le cas d’une transmission analogique [Summers 2000] ...... 80 Figure 15 : codage de données analogiques dans le cas d’une transmission analogique [Summers 2000] ...... 80 Figure 16 : codage NRZ et NRZI ...... 82 Figure 17 : codage HDB3 [Madec E7430 ; Duhot 1989] ...... 83 Figure 18 : codage Manchester et Manchester différentiel ...... 84 Figure 19 : transmission bidirectionnelle en bande de base sur un médium cuivre en topologie bus [Yoon 1998] ...... 85 Figure 20 : transmission unidirectionnelle en large bande sur un médium cuivre en topologie bus [Yoon 1998] ...... 85 Figure 21 : câble UIC 568 et câble UIC 558 utilisé pour le bus train de TCN [IEC_TCN_URL] ...... 87 Figure 22 : principe de la télécommande par multiplexage (emprunté à [Boutonnet & Chateaureynaud 1989a]) ...... 88 Figure 23 : codage des données de la liaison MUX G [Boutonnet & Chateaureynaud 1989a]...... 89 Figure 24 : bus train WTB et bus véhicule MVB [Kirrmann & Zuber] ...... 91 Figure 25 : partie de l’unité MAU (Medium Attachment Unit) connectée à la ligne A du bus train ...... 92 Figure 26 : codage des éléments binaires du réseau WorldFIP ...... 95 Figure 27 : exemple de relais utilisé avec un bus train et bus véhicule en technologie CAN (source [Witte 1998]) ...... 98

10 Synthèse INRETS n° 45 Table des illustrations

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] ...... 101 Chapitre 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

Synthèse INRETS n° 45 11 Les réseaux de terrain embarqués dans les transports guidés

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édictif p-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

12 Synthèse INRETS n° 45 Table des illustrations

Chapitre 5 : Figure 1 : les références ferroviaires concernant la sécurité dans le ferroviaire [XP_ENV_50129 1999] ...... 164 Figure 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

Synthèse INRETS n° 45 13

Table des tableaux

Chapitre 1 : Tableau 1 : matériels équipés des réseaux TORNAD et CAN [Poitevin 2000 ; Duhot 1989] ...... 31 Tableau 2 : matériels équipés du réseau TORNAD* [Poitevin 2000] ...... 32 Tableau 3 : matériels équipés du réseau TCN ou MICAS-S2 [Poitevin 2000] . . . . . 32 Tableau 4 : matériels équipés du réseau Intel BITBUS [Poitevin 2000] ...... 33 Tableau 5 : utilisation d’un réseau WorldFIP dans des applications ferroviaires d’après [WorldFIP_News 1999] ...... 33 Tableau 6 : matériels équipés de télécommande par multiplexage [Poitevin 2000] . 34 Tableau 7 : matériels équipés du réseau LONWORKS [Poitevin 2000] ...... 35 Chapitre 3 : Tableau 1 : recommandation pour l’utilisation conjointe des réseaux de types T et L d’après [IEEE_1473 1999] ...... 72 Tableau 2 : transmission analogique/ numérique et nature de l’ETCD d’après [Summers 2000] ...... 78 Tableau 3 : caractéristique de la liaison MUX G d’après [Boutonnet & Chateaureynaud 1989a] ...... 89 Tableau 4 : caractéristique de la liaison TORNAD d’après [Duquesnoy & Kieken 1986 ; Duhot 1989] ...... 90 Tableau 5 : caractéristique des liaisons TCN d’après [IEC_TCN_URL ; ROSIN_URLb ; TCNspecifications 1998] ...... 93 Tableau 6 : caractéristique des liaisons BITBUS d’après [Ciame 1999 ; GESPAC_URL ; Elzet_80_URL ; Furrer 1998] ...... 94 Tableau 7 : caractéristique des liaisons WorldFIP d’après [ALS_50414b-en 1998] ...... 95 Tableau 8 : caractéristique de la liaison RS 485 du bus PROFIBUS [Profibus 1997 ; 1999 ; EN_50170_2 1996] ...... 96 Tableau 9 : caractéristique de la liaison CEI 1158-2 du bus PROFIBUS [Profibus 1997 ; 1999] ...... 97 Tableau 10 : propriétés de la fibre optique d’après [Profibus 1999] ...... 97 Tableau 11 : caractéristique d’une liaison CAN d’après [GESPAC_URL ; Paret 1996] ...... 99 Tableau 12 : caractéristique de la paire torsadée LONWORKS [Schickhuber & McCarthy 1997a ; 1997b ; Echelon_URL] ...... 102 Tableau 13 : médium courant porteur [Echelon_URL] ...... 102 Tableau 14 : codage des éléments binaire, synchronisation et isolation galvanique pour un médium paire torsadé ...... 103 Tableau 15 : bilan des longueurs et débits des réseaux comparés à ceux de TCN ...... 104

Synthèse INRETS n° 45 15 Les réseaux de terrain embarqués dans les transports guidés

Chapitre 4 : Tableau 1 : durée d’un cycle élémentaire (ou période de base) des réseaux WorldFIP et TCN ...... 116 Tableau 2 : trames de requête-réponse définies par le protocole WorldFIP ...... 119 Tableau 3 : définition des télégrammes des bus de TCN ...... 129 Tableau 4 : définition des télégrammes du bus WTB ...... 134 Tableau 5 : description des requêtes de l’administrateur maître du bus MVB d’après [ROSIN_URLb] ...... 139

16 Synthèse INRETS n° 45 Remerciements

Je tiens à remercier l’ensemble des personnes et des institutions qui m’ont aidée au cours de cette étude. Je remercie les membres du groupe 4.4 contrôle-commande ferroviaire du PREDIT 2 qui a discuté et retenu cette étude et la Direction des Transports Terrestres du ministère chargé des transports qui l’a financée. Je poursuivrai par les industriels et opérateurs qui m’ont fait connaître leurs points de vue, 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ée du 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 de maintenance du matériel d’Hellemmes. Mes plus vifs remerciements vont enfin à Monsieur le Professeur Michel Dang (INPG-ESISAR), Madame Marion Berbineau (INRETS-LEOST), Monsieur Alain Launay (SNCF) et Monsieur Jean-Philippe Lozac’h (SNCF), référés de cette étude, pour le travail de relecture et les amendements qu’ils ont bien voulu me suggérer.

Synthèse INRETS n° 45 17

Préface

L’émergence des Réseaux Locaux Industriels (RLIs) est contemporaine de celle des LANs, 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éseau local 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éthode d’accès. Ce principe de réalité, couplant méthode d’accès et architecture des circuits, a accompagné toutes les réussites industrielles des vingt dernières années des LANs, dont les RLIs.

Le domaine des réseaux de communication embarqués à bord des matériels roulant guidé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 utilisateurs en général, des prescripteurs de toute origine et des industriels des RLIs. Cette question traditionnelle se pose aussi : importer des RLIs existant dans d’autres secteurs applicatifs (process, voiture,..) ou en concevoir de nouveaux, plus adaptés au domaine ferroviaire ?

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 la couche physique à la couche MAC.

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

La couche MAC est enfin présentée selon une approche très analytique, par grandes familles de méthodes d’accès numériques : accès répartis par passage du jeton, accès par scrutation 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’ouverture pour ceux qui font de la veille et pour des chercheurs.

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

Synthèse INRETS n° 45 19 Les réseaux de terrain embarqués dans les transports guidés

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 espace 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 Dang Institut National Polytechnique de Grenoble

20 Synthèse INRETS n° 45 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 et parallèle à l’utilisation de réseau de terrain. Le domaine des systèmes embarqués sur les matériels ferroviaires roulants ne fait pas exception à la règle. Les réseaux de terrain introduits peuvent remplacer une centaine de fils parcourant l’ensemble du train. En France, les premières solutions embarquées ont été spécifiquement conçues pour le ferroviaire (Mux G dans les locomotives de trains de fret en 1990 et Tornad dans le TGV A et 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 et WTB), 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éseau PROFIBUS, 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 de réversibilité et de travail en unité multiple des locomotives, les applications candidates au multiplexage ont alors augmenté avec l’expérience des technologies des réseaux de terrain. Les applications d’informations aux voyageurs et celles de diagnostique et de maintenance se sont jointes aux applications de télécontrôle. L’interconnexion possible de 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 relation avec leur origine et celle des matériels hôtes ne facilitent pas cette interconnexion des véhicules de pays européens différents.

C’est dans ce contexte que l’ouvrage met en valeur les ressemblances et dissemblances des réseaux embarqués testés en effectuant une description progressive et transversale de leur couche physique et de leur sous-couche d’accès au médium amenée avec 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 sont notamment 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 de communication locaux.

Dans un deuxième temps, une étude des topologies des réseaux de communication locaux 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 de bus 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 ou encore à bord d’un ensemble indéformable de véhicules. Elle repose d’autre part sur celle

Synthèse INRETS n° 45 21 Les réseaux de terrain embarqués dans les transports guidés

d’un bus train pour l’interconnexion des véhicules du train pouvant subir des opérations de couplages et découplages en cours d’exploitation. Ce bus train assure une communication entre les différents bus véhicule du train. L’étude de la longueur des média filaires en cuivre et des débits sur ces média pour chacun des réseaux montre alors des valeurs de couples « longueur-débit » très différentes. 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.

Dans un troisième temps, l’étude des méthodes d’accès au médium de communication 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 de passage 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 souvent combinées. Outre les méthodes d’accès au médium de transmission, les accès aux ré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 de types scrutation qui définissent un trafic périodique pour les variables temps critique et un 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 une redondance du contrôleur maître du bus. Bien que les protocoles à accès aléatoires CAN et LONWORKS ne définissent pas de trafics périodiques et apériodiques, les exemples du protocole CANopen et d’utilisation du protocole LONWORKS montrent l’existence (CANopen) ou la faisabilité (LONWORKS) d’une telle spécification au niveau de la couche application (protocole CANopen) ou de l’application utilisateur (LONWORKS).

Les systèmes ferroviaires étant soumis à de fortes perturbations électromagnétiques et mé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 normes ferroviaires y sont rappelées. Quelles que soient les mesures particulières prises dans les protocoles des réseaux de communication, les normes prEN 50159-1 et -2 imposent qu’une couche sécurité soit construite 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 va cesser de prendre de l’importance avec l’extension des communications embarquées et des échanges entre les installations embarquées et celles de l’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 est aujourd’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éveloppement des passerelles adéquates qu’à celui des composants des réseaux qui, à l’exception du réseau TCN, sont des réseaux largement utilisés dans des applications d’automatisation.

22 Synthèse INRETS n° 45 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 de diffuser un travail de bibliographie et de synthèse relatif à l’utilisation des réseaux de communication filaires embarqués dans le domaine des transports guidés. Cette étude a été l’objet du projet PREDIT ATUTEG dont l’acronyme signifie « Analyse bibliographique et synthèse Technique relative à l’Utilisation des réseaux de Terrain Embarqué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 recherche bibliographique 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’autres ré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 alors inté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 filaires embarqués sur du matériel roulant ferroviaire :

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

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

C’est cette seconde approche qui a été adoptée dans cette synthèse avec pour guide descriptif l’organisation des fonctionnalités des réseaux de communication selon le modèle de référence hiérarchique OSI (Open System Interconnection) de l’ISO (International Standardization Organisation) lorsque les informations étaient disponibles. 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 la problé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

Synthèse INRETS n° 45 23 Les réseaux de terrain embarqués dans les transports guidés

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ériels ferroviaires y sont présentées. Les chapitres 3 et 4 sont respectivement consacrés aux diffé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èmes embarqués intégrant des réseaux de communication.

24 Synthèse INRETS n° 45 Chapitre 1

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

Ce premier chapitre a pour objet l’introduction de la problématique « réseau de communication embarqué dans des matériels ferroviaires roulants guidés ». Nous y rappelons succinctement ce qu’est un réseau de communication et présentons quelques applications « train » candidates à ce jour à la mise en réseau dans les matériels roulants considérés. Enfin, nous introduisons les différents réseaux de communication qui font l’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 de moyens qui permettent la communication entre des processus d’application ou tâches réparties sur des matériels informatiques de tout type ». L’architecture fonctionnelle de cet ensemble comporte « au moins un support de transmission pour l’acheminement des signaux » et des « protocoles de communication selon une architecture en couches conformes 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ème d’émission et de réception et interconnectées entre elles via un support de transmission pour l’acheminement des signaux. De nombreuses classifications de réseaux de communication existent. La figure 1 met en valeur les réseaux WAN (Wide Area Network) et les réseaux LAN (Local Area Network) qui sont également classiquement distingués des réseaux MAN (Metropolitan Area Network). Cette distinction tient compte de leur couverture géographique. Un réseau LAN ou réseau local est un réseau propriétaire, et donc d’utilisation gratuite, « qui couvre une zone géographique limitée » [Thomesse_R7574], typiquement un local ou un groupe de locaux. La technologie choisie peut aussi être propriétaire ou rendue propriétaire par son utilisation particulière dans une ou un ensemble d’applications. Un réseau MAN ou réseau métropolitain (réseau fédérateur [Toutain 1999]) permet le raccordement de locaux ou groupes de locaux entre eux par l’interconnexion de leurs réseaux locaux. Le coût de sa gestion et de sa maintenance est réparti entre les différents utilisateurs. Un réseau WAN ou longue distance (réseau public [Toutain 1999]) n’est pas limité à une

Synthèse INRETS n° 45 25 Les réseaux de terrain embarqués dans les transports guidés

zone géographique et fait appel à des réseaux publics et les services qui leurs sont associés. Sa gestion et sa maintenance sont réalisées par un opérateur facturant aux utilisateurs 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 ferroviaires font parti de la famille des réseaux locaux. Les systèmes de communication qui nous inté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 pour un matériel roulant ferroviaire, – qui sont utilisés à des fins de contrôle-commande (c’est-à-dire des réseaux non spé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 fibres optiques. 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 et Synthèse Technique concernant l’Utilisation de systèmes de Télécommunication Existants 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ériels ferroviaires roulants L’introduction des réseaux de communication filaires à bord des trains date d’une vingtaine d’années. Elle se fait de manière prudente, en raison notamment des contraintes

26 Synthèse INRETS n° 45 Introduction aux réseaux de communication embarqués à bord des matériels roulants guidés fortes de sécurité liées au domaine ferroviaire, de la période d’amortissement du matériel roulant ferroviaire longue (de 15 à 30 ans) et du marché concerné restreint. Une des motivations à cette introduction est la réduction de l’engorgement des câbles servant à la transmission des ordres entre les voitures d’un train de marchandises ou de voyageurs et notamment 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]. Cette fonctionnalité est implantée aussi bien dans les trains de marchandises que de voyageurs. – Le travail en unité multiple (UM) des locomotives Afin d’augmenter la longueur et le tonnage possible en marchandises des trains, le fonctionnement de plusieurs locomotives d’un même train doit pouvoir être contrôlé simultanément. Cette technique permettait d’envisager dans [Boutonnet et Chateaureynaud 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 trois locomotives, 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 de voyageurs. – La commande/surveillance des équipements des rames La commande et la surveillance des équipements des rames de type ouverture/fermeture des portes, mise en marche/arrêt de la climatisation, des lumières... concernent aujourd’hui les trains de voyageurs, notamment les TGV. Cependant le multiplexage des trains de marchandises peut laisser envisager la surveillance des voitures et, également, celle de l’état des marchandises par l’adjonction des capteurs adéquats [Lozac’h et al. 1998]. D’autres fonctionnalités mises en réseaux ou candidates au multiplexage dans des trains 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 freinage réparti des trains par une réduction des différences dans les délais de réception de l’ordre de commande de freinage d’une voiture à l’autre. Dans le cas du frein pneumatique équipant les trains de fret [Brisou 2002], la transmission des consignes de freinage émises par le conducteur est réalisée au moyen 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

Synthèse INRETS n° 45 27 Les réseaux de terrain embarqués dans les transports 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 transitoires d’é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 de propagation 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 commande parfaitement rectiligne, le dernier véhicule commence à freiner 3 secondes après le premier. 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 de freinage 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 du fonctionnement correct de ce système de freinage nécessite actuellement qu’un technicien aille prendre une mesure du niveau de dépression d’air à chaque extrémité du train. Un autre apport de la mise en réseau des équipements de freinage sera alors la réduction du temps de mise en service du train en permettant un diagnostique en ligne du fonctionnement du freinage et de la commande de freinage [Witte 1998 ; SNCF 1999]. Ce diagnostique sera possible par un retour d’information sur la console 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 (« Union Internationale des Chemins de fer »). Un frein à assistance électrique existe, mais la ligne électrique transmettant la consigne vient en redondance de la conduite générale. Des trains de fret équipés du frein électronique ECP (Electronically Controlled Pneumatic brake) de l’AAR (Association of American Railroad) sont en exploitation 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érale de frein. – La vérification de l’intégrité des trains L’installation de réseau embarqué dans les trains de fret devrait permettre, d’une part, de connaître à tout moment la configuration du train et l’état des équipements des voitures et, d’autre part, d’être informé de tout changement dans la composition du train (ajout, suppression ou perte d’un wagon).

28 Synthèse INRETS n° 45 Introduction aux réseaux de communication embarqués à bord des matériels roulants guidés

– L’information voyageur Elle concerne aujourd’hui l’affichage de la destination des voitures, des numéros de voitures et numéros de places. L’affichage de la route du train est effectué sur des écrans à l’extérieur des trains, près des portes d’accès, et à l’intérieur, dans les zones d’embarquement. L’utilisation d’un récepteur GPS permettra également l’affichage de la prochaine station dans les voitures du train [Fabri et al. 1999]. Un affichage de la réservation des sièges par l’intermédiaire de LED servira d’autre part à informer les passagers de places libres. Cette information, récupérée à bord du train au moyen d’une disquette ou d’une liaison GSM [Fabri et al.1999], sera diffusé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 est utile 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 des dé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 font face à de fortes contraintes liées à l’environnement des matériels roulants guidés et à la particularité de l’application train : – Les contraintes liées à l’environnement ferroviaire Celles citées dans [Poitevin 2000] sont notamment une large plage de température de – 30 ˚C à + 70 ˚C ; des vibrations importantes en provenance du roulement Fer/Fer et de la motorisation ; une pollution électromagnétique sévère en provenance notamment de la caténaire, des équipements de traction et des convertisseurs statiques ; une pollution importante par des poussières, y compris des poussières métalliques ; une corrosion importante des parties nues (contacts de connecteurs) induite par une condensation fréquente. Les équipements embarqués, en particulier les coupleurs et média de communication des réseaux, sont donc soumis à de fortes contraintes matérielles. Les champs électromagnétiques peuvent influer sur les signaux transmis, les vibrations peuvent être cause de microcoupures au 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 cours d’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. Par conséquent, un réseau de communication parcourant un train doit pouvoir supporter l’ajout ou la suppression d’entités connectées. Un exemple est celui de deux rames de TGV où les deux réseaux de communication autonomes des deux rames découplées doivent pouvoir être transformés en un unique réseau de communication après couplage des rames. Inversement, le découplage de ces rames devra induire une transformation du système « réseau de communication » en deux systèmes « réseau de communication » autonomes. Une autre difficulté, rencontrée

Synthèse INRETS n° 45 29 Les réseaux de terrain embarqués dans les transports guidés

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 ses véhicules nécessite des réseaux de communication de près de 1 km pour l’interconnexion d’équipements répartis dans un train ou jusqu’à environ 200 mètres pour ceux interconnectés au sein d’un véhicule [TCNspecifications 1998]. D’autres contraintes liées à l’application sont la disponibilité de la communication et l’aspect temps réel [Duhot 1989]. Les réseaux embarqués pouvant remplacer des centaines 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, ce qui nécessite de pouvoir garantir la pérennité des équipements embarqués durant cette 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 de communication peut être également importante. Remarquons que [Poitevin 2000] constate une forte influence entre le pays d’origine d’un réseau de communication embarqué et son développement géographique malgré la mondialisation des marchés. Ainsi, si l’on considère les deux réseaux constituant la norme internationale IEEE 1473 ratifiée en 1999 [IEEE_1473 1999], le réseau de communication américain LONWORKS est essentiellement implanté dans les pays anglo-saxons (Etats-Unis, Canada, Australie...) et le réseau de communication TCN (Train Communication Network), développé à l’aide d’un financement de l’Union Européenne, est aujourd’hui utilisé notamment dans des trains circulant en Allemagne, en Suisse et en Italie. 3. Quelques réseaux embarqués ou candidats au multiplexage 3.1 Exemples de réseaux embarqués Les premiers réseaux filaires de communication embarqués à bord des matériels roulants ferroviaires ont été des réseaux spécifiquement conçus pour les besoins du ferroviaire. En France, un des premiers besoins exprimés a été la réduction de l’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 Atlantique mis en exploitation en 1988 [Duhot 1989], mais aussi la ligne D du métro de Lyon MAGGALY (tableau 1). Sur la ligne de métro, ce réseau « relie par rame sur la même boucle deux pilotages automatiques, deux systèmes traction freinage et deux automates programmables de 300 entrées sorties chacun », ce qui fait douze équipements connectés sur la même boucle dans le cas de deux rames accouplées [Duhot 1989]. Dans la rame TGV Atlantique « composée de deux motrices et dix remorques », « TORNAD parcourt l’ensemble de la rame et assure la communication entre dix-huit calculateurs en unité

30 Synthèse INRETS n° 45 Introduction aux réseaux de communication embarqués à bord des matériels roulants guidés simple et le double en unité multiple. Chaque remorque est équipée d’un calculateur qui assure 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 les fonctions » guide de dépannage, essais freins et cab signal3, transmission de données vers le sol, préparation de la rame avant départ et mémorisation de défauts. « Ces fonctions font appel à TORNAD. La consigne d’effort de traction vers les moteurs passe dans le ré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]

Fonctionnalités multiplexées par TORNAD : 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 Lyon MAGGALY * Soit 210 motrices et 1 050 voitures.

Le réseau TORNAD* (lire TORNAD « Etoile ») d’ALSTOM a ensuite remplacé le ré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ée d’après [Poitevin 2000] pour la commande et la synchronisation des équipements de traction (tableau 2).

2 Le dispositif électronique d’anti-enrayage sert à éviter un blocage, d’où glissement, d’un ou plusieurs essieux lors du freinage, grâce à une régulation de l’effort de freinage. Il permet ainsi une utilisation optimale de l’adhérence entre la roue et le rail. Il minimise la distance de freinage 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 la vitesse maximale autorisée sur une section de ligne. Cette indication est fournie par un dispositif installé en cabine pour les trains circulant à plus de 200 km/h avec le concours de circuits de voie utilisant une transmission continue de fréquences porteuses par les rails ou de 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 provoque l’arrêt d’urgence en cas de besoin [Deufrako 1993 ; Berbineau et al. 1990].

Synthèse INRETS n° 45 31 Les réseaux de terrain embarqués dans les transports guidés

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

Fonctionnalités multiplexées par TORNAD* : Unité Multiple, Réversibilité, Contrôle de la rame. CAN : Commande et synchronisation des équipements de traction. Année Exploitant Matériel Nombre 1992 SNCF TGV Réseau bicourant 50 TGV Réseau tricourant 30 TGV R tricourant PBA 10 1992 SNCF TGV Transmanche 16 1992 SNCB « 4 1993 Eurostar UK ltd « 11 1995 Eurostar UK ltd « (North Of London) 7 1995 SNCF TGV DUPLEX 30 1996 SNCF TGV PBKA (Thalys) 6 1996 SNCB 7 1996 NS 2 1997 DB 2

Tableau 3 : matériels équipés du réseau TCN ou MICAS-S2 [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é le modèle pour TCN [Scheinder et Vitins 1996]) [Poitevin 2000] Fonctionnalités multiplexées : Année Exploitant Matériel Nombre Unité Multiple, Réversibilité, contrôle de la rame 1989 DB ICE 1 60 1996 ICE 2 22 Unité Multiple, Réversibilité 1992 SBB CFF FFS Re 450 115 1996 Re 460 119 Interconnexion 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 Tassin 1998 BoBoBo 9100 et Julien 1994] 5 1997 SBB CFF FFS IC 2000** 250 Réversibilité, contrôle de la rame 1987 FS Pendolino*** ETR 450 15 1993 Pendolino ETR 460 10 1997 Pendolino ETR 480 15 1996 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 les niveaux électriques sont conformes à la norme RS485. ** Les voitures IC 2000, incluant pour la version Bt une cabine de réversibilité, sont destinées à former une trentaine de rames-bloc, tractées par une locomotive Re 460. *** Le réseau du Pendolino, analogue à celui de TCN, provient de EKE.

32 Synthèse INRETS n° 45 Introduction aux réseaux de communication embarqués à bord des matériels roulants guidés

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] qui donne une liste de projets en cours réalisés par Adtranz et Siemens et basés sur l’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 WorldFIP en 1997-1998.

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

Fonctionnalités multiplexées par Intel BITBUS : Contrôle des portes, éclairage, alarmes... [Julien et al. 1994] Année Exploitant Matériel Nombre 1993 EuroTunnel* Voiture Tourisme 252 (triplettes**) * Les matériels roulants d’EuroTunnel sont équipés de trois réseaux (un pour les locomotives, ici ABB MICAS-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 un total de 9 navettes tourisme de 27 voitures.

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

Années Evolution de la technologie Application du réseau WorldFIP WorldFIP 1997-1998 HIFLIRTS : système de communication Métro Auber : en station à haute intégrité pour le transport Eurotunnel : Navette ferroviaire léger Belgique : locomotive de fret 1998-1999 Université de Birmingham : Météor (Paris) : ligne de métro « predictive condition monitoring of complètement automatisée railway infrastructure » Euro : locomotive de fret 1999-2000 Intégration sur WFIP de communication Singapour, Varsovie et Shangai : métros voix (paquets de sons) Dublin : Tramway 2000-2001 WorldFIP vidéo à 5 Mbit/s Inclinaison TGV (tilting) 2001 ^ WorldFIP HSF à 25 Mbit/s ALSTOM : conception des trams Application Internet/WorldFIP intégrant « optionic » : systèmes de métros, lignes des serveurs web sur WFIP sub-urbaines, trains inter-cité et TGV Communication d’image video sur HSF Intégration future de communication passager (son et image) et contrôle du conditionnement sur WFIP, HSF (High Speed Fieldbus)

Synthèse INRETS n° 45 33 Les réseaux de terrain embarqués dans les transports guidés

En Europe, les trains à grandes vitesses ont donc fait appel à des technologies dédiées TORNAD, TORNAD* et TCN pour la communication inter-rame et le contrôle des rames, en combinaison parfois avec des réseaux non-dédiés tels que BITBUS, WorldFIP ou 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 des manœuvres en gare et donc un gain de temps [Boutonnet et Chateaureynaud 1989a]. Ce multiplexage MUX G autorise également la commande simultanée de plusieurs locomotives (train en unité multiple – UM) [Menoux 1993]. Une technique de multiplexage 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) ou TCN par exemple.

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

Fonctionnalités multiplexées par MUX G : Unité Multiple, Réversibilité, Contrôle de la rame. Année Exploitant Matériel Nombre 1990 SNCF BB 9200 10 BB 25200 18 1994 SNCF BB 9700* 4 BB 16100* 15 Voitures V2N* 151 * Matériel qui permet la constitution de 11 rames-bloc.

Toujours dans le cas des trains de marchandises, de nombreuses recherches sont actuellement en cours en Europe pour la réalisation d’un frein électronique. On peut citer celle expliquée dans [Witte 1998] utilisant la technologie CAN. Plus récemment, la SNCF 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 des maté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.

34 Synthèse INRETS n° 45 Introduction aux réseaux de communication embarqués à bord des matériels roulants guidés

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

Fonctionnalités multiplexées par LONWORKS : Contrôle des freins et de la rame Année Exploitant Matériel Nombre 1996 BART*1 Voitures métro 900 1 « Baie Area Rapid Transit network » (San Francisco) [DOHEN 1985]. Les aspects relatifs à la sé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 30 Wagons 840 2 Différents réseaux de l’« Association of American Railroads ». L’ensemble forme 7 trains de 120 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 96 3 « 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 70 4 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.

Ce premier paragraphe a donc permis de lister un ensemble de réseaux de communication 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 de communication 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 communication spécialisés (MUX G, TORNAD*, TORNAD, TCN) et d’autre part à l’utilisation de technologies existantes (BITBUS, CAN, WorldFIP, LONWORKS). Ce second choix d’adapter des solutions existantes aux besoins du ferroviaire répond à une demande de disponibilité des composants et de réduction des coûts (coûts d’étude et de développement du réseau).

Synthèse INRETS n° 45 35 Les réseaux de terrain embarqués dans les transports guidés

3.2 Origine des réseaux de communication cités Le panorama effectué ci-dessus a montré que les premiers essais de multiplexage effectué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 et Suisse par exemple avec la définition des bus de communication qui sont à l’origine du réseau TCN). D’autres réseaux de communication (CAN, WorldFIP, BITBUS, LONWORKS) en provenance d’autres secteurs d’activités ont également fait l’objet d’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 en provenance de différents pays, le réseau de communication TCN (Train Communication Network) a été spécifié dans le cadre de l’IEC (International Electrotechnical Commission ou CEI en français pour « Commission Internationale Electrotechnique » [IEC_URL]). Des applications ont alors été étudiées à l’occasion du projet européen ROSIN4 (acronyme de Railway Open System Interconnection Network) [ROSIN_URLa]. Dans ce même souci, cette technologie, récemment normalisée sous le nom de IEC 61375-1, ainsi que la technologie LONWORKS [Echelon 1999 ; Chervet 1998 ; Sullivan 1998] ont été retenues en tant que standard IEEE (IEEE 1473-L pour la solution ferroviaire 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 autre réseau, le réseau PROFIBUS, qu’il est question d’embarquer à bord des trains à grande vitesse en Europe pour les applications embarquées de contrôle ERTMS (European Rail Traffic Management System). Rappelons que le but d’ERTMS est de permettre à tout type de train, équipé du système de contrôle-commande et de signalisation ETCS (European Train 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, dans l’introduction de son livre sur le réseau CAN [Paret 1996] : « Il s’agit encore d’un autre bus ! Mais quand donc s’arrêtera-t-on de créer de nouveaux bus et normalisera-t-on tout cela ? ». 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 Transport Sector) 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 des Chemins de Fer (UIC) (partenaire sponsor – France), Union Internationale des Transports Publics (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).

36 Synthèse INRETS n° 45 Introduction aux réseaux de communication embarqués à bord des matériels roulants guidés surtout lorsque chacun a des souhaits et des exigences techniques particulières et qu’il existe 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 à notre arsenal 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-ils disponibles ?). Les normalisations de réseaux locaux, la course aux standards, essaient de résoudre le problème du trop grand nombre de solutions, mais sans succès puisque chaque nouvelle norme commune juxtapose un certain nombre de solutions non interopérables [Thomesse 1998]. Ainsi, nous n’essayerons pas d’y répondre, mais nous nous attacherons à mettre en valeur techniquement les différences ou ressemblances de chacun des réseaux cités selon différents critères, parmi lesquels on peut citer leur topologie (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 sont transmises), leurs protocoles (soit les règles d’échanges de données, de codage des données transmises...). Dans ce contexte, les réseaux embarqués à ce jour, dont les caractéristiques de la couche physique et de la méthode d’accès (partie inférieure de la couche liaison de données) font l’objet de ce rapport dans la limite de l’information à notre disposition, sont donc 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 au multiplexage de la commande de réversibilité des trains de marchandises. Cette commande 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 par ALSTOM (anciennement Alsthom) pour le TGV. Leurs topologies respectives sont l’anneau (TORNAD) et le bus (TORNAD*). Nous n’avons pas trouvé d’informations sur le protocole TORNAD* sinon que son accès au médium est basé, comme celui de TORNAD, sur la possession d’un jeton mais avec une topologie bus. Nous évoquerons donc d’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ême véhicule et dans différents véhicules [TCNSpecifications 1998]. Pour cela son architecture est définie comme une structure hiérarchique comportant un bus véhicule et un bus train. [TCNSpecifications 1998] spécifie notamment deux bus de communication : le bus véhicule MVB (Multifunction Vehicle Bus) pour l’interconnexion des équipements

Synthèse INRETS n° 45 37 Les réseaux de terrain embarqués dans les transports guidés

standards situés à bord d’un véhicule, le bus train WTB (Wire Train Bus) pour celle des véhicules d’un train « ouvert » tel que les trains internationaux UIC. La définition du bus MVB repose sur l’expérience acquise sur 200 locomotives en service en Suisse notamment. Celle du bus WTB repose sur le standard allemand DIN V 43322 utilisé sur le 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é 9 de la Commission Internationale Electrotechnique (IEC TC9 WG22) en collaboration avec le Groupe pilote 5R de l’Union Internationale des Chemins de Fer (UIC 5R). Un nouveau groupe IEC TC9 WG38 étudie depuis juillet 2000 la possibilité d’une nouvelle norme 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-1999 sur les protocoles de communication embarqués dans les trains sous la dénomination P1473-T. LONWORKS est le second protocole intégré dans cette norme sous le nom P1473-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 devenu un standard en 1990 (standard IEEE-1118 1990). Le réseau BITBUS est supporté par l’organisation BEUG (BITBUS European Users Group) en charge de la diffusion de cette technologie 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 groupe de travail français à la même époque que l’était le bus CAN par Bosch (1983-1984) et le réseau PROFIBUS (1985) en Allemagne. Il fait l’objet de la partie 3 de la norme CENELEC EN 50170 [EN_50170_1 :3 1996]. Les parties 1 et 2 de cette norme sont respectivement 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éseaux d’instrumentations [Thomesse 1998]. Le réseau CAN Le protocole CAN (Controller Area Network) a été le premier protocole de communication 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 est normalisé 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ère version du livre blanc [FIP 1984] ou encore Flux Information Process, puis Factory Instrumentation Protocol. Il est également celui de Fieldbus Internet Protocol depuis la décision de 1998 d’introduire un produit intégrant le protocole Internet (IP) [WorldFIP_URL].

38 Synthèse INRETS n° 45 Introduction aux réseaux de communication embarqués à bord des matériels roulants guidés séries à bas débit embarquées à bord de véhicules routiers (soit un débit de transmission du 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 les réseaux de communication à basse vitesse pour les véhicules routiers (partie 1), au bus franç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 paire torsadé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 CAN sont é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é Echelon Corp., Palo Alto, USA [Heffernan 1997]. Il réalise d’après [Heffernan 1997] une solution de 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 transports ferroviaires, ce réseau fait l’objet, avec le réseau TCN, de la norme internationale IEEE 1473 votée en 1999. Dans le domaine des applications domotiques, une norme ENV 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. Il est utilisé pour l’automatisation de l’industrie, des bâtiments et des maisons et dans le transport. Enfin, un autre réseau non dédié, le réseau PROFIBUS, est couramment à l’étude pour les applications embarquées ERTMS. Le réseau PROFIBUS Le réseau de terrain PROFIBUS a été créé en Allemagne en 1985 à la même époque que les réseaux FIP (1982) et CAN (1983-1984). Depuis 1989, il fait l’objet du standard allemand DIN 19245. En 1996, il a été ratifié pour la partie 2 de la norme CENELEC EN 50170 [EN_50170_1 :3 1996]. La partie 3 de cette norme est dédiée au réseau WorldFIP. En 2000, le réseau PROFIBUS a été ratifié pour le standard international IEC 61158. Le réseau PROFIBUS n’est actuellement pas embarqué à bord de trains. Ce réseau a cependant été choisi pour les applications de contrôle ERTMS (European Rail Traffic Management System), applications qui permettront à tout type de train de circuler sur toute ligne européenne [ERTMS_URL]. PROFIBUS est cependant déjà utilisé dans l’infrastructure ferroviaire pour les systèmes d’aiguillage.

Synthèse INRETS n° 45 39

Chapitre 2

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

1. Introduction au modèle de référence OSI de l’ISO Devant l’impossibilité d’interconnecter les différents réseaux des constructeurs, un sous-comité de l’organisation internationale de standardisation (ISO – International Standard Organization) a été créé en 1977 afin d’établir une norme internationale pour la transmission de données par réseau. Le travail de ce sous-comité a donné lieu à la publication 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ée conformé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 normes appropriées » [EuroDicAutom_1]. Un système ouvert peut ainsi être un ordinateur, un terminal, 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 et les services qu’il peut assurer sont représentées par une hiérarchie de couches de protocole. Il est ainsi composé de sept couches (figure 1), chacune correspondant à un niveau d’abstraction du système. D’autre part, « chaque couche contient une ou plusieurs fonctions 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 propres fonctions pour créer de nouveaux services qui sont mis à la disposition des couches de niveau supérieur » [EuroDicAutom_2]. Pour chaque couche implantée par un réseau, un ensemble de règles sémantiques et syntaxiques qui régit le comportement des unités fonctionnelles au cours de la communication est défini [EuroDicAutom_3]. Cet ensemble, appelé pour une couche n donnée « protocole de communication de la couche n », permet la communication de cette couche n d’un équipement avec celle de même niveau n d’un autre équipement distant.

Synthèse INRETS n° 45 41 Les réseaux de terrain embarqués dans les transports guidés

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. Elles sont tout d’abord transmises jusqu’au médium de communication via les services offerts par les interfaces des couches adjacentes (figure 2), puis elles transitent via les différents nœ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 remonte alors 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. Les trois 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 du matériel utilisé. A la transmission, la couche transport, décompose, si nécessaire, les

42 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI données en provenance de la couche immédiatement supérieure (couche session) en paquets de taille plus petite de sorte à ce que chacun puisse être inséré dans la trame de communication, 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]

Les trois couches inférieures 1 à 3 (physique, liaison et réseaux) se chargent alors de l’acheminement avec contrôle d’erreur des paquets de la couche transport à travers le réseau [Mackenzie et Bettaz 1988]. La couche 4 (transport) assure l’interface entre les fonctions 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 maintenant rapidement 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’environnement réseau. Elle est donc l’interface entre les processus utilisateur et l’environnement ré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 sa sémantique. Quelques-uns de ses services peuvent être le codage des données, la compression de données, le cryptage.

Synthèse INRETS n° 45 43 Les réseaux de terrain embarqués dans les transports guidés

– 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 deux utilisateurs 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 le transfert d’un fichier de données de l’un à l’autre [Tanenbaum 1997]. Un des services de cette couche est la gestion de dialogue, le trafic entre les utilisateurs pouvant être bidirectionnel ou bidirectionnel à l’alternat. Dans ce second cas, le service gestion de dialogue permet d’éviter les conflits d’accès à la ressource partagée par la gestion d’un « jeton » qui donne le droit de parole à la station qui le possè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ée une ou plusieurs connexions réseau par connexion transport requise par la couche session (requête vers la couche réseau). Un mécanisme de contrôle des flux peut exister dans cette couche pour empêcher qu’une machine hôte ne sature une machine plus lente. C’est un protocole de bout en bout en cela qu’une machine destinataire échange des données avec une machine source en utilisant un même programme identifié par le contenu des messages d’en-tête et de contrôle. Plusieurs programmes hôtes pouvant être supportés par une même machine, l’en-tête de la couche transport peut aussi permettre d’identifier les différentes connexions entrantes 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 son nœ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ôle de flux des paquets afin qu’ils n’engorgent pas un sous-réseau. Différentes straté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, est souvent inexistante dans les réseaux à diffusion, peu concernés par les problèmes de routage de l’information. Elle intervient lors de l’interconnexion de réseaux hé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 à point ou multipoints entre une station hôte et son nœud de transmission [Mackenzie et Bettaz 1988]. Une de ses fonctions est l’assemblage des données sous la forme de trames de données, qui seront ensuite émises par la couche physique sous celle d’éléments binaires. Afin de délimiter cette information émise, elle ajoute notamment un délimiteur à chaque extrémité de la trame. D’autres fonctions sont

44 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI

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êcher qu’un émetteur rapide ne sature un plus lent) et l’accès au médium de communication. Afin de s’adapter à l’émergence des réseaux locaux, la norme ISO DIS 8802 subdivise cette couche liaison de données en deux sous-couches (voir le paragraphe 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’interface mécanique, électrique et fonctionnelle entre une machine hôte et son nœud de transmission [Mackenzie et Bettaz 1988]. Elle définit notamment les niveaux des signaux transmis et les débits de données. Cette couche est responsable de la transmission d’éléments binaires sur un médium de transmission [Tanenbaum 1997]. Le support de transmission peut être une liaison filaire (fil en cuivre ou fibre optique) 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 de réseau » (Network Management – figure 1) : – l’entité de « gestion de réseau », transversale aux sept couches, définit un ensemble de fonctions de paramétrage, de configuration, d’exploitation et de surveillance pour 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 comparer les différents réseaux de communication par l’examen des différents protocoles de communication qui les composent. Comme nous le verrons, toutes les couches OSI ne sont pas implantées dans l’ensemble des réseaux de communication. Plus d’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 [Tanenbaum 1997]. Le paragraphe 2 suivant s’intéresse au modèle de référence IEEE 802 particulier aux réseaux de communication locaux et métropolitains, le paragraphe 3 présentera les différentes méthodes d’interconnexion de réseaux locaux, enfin le paragraphe 4 traitera de la décomposition en couche, selon le modèle de référence OSI, des réseaux utilisés pour 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 du modèle OSI, la couche physique et la couche liaison de donnée. Il propose une décomposition de la couche liaison de données en deux sous-couches, la sous-couche basse 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 »). Les fonctions des couches LLC, MAC et physique sont décrites ci-après.

Synthèse INRETS n° 45 45 Les réseaux de terrain embarqués dans les transports guidés

– La sous-couche LLC (normalisé ISO 8802-2 et ANSI/IEEE Std 802.2) assure le contrô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 trois types 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 au préalable de lien logique entre les entités communicantes. Chaque unité de données est transmise comme un « datagramme » dans une trame non numérotée. Il n’y a ni accusé de réception, ni garantie de séquence, ni recouvrement d’erreur. • LLC Type 2, un service « orienté avec connexion » (connection-oriented) pour lequel une liaison logique doit être établie avant tout échange de trames d’informations. Les paquets de données transférés via les trames sont numérotés et délivrés en séquence. La couche LLC acquitte les paquets reçus et effectue un recouvrement d’erreur. • LLC Type 3, ce troisième service « sans connexion avec acquittement » (acknowleged connectionless) est un compromis entre les deux premiers. Il ne nécessite pas l’établissement d’un lien logique entre les entités LLC communicantes avant tout échange de trames. Mais, un accusé de réception, que l’émetteur attend avant d’émettre toute nouvelle trame, est envoyé à chaque trame reçue. Cet acquittement permet le recouvrement d’erreur et l’ordonnancement correct des trames. Ce troisième service autorise également qu’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 services de la sous-couche MAC afin d’assurer le contrôle d’erreur de la couche physique et la correction de certaines erreurs par retransmission des trames erronées (services LLC types 2 et 3).

46 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI

– La sous-couche MAC Elle réalise, en support de la couche LLC, les fonctions d’accès au médium de communication partagé, l’adressage et la reconnaissance des trames. Lors de l’émission d’une trame, elle génère et insère dans la trame une séquence pour le contrôle d’erreurs (FCS – Frame Check Sequence). Elle réalise également la délimitation de l’« unité de données du protocole LLC » par l’insertion de délimiteurs. A la réception, elle désassemble la trame reçue (suppression des délimiteurs et de la séquence de contrôle) et vérifie l’intégrité de la trame au moyen de la séquence de contrôle. – La couche physique Elle fournit les moyens de transmettre et de recevoir des bits 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équences spécifiques, dans le cas d’une transmission large bande (broadband), ou affectés à un unique canal dans une 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ération d’é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 être trouvé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ès des 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 sur anneau, 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 techniques pour la transmission sur fibre optique ; – le projet P802.10 qui porte les spécifications de la couche physique et de la méthode d’accès des réseaux sécuritaires dont les données sont privées.

Synthèse INRETS n° 45 47 Les réseaux de terrain embarqués dans les transports guidés

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 « fournit un ensemble d’outils qui permet à des applications de gestion spécifiques de réaliser des tâches de gestion à l’intérieur des stations LAN, telles que la gestion de confirmation, de fautes, de performance ou de sécurité » [IEEE_Std_802 1990]. 3. Equipements d’interconnexion pour les réseaux locaux Il 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, des nœ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 les synchronisent ». Ils interconnectent deux segments de même technologie d’un même ré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 de transmission peuvent être de natures différentes. Leur rôle est de filtrer et de relayer les trames de la couche liaison de données d’un réseau à l’autre de sorte à ce que les utilisateurs de chacun des deux réseaux interconnectés puissent accéder aux ressources de 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 et liaison de données peuvent être différentes. Leur rôle est d’assurer « le routage et l’aiguillage des messages », à partir de la connaissance des adresses, afin d’acheminer un message d’un équipement source d’un réseau à un équipement destinataire d’un autre réseau. Les routeurs peuvent également assurer un rôle de filtrage des trames au niveau de la couche liaison de données, ils sont alors parfois appelés « ponts/routeurs ».

48 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI

Les passerelles interconnectent deux réseaux hétérogènes incompatibles. Elles assurent, en utilisant une partie ou l’ensemble des sept couches du modèle de référence OSI, l’adaptation des deux réseaux. Elles convertissent les informations d’un format à un autre. La conception de chacun de ces équipements est naturellement spécifique aux réseaux qu’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 un ré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 à notre disposition ne spécifient pas les couches implantées par la liaison MUX G. Les informations reportées sur ces deux réseaux sont donc des hypothèses élaborées d’après la description de la liaison filaire MUX G dans [Boutonnet et Chateaureynaud 1989a] et par similitude avec le réseau TORNAD, prédécesseur de TORNAD*, dont les couches sont 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 de référence OSI. Trois d’entre eux ont été spécifiés dès l’origine pour les applications ferroviaires (TORNAD, TORNAD* et TCN). Le quatrième (LONWORKS, protocole LonTalk), dont la couche physique n’est pas spécifiée dans le protocole, était déjà

Synthèse INRETS n° 45 49 Les réseaux de terrain embarqués dans les transports guidés

couramment utilisé dans le secteur du bâtiment, notamment pour des applications de domotique. – les autres protocoles (WorldFIP, BITBUS, PROFIBUS et sans doute MUX G) sont dé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 de données (sous-couches MAC et LLC). Cependant, pour ce dernier protocole, de nombreuses couches application propriétaires ou commerciales existent aujourd’hui (paragraphe 4.3 de ce chapitre). – parmi l’ensemble des réseaux utilisés dans le ferroviaire, deux mettent en évidence une couche « gestion du réseau » (WorldFIP et TCN). Cependant, l’absence de cette couche dans une représentation ne signifie pas que des services permettant cette gestion du réseau n’existent pas au sein des différents protocoles du réseau comme 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 de réseau, une huitième couche, la couche utilisateur, est considérée dans les prospectus techniques relatifs au réseau PROFIBUS. Cette couche concerne des profils applicatifs définis en réponse à des besoins spécifiques de différents secteurs d’activités industriels, par exemple du manufacturier (équipement de type variateurs, 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 documentations techniques ou autres publications publiques, qui représentent la décomposition en couches de ces réseaux, on comprend que cette représentation ne permet pas de les comparer rapidement. Deux types de présentations peuvent être distingués selon qu’elles mettent en valeur : – un détail de fonctionnalités des couches du réseau relativement au modèle de référence OSI ou – des aspects hiérarchiques et/ou normatifs de différents protocoles composant le réseau. Le premier cas a été rencontré lorsque le réseau de communication local est construit autour d’un protocole spécifique qui peut être ou pourrait être normalisé. On peut citer le réseau CAN basé sur le protocole CAN, le réseau LONWORKS basé sur le protocole LonTalk ou encore le réseau propriétaire TORNAD (figures 7 à 10). La seconde repré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é de quatre protocoles, réseau WorldFIP mettant en valeur les parties normalisées ou réseau PROFIBUS 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 de référence OSI de l’ISO d’après [Duhot 1989]. Elle met en valeur les caractéristiques

50 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI fonctionnelles du réseau et la répartition de ces fonctions sur les différentes couches du modèle de référence OSI. Les coupleurs TORNAD, au moyen desquels sont connectées les stations, couvrent les six premières couches. On en déduit raisonnablement que la couche 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. Des coupleurs TORNAD, entièrement compatibles, ont également été développés par la socié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 la spé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 par l’utilisateur. Comme nous l’avons précédemment signalé, des protocoles application sont cependant 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 1 et 2 du modèle de référence OSI. [Bosch 1991] définit la couche physique et les deux sous-couches MAC et LLC comme expliqué ci-dessous. – Seule la partie haute de la couche physique est spécifiée. Elle décrit le rythme binaire, 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 des signaux sur le médium de transmission choisi en fonction de l’application cible.

Synthèse INRETS n° 45 51 Les réseaux de terrain embarqués dans les transports guidés

D’après [CANimpl 2000], la sous-couche PS de la couche physique est supervisée par 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 à la couche physique les messages reçus en provenance de la sous-couche LLC et elle accepte de la couche physique les messages à transmettre à la sous-couche LLC. Elle est responsable de la mise en trame des messages (message framing), de l’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 une entité de gestion de réseau appelée confinement d’erreur. Cette entité est un mécanisme « d’auto-vérification » qui distingue les perturbations temporaires des défaillances permanentes [Paret 1996 ; Bosch 1991]. – La sous-couche LLC se consacre au filtrage de messages (acceptation ou refus d’un message), à 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 circuits contrôleur de protocole CAN. Certaines de ces fonctions sont reprises sur la figure 9 qui présente l’architecture fonctionnelle d’un circuit contrôleur de protocole CAN s’interfaçant à un micro-processeur.

52 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI

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

Les circuits contrôleur de protocole CAN intègrent un module contrôleur de protocole CAN, 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 architectures de 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 un microcontrôleur externe qui gère notamment son fonctionnement. Les circuits microcontrôleurs intégrés avec un contrôleur de protocole CAN (cas « B » de la figure 10) s’interfacent directement avec l’application. Il en est de même pour les composants CAN SLIO (Serial Linked I/O Device – cas « C » de la figure 10). Les nœuds SLIO, contrairement aux nœuds possédant une unité de traitement (CPU), ne peuvent transmettre que sur une demande d’un autre nœud. Les composants SLIO étant conçus pour 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’un microcontrôleur distant sur le bus CAN.

Synthèse INRETS n° 45 53 Les réseaux de terrain embarqués dans les transports guidés

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

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 de plus d’une centaine de composants. Quelques exemples de composants existant aujourd’hui sont : – des contrôleurs CAN 2.0B autonomes tels que le composant SJA1000 de Philips avec une interface CPU hôte de 8 bits, une mémoire tampon (buffer) pour la transmission d’un message, une FIFO de 64 octets pour la réception de messages ; le composant 82527 d’Intel offrant le choix d’une interface CPU 8 bits multiplexés (bus adresses et données), 8 bits non multiplexés, 16 bits multiplexés ou série SPI, une mémoire tampon 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 composant MCP251 de Microchip avec une interface CPU série SPI et une mémoire de 3 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ôleur CAN 2.0B intégré tels que les composants C515/C505C d’Infineon avec un CPU de 8 bits, 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 C167CR d’Infineon avec 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émoire tampon de 16 messages en émission ou en réception... [IXXAT_URL] ;

54 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI

– des circuits DSP avec un contrôleur CAN intégré tels que le DSP eCAN (enhanced Controller 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 du protocole 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 logicielle alors 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 les protocoles J1939 de la SAE (Society of Automotive Engineers aux USA), OSEK (Open Systems and the Corresponding Interfaces for Automotive Electronics) du groupement European Car Industries Users Group [Paret 1996]. Les protocoles les plus connus développés pour les systèmes de contrôle et les réseaux embarqués de l’industrie sont les protocoles application CAL (CAN Application Layer) du groupement CiA (CAN in Automation), CANopen dont les spécifications sont basées sur CAL et qui a été ratifié en 2002 par le comité de standardisation Cenelec pour être publié comme partie 4 de la norme EN 50325 (EN 50325-4), DeviceNet de la société Allen Bradley, SDS (Smart Distributed System) de la société Honeywell ou encore pour des applications plus spécifiques CAN Kingdom de Kvasa [Paret 1996 ; CANappl 2000]. Parmi ces protocoles de la couche application, signalons l’utilisation dans les transports de CANopen par BMW pour le bus hybride développé par Neoplan. D’autre part, 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 au contrô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é un système d’informations aux passagers utilisant ce protocole application. Le réseau CANopen devrait se substituer au réseau allemand IBIS utilisé sur du matériel ferroviaire allemand. 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é sur l’utilisation de la partie 1 et 2 de la norme ISO 11898 du protocole de communication CAN (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 et spécifie des fonctionnalités de communication additionnelles pour les équipements programmables. Il complète également la couche physique du protocole CAN en définissant la durée des éléments binaires et en faisant des recommandations sur l’affectation des broches des connecteurs. Ces recommandations sont à respecter pour assurer l’interopérabilité d’équipements conçus par des constructeurs différents.

6 SIG : Special Interest Group.

Synthèse INRETS n° 45 55 Les réseaux de terrain embarqués dans les transports guidés

Les profils des équipements, des interfaces et applications « standardisés » spécifient le 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]

56 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI

La figure 12 présente les fonctions logicielles d’un profil CANopen. Le logiciel du protocole 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’exemple des micro-processeurs des familles 8051 et C16x interfacés à un contrôleur CAN externe Intel 82527, Philips 82C200 ou Philips SJA1000 par exemple, ou encore, de microprocesseurs 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. La couche physique n’est pas spécifiée autorisant ainsi l’utilisation de différents média de communication et méthodes de codage des données, la méthode de codage choisie dépendant du 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 du protocole 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 processeur Réseau et un processeur MAC. Il existe deux familles de ce circuit « Neuron Chips », le Neuron 3120 et le Neuron 3150. Le 3120 stocke directement l’applicatif. Avec le 3150, l’applicatif est stocké 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 Cypress Semiconductor suite à un changement d’orientation de la société Motorola annoncé en janvier 1999. Echelon indique également que le code du protocole LonTalk, qui figure dans la norme ANSI/EIA-709.1-A, peut être implémenté sur d’autres microprocesseurs que le « Neuron Chip ». Les composants des réseaux de contrôle LONWORKS sont fournis par Echelon et ses partenaires 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

Synthèse INRETS n° 45 57 Les réseaux de terrain embarqués dans les transports guidés

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

4.5 Réseau WorldFIP La figure 15 tirée de [Azevedo et Cravoisy 1998] met en valeur la normalisation des quatre 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]

58 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI

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 aux autres équipements connectés sur le bus, le médium peut être une paire cuivre torsadée blindée ou une paire de fibres optiques (EN50170-3, parties 2 et 3). Elle définit le débit, le codage des éléments binaires de la trame et les média de transmission 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 sont ré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 les applications. 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 la communication et l’ensemble des ressources de communication nécessaires. Les deux services de cette couche sont d’une part le service SM_MPS basé sur les services périodiques et apériodiques MPS et d’autre part le service SMS basé sur les 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 partie des couches liaison de données et physique des normes EN50170-IEC61158. Il accepte 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érer jusqu’à 4000 identificateurs et 2 Mbits de mémoire externe. La figure 16 montre un exemple 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 les fonctions d’abonnés (Subscriber), d’arbitre de bus (Bus Arbiter) (voir le paragraphe 3 du chapitre 4) et d’observateur réseau WorldFIP. – FIPCO1 et MicroFIP sont des circuits bon marché. FIPCO1 est à utiliser avec un micro-processeur pour la connexion d’équipements simples échangeant uniquement des variables. Il ne permet pas le transfert de messages et ne peut ré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ées traitées localement. Il opère à 31,25 kbit/s, 1 Mbit/s et 2,5 Mbit/s. Il est capable de gérer des messages de longueur maximum de 128 octets et jusqu’à 8 mémoires tampons distribuées parmi les 120 octets de mémoire interne. La figure 17 montre un exemple d’architecture d’un nœud WorldFIP implantant un circuit MicroFIP.

Synthèse INRETS n° 45 59 Les réseaux de terrain embarqués dans les transports guidés

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

60 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI

4.6 Réseau TCN La décomposition en couches des protocoles du réseau TCN (Train Communication System) est montrée en figure 18 [TCNspecifications 1998]. Cette figure met en évidence ses quatre protocoles MVB, WTB, RTP et NM spécifiquement conçus pour l’interconnexion d’équipements programmables situés à l’intérieur d’un même véhicule et de différents véhicules : – Le protocole du « bus véhicule » MVB (Multifunction Vehicle Bus) est défini sur les 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 les couches 1 et 2. Il permet l’interconnexion des véhicules d’un train dans le cas de trains « 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éhicule autorisent la communication avec d’autres applications du même ou d’autres véhicules au travers du réseau TCN. Les protocoles RTP de TCN sont utilisés pour la communication sur un bus véhicule MVB, le bus train WTB ou tout autre bus offrant les mêmes services de base demandés par RTP. Ces protocoles offrent à la couche application les services « variables », pour lesquels seule la couche 7 est spé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 services nécessaires à la mise en service, au test et à la maintenance d’un réseau TCN dont les bus (MVB, WTB ou autres bus non spécifiés par TCN) acceptent les protocoles RTP 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]

Synthèse INRETS n° 45 61 Les réseaux de terrain embarqués dans les transports guidés

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 cartes MVB sont conçues par Bombardier, Far Systems et Siemens, des cartes MVB/VME par Kontron et Unicontrols, des passerelles TCN par Bombardier, EKE Electronics, Far Systems, des passerelles MVB/CAN par Duagon et Selectron, le logiciel TCN est disponible 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 des progrès techniques. L’évolution de la représentation des couches du réseau PROFIBUS illustre bien ce propos (figures 19 et 20). Un autre exemple explicite aurait pu être le réseau WorldFIP dont la couche application est couramment en cours de développement afin d’accepter de nouvelles familles d’applications [WorldFIP_URL]. Les deux figures montrent un protocole défini sur les couches physiques, liaison de données et application du modèle de référence OSI. Le manuel technique [Profibus 1997] mettait en valeur les différentes parties faisant l’objet de la norme européenne EN 50170, de la norme allemande DIN E 19245 (partie 4) ou encore de directives PROFIBUS. Elle distinguait également trois profils applicatifs : PROFIBUS-FMS, réseau qualifié « d’universel » pour les applications « 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 de 1999 du manuel technique [Profibus 1999] met en avant (figure 20) : – des supports physiques (liaison RS 485 pour les applications de l’industrie manufacturière, la transmission CEI 1158-2 pour le process et la fibre optique pour les environnements perturbés et les longues distances) ;

62 Synthèse INRETS n° 45 Présentation des réseaux de communication ferroviaires selon le modèle de référence OSI

– 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 dialogue entre automatismes et périphérie décentralisé », en remplacement « des signaux 24 V dans le manufacturier et de signaux analogiques sur boucle 4-20 mA dans le process » [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 de PROFIBUS, il devrait jouer, d’après [Profibus 1999], un rôle moins important dans la communication industrielle ; – des profils applications qui décrivent « l’interaction du protocole utilisé », DP et FMS, « avec la technique de transmission utilisée », c’est-à-dire la transmission RS 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 couches physique à 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. [Profibus 2002] fait état de trois types de puces de protocole : – « des puces simples intégrant toutes les fonctions du protocole, sans contrôleur supplé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é ».

Synthèse INRETS n° 45 63 Les réseaux de terrain embarqués dans les transports guidés

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

5. Conclusion Ce 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éseaux de communication multi-constructeurs. Le modèle de référence propre aux réseaux de communication locaux dont les couches 1 et 2 sont généralement très développés et les différents types d’équipements d’interconnexion ont alors été présentés. Après ces trois parties introductives, nous nous sommes alors intéressés à la représentation des réseaux de communication « ferroviaires » selon le modèle de référence OSI ainsi qu’à l’architecture des nœuds. Le parcours de ces représentations a été fait à partir des normes, d’articles scientifiques ou de prospectus. Il nous permet déjà d’introduire l’hétérogénéité des solutions mises en œuvre et le large éventail des choix technologiques. Il met notamment en valeur la difficulté 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éveloppement de passerelles pour permettre l’interconnexion de ces solutions et donc de véhicules ferroviaires de pays d’origines différentes. Un exemple d’interface est celle fournie par Selectron entre le CAN et MVB [Selectron 1999]. Deux autres exemples sont un répéteur MVB 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 physique et les protocoles d’accès au médium de ces réseaux.

64 Synthèse INRETS n° 45 Chapitre 3

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

Les deux principales couches des réseaux de communication locaux sont généralement les deux couches basses du modèle OSI, la couche physique et la couche liaison 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 couche physique des protocoles de communication embarqués, le chapitre suivant s’intéressera plus 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éments binaires 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équences spécifiques dans le cas d’une transmission large bande (broadband, transmission par modulation de porteuse) ou encore les signaux affectés à un unique canal dans une bande de 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ération d’é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 topologies embarquées au sein des trains, ensuite les supports de transmission prévus par les protocoles de communication qui nous intéressent et enfin les différentes techniques de transmission sur un médium de transmission (filaire ou non) et le codage des informations. 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ésenter celles choisies dans le cas particulier de réseaux de contrôle-commande embarqués au sein 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 logique définit la façon dont une trame est véhiculée sur le réseau. Elle est réalisée par un protocole d’accès.

Synthèse INRETS n° 45 65 Les réseaux de terrain embarqués dans les transports guidé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 » supportent l’interconnexion en parallèle de plusieurs stations à un même support physique. Tout abonné 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és sont le bus (topologie multipoint), l’anneau (topologie point à point) et l’étoile (topologie point à point) [Tanenbaum 1997 ; Mackenzie et Bettaz 1988 ; Desgeorge 2000 ; Summers 2000]. 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 du réseau sur une seule ligne. Tous les abonnés partagent le même médium généralement terminé à chaque extrémité par une terminaison chargée de supprimer tout écho. Le transfert des bits s’y fait en série, la transmission des données sous forme de trame. Dans le 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 maximale choisie pour le bus est souvent de 1 km. Cette longueur peut être augmentée par l’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 son entrée, un retard volontaire est introduit dans la chaîne de traitement du répéteur [Paret 1996]. Ce retard de quelques dizaines ou centaines de nanosecondes est à considérer

66 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués comme une augmentation apparente de la longueur physique du réseau qui peut né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

Un signal émis sur un bus se propage le long du médium. Ceci permet de diffuser facilement 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’un sous-ensemble de stations. Afin de distinguer ces différents cas de figures, la trame doit contenir une information qui définit la destination de l’information transmise. Selon les protocoles de communication, cette information de destination pourra être une adresse physique ou une adresse logique. Une adresse physique identifie un nœud. Utilisée comme information de destination, elle sert à la transmission point à point. Une adresse logique est un nom symbolique qui identifie les éléments d’un ensemble sur le réseau. Elle permet la diffusion d’une information. L’ensemble identifié par l’adresse peut être celui des adresses physiques destinatrices. Les destinataires sont alors ce groupe d’adresses physiques. Il peut également être celui des données transmises dans la trame (on dit que l’adresse logique, souvent appelée ici « identificateur », identifie la nature de l’information contenue dans la trame). Dans ce second cas, seuls les nœuds abonnés à cette adresse acceptent 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 bien utilisé pour l’émission que la réception. Afin d’éviter les collisions et la monopolisation du mé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 rencontrer dans des réseaux où la transmission se fait en large bande : la transmission du signal étant alors unidirectionnelle, le signal se diffuse à partir du point d’émission sur l’ensemble des branches de l’arbre. Les avantages de la topologie bus sont le faible coût du câblage et du médium de transmission. D’autre part, la panne d’une station ne perturbe pas l’ensemble du réseau et le réseau est facile à étendre. Ses inconvénients sont un ralentissement possible du réseau lorsque le trafic est important, des difficultés d’isolation des problèmes qui peuvent apparaître sur le réseau et, en cas de coupure du câble, l’affectation d’un grand nombre 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 signal d’une station à une autre. Chaque coupleur est lié via une liaison point à point avec celui de son voisin jusqu’à arriver à la formation d’un anneau. Le câble utilisé peut être une paire torsadée, des câbles coaxiaux ou des fibres optiques.

Synthèse INRETS n° 45 67 Les réseaux de terrain embarqués dans les transports guidés

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 autre jusqu’à retourner à la station émettrice qui la détruit alors. Une station destinatrice d’une trame 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 avant d’être retransmis après un délai d’une durée d’un bit, le mode transmission dans lequel se met le coupleur lorsqu’il a des données à transmettre. Dans ce mode, les informations d’un nœud sont émises sur la partie aval de l’anneau. En fin de transmission, le coupleur passe en mode écoute dans lequel il pourra retirer la trame du réseau lorsqu’elle lui parviendra en fin de tour. Un troisième mode de fonctionnement du coupleur, le mode dérivation, est utile pour contourner une station rattachée et ainsi l’isoler en cas de dé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 pour déterminer le moment où une station peut insérer une trame dans la boucle. Elle offre un accè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 nombre de nœuds. Ses inconvénients sont l’affectation de l’ensemble du réseau lors de l’apparition d’une défaillance sur un coupleur ou après rupture du médium et les difficultés d’isolation d’un problème sur le réseau. D’autre part, le fonctionnement du réseau est interrompu pour toute reconfiguration. Signalons également que l’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 central qui 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 de l’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 « bus logique ». Une méthode de contrôle d’accès au médium est nécessaire afin qu’un unique nœud ne soit autorisé à transmettre à un instant donné.

68 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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’un nœud (autre que l’unité centrale) sur l’ensemble du système. Sa faiblesse est son nœud de 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 des matériels guidés ferroviaires Les premières topologies des réseaux de communication embarqués dans les matériels roulants ferroviaires ont été l’anneau et le bus. Les réseaux TORNAD et TORNAD*, utilisés dans des trains de voyageurs TGV (TORNAD et TORNAD*) et le métro de Lyon MAGGALY (TORNAD), sont respectivement des réseaux à passage de jeton 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 vers une 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 de conduite en unité multiple des trains de fret. L’évolution suivante a été une décomposition hiérarchique du système réseau de communication embarqué avec la définition d’un « bus train » (Train Bus) et d’un « bus véhicule » (Vehicule Bus) (figure 5). Le bus train sert alors à l’interconnexion de l’ensemble des véhicules du train (rames ou wagons) et supporte notamment les fonctions de numérotation des véhicules et d’intégrité du train (surveillance du nombre de véhicules en cours d’exploitation du train). Ce bus train est un réseau ouvert : le nombre de nœuds connectés n’est pas figé, le réseau accepte l’ajout ou la suppression de

Synthèse INRETS n° 45 69 Les réseaux de terrain embarqués dans les transports guidés

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éformable de véhicules (pas de découplage autorisé de ces véhicules en cours d’exploitation). C’est un 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 des bus véhicule au bus train se fait par l’intermédiaire des nœuds du bus train qui servent alors de passerelle. Cette architecture permet l’utilisation de technologies différentes pour les bus véhicule et le bus train, pourvu que les passerelles adéquates aient été définies et implanté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 et vé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 trois véhicules) et d’un bus train WorldFIP supportant les fonctions de couplage et découplage de triplettes.

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

La figure 7 montre l’utilisation du bus véhicule MVB de TCN pour l’interconnexion d’équipements programmables entre eux et celle de ces équipements avec des capteurs et actionneurs à 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 ensemble indéformable de véhicules. Le bus train utilisé est le bus WTB de TCN. Il a été conçu pour permettre l’interconnexion de véhicules qui, en cours d’exploitation quotidienne d’un train,

70 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués sont couplés ou découplés. Ce bus remplit les exigences de communication UIC 556 définies pour 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’utilisation du 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 and Information System). Deux approches de connexion des équipements au bus train sont notamment étudiées : un nœud central à chacun des véhicules implante toutes les fonctionnalités du système et est directement connecté au bus train ; dans chaque véhicule, les équipements électroniques exécutant les fonctions sont connectés à un bus vé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ème expérimental [Witte 1998]. Enfin, il convient de rappeler que le standard « IEEE P1473, Communications Protocol Aboard Trains » adopté en 1999 repose sur la possibilité d’intercommunication transparente des deux protocoles TCN et LONWORKS l’un avec l’autre, c’est-à-dire de l’existence d’une passerelle entre ces deux protocoles [McGean 1999]. Ce standard définit les configurations permises pour l’utilisation de ces réseaux TCN (tableau 1).

Synthèse INRETS n° 45 71 Les réseaux de terrain embarqués dans les transports guidés

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

Bus VÉHICULE Bus TRAIN Couplage et découplage Exigences de Cas 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 ayant juridiction I Type T Type T Type T Oui Spécifiées dans Sdt. II Type L Type T Type T Oui IEEE 1473-1999 III Type L Type L Type T Oui Non spécifiées dans Sdt. IV Type L Type L Type L Non IEEE 1473-1999 Où Type T désigne le réseau TCN et Type L le réseau LONWORKS.

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 filaires Aprè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 liaison sur 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 dans le spectre électromagnétique. La connaissance de ce spectre est utile dans le cas d’une transmission large bande (par modulation de fréquence). Dans le cas des réseaux de communication locaux filaires, les média rencontrés sont avant tout le cuivre (paire torsadée et câble coaxial), parfois le « courant porteur » (surtout dans la domotique) et plus récemment la fibre optique. Les paragraphes suivants donnent quelques éléments complé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 et enroulés l’un autour de l’autre afin de limiter les interférences extérieures, en particulier

72 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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

en provenance d’autres câbles [Linux_URL]. Plusieurs paires sont groupées dans une mê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 sont utilisées pour la transmission en bande de base et en large bande (voir le paragraphe 3.3 de ce chapitre). Les avantages de la paire torsadée sont sa facilité d’utilisation, son faible coût, sa présence dans de nombreux lieux (câblage téléphonique). Par contre, elle est sensible aux perturbations en provenance de l’environnement. Elle présente une forte atténuation du signal en fonction de la distance et peut nécessiter l’utilisation de répéteurs. Enfin, elle offre 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ême recouvert d’un deuxième conducteur assurant le blindage. Ce deuxième conducteur est constitué de métal tressé. L’ensemble est enfin mécaniquement protégé par une gaine de plastique. Il existe plusieurs types de câbles coaxiaux. Les plus courants sont classés par leur impédance caractéristique, mais ils sont principalement caractérisés par leur impédance

Synthèse INRETS n° 45 73 Les réseaux de terrain embarqués dans les transports guidés

et leur affaiblissement linéique qui varient en fonction de la fréquence de travail et de leur section. 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 et une meilleure protection contre les perturbations de l’environnement. Il permet de transmettre 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, sa lourdeur 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. Les informations 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 applications de la domotique). La modulation du signal haute fréquence permet d’éviter les interférences. Mais l’atténuation du signal en fonction de la distance est importante. Les dé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 plastique entouré par une gaine protectrice. Elle supporte la transmission unidirectionnelle de signaux lumineux. Par conséquent, une configuration en boucle ou l’utilisation de deux fibres optiques sont nécessaires à une transmission bidirectionnelle des données. Dans ce dernier 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 puissance optique d’une onde émise à une longueur d’ondes donnée. Les deux familles de fibres optiques sont les fibres monomodes et les fibres multimodes qui se différencient par leur composition et le mode de propagation des rayons lumineux. Le cœur d’une fibre monomode extrêmement fin (10 mm) permet une propagation quasiment directe. La dispersion modale est alors proche de zéro. La bande passante transmise est presque infinie (> 10 GHz/km). Cette fibre est utilisée essentiellement pour l’interconnexion de sites distants. Deux types de fibres multimodes se distinguent : la fibre à saut d’indice et la fibre à gradient d’indice. La fibre à saut d’indice est constituée d’un cœur et d’une gaine optique en verre de différents indices de réfraction. Cette fibre provoque, en raison de l’importante section du cœur, une grande dispersion des signaux la traversant, ce qui génère une déformation du signal reçu. Le cœur de la fibre à gradient d’indice est constitué de couches successives de verre dont les indices de réfraction sont proches et par conséquent les temps de propagation. La dispersion modale est donc réduite. La connexion sur un médium fibre optique peut se faire par l’intermédiaire d’un coupleur actif ou passif (figure 10). Un coupleur actif agit comme un répéteur, la connexion des coupleurs est alors point à point. Un coupleur passif extrait une portion de l’énergie optique du bus en réception et en injecte directement sur le médium en transmission. Cette connexion multipoint limite, par rapport à la première solution, le nombre de stations sur le bus et également la longueur du médium.

74 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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

Les avantages de la fibre optique sont une très bonne immunité aux bruits, une faible atté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 de 600 Mbit/s sur des distances de l’ordre du km contre quelques kbit/s à quelques centaines de Mbit/s pour un médium métallique), une très large bande passante (de l’ordre du GHz), 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éral l’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 la fibre 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 nombreuses applications dans les entreprises et les institutions. La voie hertzienne est utilisée pour les constituer. On distingue deux types de réseaux sans-fil : les réseaux locaux sans-fil de type boucle locale radio (WLAN, Wireless LAN, BRAN, Broadband Radio Network...) et les réseaux mobiles. Plus d’informations sur l’utilisation de ces réseaux dans les transports ferroviaires pourront être trouvées dans [Berbineau 2001a ; 2001b]. 3. Techniques de transmission et de codage des informations Les différentes topologies et média de transmission ayant été introduits, nous présentons maintenant les techniques de transmission et de codage des informations sur un médium de transmission.

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

Synthèse INRETS n° 45 75 Les réseaux de terrain embarqués dans les transports guidés

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 terminal comporte deux entités, l’« Équipement Terminal de Traitement de Données » (ETTD ou DTE en anglais pour Data Terminal Equipment) et l’ « Équipement Terminal de Circuit de Donné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ées reçues, les données transmises et reçues étant composées de l’information utilisateur et de donné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 de communication 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 en signaux conformes aux caractéristiques du médium de transmission, et inversement, il convertit 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 et de transmission entre deux équipements distants, dans le cas d’une transmission sérielle de données. Ensuite, les techniques de transmission analogique et digitale et le codage des 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 cette fin, deux techniques, les techniques asynchrones et synchrones, permettent la synchronisation de l’émetteur et d’un récepteur. La technique synchrone nécessite la mise en œuvre d’un référentiel temporel commun entre l’émetteur et le récepteur qui leur permet de connaître les instants de dépôt et de prélèvement des informations sur le médium. Ce référentiel commun n’existe pas dans la technique asynchrone [Mackenzie et Bettaz 1988] comme nous allons le voir.

76 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

3.2.2 Technique asynchrone de synchronisation Cette technique est utilisée dans le cas d’un transfert irrégulier ou à débit faible d’informations de petites tailles (blocs de trois à huit bits), typiquement lors du transfert de caractères d’un clavier à un terminal. Elle consiste en l’ajout d’un ou plusieurs bits de début d’information (« bit start ») et d’un ou plusieurs bits de fin d’information (« bit stop ») (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 la rapidité de modulation du signal représentant l’information transmise, va échantillonner le 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 la taille peut être importante. Chaque bloc de données élémentaire constituant l’information transmise est transmis sans bits « start » et « stop ». Cependant, les horloges locales de l’émetteur et du récepteur doivent être maintenues synchrones. Pour cela, un référentiel temporel commun est établi entre l’émetteur et le récepteur par la transmission, entre les deux entités, d’un signal d’horloge déterminant les instants de dépôt et de prélèvement des informations élémentaires [Mackenzie et Bettaz 1988]. Sur de courte distance, cette horloge peut être transmise par l’émetteur sur une ligne de transmission dédiée (cas du bus I2C [I2c_URL]). Sur de longues distances, la synchronisation entre l’émetteur et le récepteur se fait via le codage de l’information élémentaire. Ce codage permet au récepteur de maintenir synchronisée son horloge locale avec celle de l’émetteur tout au long de la transmission lorsqu’il insère l’horloge de l’émetteur dans les données transmises (utilisation d’un codage biphase par exemple) ou qu’il présente assez de transitions [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 de synchronisation mis en début et fin de trame. Le codage de ces éléments binaires peut différer de ceux du champ de données. C’est cette dernière technique de synchronisation synchrone qui est utilisée par l’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 transmission asynchrone.

Synthèse INRETS n° 45 77 Les réseaux de terrain embarqués dans les transports guidés

Figure 13 : technique de transmission synchrone

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). La transmission analogique a été le premier mode de transmission de données [Mackenzie et Bettaz 1988]. Aujourd’hui, les données analogiques et numériques sont aussi transmises numériquement.

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

Type de données Nature des signaux sur le médium (interface ETTD- Nom de l’ETCD de transmission ETCD) (interface ETCD-médium) Analogiques Téléphone analogique représentation des (onde sonore, voix) données par un Analogiques : signal variant de Digitales Modem façon continue (texte) (Modulateur/Démodulateur) Analogiques Codec représentation des (son,...) (Codeur/Décodeur) données par un Digitaux : signal variant de Digitales Emetteur et récepteur digitaux façon discrète

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

3.3.1 Transmission de signaux analogiques ou transmission sur onde porteuse La transmission analogique (transmission large bande) est également appelée transmission sur onde porteuse (la bande de fréquence allouée à la transmission est

78 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

centrée autour d’une fréquence F0, où F0 est non nulle). Elle se fait par modulation des données à transférer (numériques ou analogiques) par une onde porteuse sinusoïdale dont une des caractéristiques (fréquence, amplitude ou phase) varie. On parle alors de modulation d’amplitude, de fréquence et de phase. Les données sont représentées par des valeurs variant continuellement dans un intervalle de temps donné. Ce type de transmission permet le multiplexage fréquentiel (FDM –Frequency Division Multiplexing) sur le médium de communication, c’est-à-dire la division de la bande passante de ce médium en plusieurs canaux de transmission ayant chacun une bande de fréquences allouée différente. La transmission analogique de données digitales utilise un « modem » pour moduler les informations à émettre et les démoduler à la réception (tableau 2). L’utilisation d’un té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 seule pour un médium fibre optique, courant porteur ou éther. Le signal transmis subit une atténuation qui est fonction de la distance. L’utilisation d’amplificateurs sur la ligne de transmission 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 forme d’un signal analogique : – la modulation d’amplitude ASK (Amplitude Shift Keying) qui représente les valeurs par des amplitudes différentes de l’onde porteuse. L’amplitude zéro est souvent choisie et la détection de la présence ou de l’absence de porteuse sert alors pour diffé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 les valeurs par des fréquences différentes. Cette technique est moins susceptible aux erreurs 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 des données en décalant la phase du signal de la porteuse. La figure 14, empruntée à [Summers 2000], montre les signaux transmis sur un médium pour la séquence binaire « 00110100010 ». Les données binaires à transmettre peuvent avoir été codées selon un codage en bande de base (voir le paragraphe 3.3.2 suivant) 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 onde porteuse sinusoïdale. La modulation de données analogiques permet de rendre plus efficace la transmission en augmentant la fréquence et autorise aussi le multiplexage par division de fréquence (multiplexage FDM).

Synthèse INRETS n° 45 79 Les réseaux de terrain embarqués dans les transports guidés

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

Les trois techniques possibles de modulation de données analogiques (modulation d’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]

80 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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 également appelée transmission en bande de base (la bande de fréquence allouée à la transmission est comprise entre zéro, ou une fréquence proche de zéro, et une fréquence Fmax). La transmission en bande de base ne nécessite pas de moduler le signal après codage de l’information. Les suites de bits sont directement émises sur le médium de communication sous la forme de valeurs discrètes. Cette transmission utilise au moins deux composantes continues. Le signal n’étant pas modulé, ce type de transmission n’est possible que sur un mé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. Par conséquent, à partir d’une certaine longueur de médium (spécifique au réseau choisi), une transmission de données en bande de base nécessite l’utilisation de répéteurs qui ré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 donc pas le multiplexage fréquentiel. Nous présentons maintenant le codage de données digitales et analogiques dans le cas d’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 binaires sont représentés par des éléments de signal transmis sous la forme d’impulsions de tension. Le codage des éléments binaires transmis sur le médium s’appelle codage en bande de 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 signal transmis 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és communicantes : le codage du signal binaire rend ou non possible la synchronisation 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écepteur de 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 du signal que d’autres,

Synthèse INRETS n° 45 81 Les réseaux de terrain embarqués dans les transports guidés

– le coût et la complexité : une fréquence du signal de transmission supérieure (et donc un débit des données supérieur) conduit à un coût plus élevé ; certains codes nécessitent une fréquence du signal supérieure au débit des données [Summers 2000]. Nous présentons ci-dessous différents types de codage selon qu’ils codent ou non l’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ément binaire. Ces codages n’offrent pas de capacité de re-synchronisation. – Le codage NRZ apporte une solution à la difficulté d’obtenir un courant nul. Il possède souvent une tension positive et l’autre négative, l’un des niveaux de tension codant l’élément binaire ‘1’, l’autre l’élément binaire ‘0’. Ce codage n’offrant pas de capacité de re-synchronisation, il ne permet pas au récepteur de recaler son horloge par l’intermédiaire du signal reçu en cas de réception d’une longue série d’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 transition du signal en début de transmission d’un élément binaire code cet élément : un ‘1’ est codé par une transition positive (passage d’un niveau de tension bas à haut) ou négative (passage d’un niveau de tension haut à bas), un ‘0’ est codé par une absence de transition. Ce codage est donc basé sur une détection des transitions, détection plus fiable que celle des niveaux (codage NRZ) [Summers 2000]. Contrairement au codage NRZ, il permet au récepteur de recaler son horloge en cas de transmission d’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 le codage bipolaire AMI (Alternate Mark Inversion) dont il est dérivé (figure 17).

82 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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

– 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 codage NRZ et à l’image du NRZI, il permet au récepteur de recaler son horloge en cas de transmission d’une longue série de ‘1’, par contre la transmission de celle de l’é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 deux niveaux en transmettant deux polarités opposées pendant l’intervalle de temps de l’élément binaire [Lagrange et Seret 1998] (figure 18). Ces codages transportent l’horloge de l’émetteur. – Pour le codage Manchester utilisé par la norme IEEE 802.3, la transition significative 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). Dans d’autres protocoles, tels que le protocole WorldFIP, une transition de bas à haut représentera un ‘0’ et une transition de haut à bas un ‘1’. – Pour le codage Manchester différentiel utilisé par la norme IEEE 802.5, une transition 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, qui codait la donnée et l’horloge dans le codage Manchester, ne code plus que l’horloge.

Synthèse INRETS n° 45 83 Les réseaux de terrain embarqués dans les transports guidés

Figure 18 : codage Manchester et Manchester différentiel

Les codages Manchester nécessitent une bande passante supérieure à celle du codage NRZ ; sa vitesse de modulation maximale est deux fois celle du codage NRZ. L’avantage de ce codage est de permettre une synchronisation du récepteur sur l’horloge de l’émetteur à l’aide de la transition en milieu de l’élément binaire. D’autre part, ce codage ne présente pas de composante continue contrairement au codage NRZ. Enfin, une erreur sur 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 la dégradation du signal augmente avec la distance à parcourir. L’utilisation régulière de ré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 distances infé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 techniques précédentes de codage sont alors utilisées. Signalons qu’il existe deux types de modulation pour la conversion des données analogiques 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 du signal. Par exemple, une donnée vocale limitée à 4 000 Hz nécessite 8 000 échantillons par secondes, chaque échantillon est alors assigné à une valeur numérique représentant un 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. A chaque 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.

84 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

3.3.3 Conclusion Des données analogiques ou numériques peuvent être transmises au moyen d’un signal numérique (transmission en bande de base) ou d’un signal analogique par modulation de porteuse (transmission large bande). Certains supports, tels que la paire torsadée et le câble coaxiale, autorisent aussi bien une transmission analogique que numérique. Les média « courants porteurs », fibre optique et éther n’acceptent qu’une transmission analogique. La transmission large bande permet le multiplexage fréquentiel, c’est-à-dire la division de la bande passante du médium de communication en plusieurs canaux de transmission utilisables pour les données, la vidéo et l’audio. Le spectre en fréquence du signal 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 double connexion 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]

Synthèse INRETS n° 45 85 Les réseaux de terrain embarqués dans les transports guidés

La longueur d’un médium pour une transmission en bande de base est classiquement de quelques kilomètres, elle est de quelques dizaines de kilomètres en large bande [Yoon 1998]. Dans le cas des réseaux de communication embarqués dans des trains, la longueur maximale du médium de transmission étant aujourd’hui proche du kilomètre, une transmission en bande de base, qui permet facilement une détection en ligne d’une erreur binaire, 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 les différents supports de transmission filaires et les techniques de transmission adaptées à ces supports. Un premier paragraphe présente maintenant les supports de transmission disponibles sur les matériels roulants ferroviaires guidés pour les bus trains. Un second paragraphe reprend chacun des bus cités en introduction et répertorie pour chacun d’eux les média les plus courants. Les points notamment abordés dans ce second paragraphe sont 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 des ré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 au choix d’un médium de transmission pour le bus train, soit le bus supportant le couplage et 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éhicules roulants, notamment le câble UIC568 défini par l’Union Internationale des Chemins de Fer (UIC) pour permettre l’interopérabilité des voitures du train (référence [UIC568 1996] citée dans [Poitevin 2000]). Ce câble prend en charge des fonctions telles que la commande de l’éclairage, le contrôle de la fermeture des portes ou l’interphonie. Il est composé de 12 conducteurs, arrangés en 3 quartes, et est destiné à des applications par tensions continues ou basses fréquences. L’utilisation de la paire interphonie de ce câble pour la transmission d’informations (bus de train) est admise par la fiche UIC 556 [UIC556].

86 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

La SNCF a essayé d’utiliser cette paire pour la télécommande de locomotives par la technique 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/s que pour un nombre limité de voitures et à la condition d’accepter un taux d’erreurs important [ROSIN_URLc]. L’UIC a alors défini le câble UIC 558 (figure 21) comportant 4 quartes et 1 paire torsadée blindée unitairement pour les applications nécessitant une bande passante importante (référence [UIC558 1996] citée dans [Poitevin 2000]). C’est cette paire torsadée blindée que le réseau TCN utilise pour le bus WTB. Ces câbles UIC (UIC 568 ou UIC 558) sont installés de chaque côté des véhicules. Par conséquent le médium de transmission 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 le bus train sont donc la paire interphonie du câble UIC 568 ou la paire torsadée blindée du câble UIC 558. D’autres média peuvent être envisagés pour les bus train et véhicule tels qu’une paire d’alimentation en continue (médium courant porteur) [Chervet 1998] ou un média installé spécifiquement [Poitevin 2000]. Par exemple, les essais effectués avec la technologie 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 du médium du bus véhicule est optionnelle d’après [ROSIN_URLb ; TCNSpecifications 1998].

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 fonction de leur caractère dédié ou non au domaine ferroviaire. Ainsi, seront tout d’abord considérés les réseaux MUX G, TORNAD et TCN, puis les réseaux BITBUS, WorldFIP et PROFIBUS d’une part et CAN et LONWORKS d’autre part.

Synthèse INRETS n° 45 87 Les réseaux de terrain embarqués dans les transports guidés

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 pilotage et le fonctionnement en unité multiple. Le pupitre de la cabine de la locomotive menée est alors commandé à distance par la cabine de réversibilité ou par la locomotive qui mène le train (figure 22). Le système de multiplexage est redondé et utilise deux fois une paire 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 machine depuis la cabine de réversibilité » et « les signalisations issues de la machine que le conducteur reçoit sur le pupitre » [Boutonnet et Chateaureynaud 1989a]. Elles sont fournies par des contacts électriques qui transmettent au système de multiplexage des tensions 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 un préambule pour la synchronisation de l’horloge du récepteur avec celle de l’émetteur.

88 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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 informations contenues dans [Boutonnet et Chateaureynaud 1989a].

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

1 Type du médium de transmission Câble UIC (1 paire de conducteurs de la ligne de sonorisation UIC redondé, 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)

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 fibre optique. Dans [Duhot 1989], Alsthom utilise la paire torsadée blindée dont le coût est moindre. Sa longueur est de 900 m pour le TGV A. La topologie du réseau TORNAD est l’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] :

Synthèse INRETS n° 45 89 Les réseaux de terrain embarqués dans les transports guidés

– afin d’éviter des phénomènes d’éblouissement, le médium TORNAD est interrompu par des coupleurs isolant et ne propageant pas les défauts ; des transformateurs assurent l’isolement galvanique ; – le problème d’affaiblissement sur la paire torsadée blindée est résolu par la régénération du signal par les coupleurs ; – le réseau est protégé d’une panne de coupleur par la connexion des coupleurs au ré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 la fibre 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 de trame 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’information transmis (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 les informations 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 optique de transmission (câble UIC utilisable) 2 Topologie du réseau ANNEAU 3 Nombre maximal 12 équipements dans le cas de pas d’exemple de 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 dans le cas du TGV A 4 Nombre maximal Les coupleurs régénèrent de 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 sont ceux 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 de 1 Mbit/s pour le bus train WTB. Le bus véhicule MVB comporte un ou plusieurs segments de bus qui peuvent être reliés par des coupleurs. Ces coupleurs sont des répéteurs pour l’interconnexion de différents média électriques et des coupleurs en étoile utilisés pour former un bus dans le cas d’un médium fibre optique. Trois types de médium de transmission sont définis dans la norme du réseau TCN, deux électriques (ESD et EMD) et un optique (OGF).

90 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

– Le médium ESD (Electrical Short Distance) utilise une paire de conducteurs de préférence torsadée et blindée. Les émetteurs-récepteurs de ligne doivent être conformes à la norme ISO 8482 (RS-485). Ce médium peut atteindre une longueur de 20 mètres et interconnecter jusqu’à 32 entités par segment, chaque segment comprenant un unique maître. Il est prévu pour tout lieu où une isolation galvanique 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ée qui est terminée à chaque extrémité du bus par une impédance de ligne de 120 Ohm. Ce médium est d’autre part isolé galvaniquement par transformateur. Il peut atteindre une longueur de 200 m et supporte un maximum de 32 entités par segment. – Le médium OGF (Optical Glass Fibre) est formé d’une paire de fibres optiques qui forme une liaison point à point bidirectionnelle (full-duplex). Une paire de fibres peut 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 atteindre 2 000 m. Il est prévu pour l’interconnexion d’équipements sur de longues distances ou bien pour les environnements hautement perturbés, tels que celui des locomotives. Le bus train WTB comporte (figure 24) : – un « Bus Train » pour l’interconnexion des véhicules du train, ce bus doit être conforme au protocole WTB, et – des « nœuds », qui sont les équipements connectés au bus WTB servant de passerelle 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 autorise l’interconnexion de 32 nœuds et couvre une distance de 860 mètres (des distances plus

Synthèse INRETS n° 45 91 Les réseaux de terrain embarqués dans les transports guidés

grandes avec un maximum de 62 nœuds peuvent être réalisées). Dans le train, le câble WTB est redondé afin que le bus soit connecté aux deux connecteurs situés à chaque extré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 des transformateurs. 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 et permettent un débit de 1 Mbit/s sur le bus. Le bus WTB supporte la duplication du médium mais pas celle des nœuds. Un nœud émet toujours sur les deux lignes et ne reçoit les informations que de l’une ; il utilise l’autre pour vérifier que la ligne de réception est toujours 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 de bus. Ils relient les deux sections de câbles auxquels ils sont connectés afin de former le bus. 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 relient chacune à 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 la phase d’initialisation du bus train. Cette phase, appelée « inauguration » du bus, est contrôlée par le nœud maître du bus WTB. Elle permet notamment l’attribution dynamique 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

92 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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 bus optionnelle 1 Type du médium ESD EMD OGF Utilisation d’une paire de transmission (RS-485 ; (avec isolation (fibre métallique torsadée sans isolation par optique) blindée dédiée (du câble galvanique) transformateur) UIC 558 s’il existe) 2 Topologie du BUS BUS Coupleur BUS ré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 maximal de 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 (codage Manchester) (seulement 500 kbit/s si ancien câble UIC568) Où l’acronyme ESD signifie Electrical short distance, EMD Electrical Medium Distance et OGF Optical Glass Fibre.

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 compte des retours d’expérience d’applications comme celle du frein électronique qui devrait permettre l’augmentation de la longueur des trains de marchandise. Une longueur de 2 250 m est d’ailleurs en expérimentation avec la technologie LONWORKS à l’occasion des recherches 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éseau spécifie, pour un câble métallique, une longueur maximale du bus véhicule avec isolation galvanique par transformateur de 200 mètres. Par contre, l’ensemble des informations pré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 selon que leur méthode d’accès au médium est de type scrutation ou contention (voir le chapitre 4).

Synthèse INRETS n° 45 93 Les réseaux de terrain embarqués dans les transports guidés

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 sont les bus BITBUS, WorldFIP et PROFIBUS. a. Intel BITBUS/ IEEE 1118 Le réseau BITBUS utilise le standard RS-485 (paire torsadée) pour la couche physique et le standard SDLC (Synchronous Data Link Control – protocole de la couche liaison 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 codage en bande de base NRZI. La trame SDLC comprend en fin et début de la trame de la couche liaison de données un champ « flag » dont le codage permet au récepteur, en début de réception de trame, de se 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éteur de 300 m et avec un répéteur de 900 m. Le débit du bus est limité à 62,5 kbit/s dès que deux 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 Optique de transmission (0/5V) (RS 485) 2 Topologie du réseau BUS 3 Nombre maximal de 28 esclaves par segment en plus stations par segment, de la station maître, (249 avec et sans répéteurs esclaves au maximum) (remarque : la liaison RS485 accepte 31 récepteurs) 4 Nombre maximal 1 10 Contrainte : le début d’un de répéteurs message doit être détecté dans un délai inférieur à la durée de 2 bits, soit une troncature par répéteur d’une valeur maximale de 2 bits ; la fin du message doit être détectée dans 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 fibre optique (tableau 7). Un débit de 1 Mbit/s pour une longueur maximale sans répéteur de

94 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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

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

1 Type du médium de fil métallique – paire torsadée fibre optique transmission 2 Topologie du réseau BUS Connexion point à point, utilisation de coupleurs actifs en étoile 3 Nombre maximal de 256 256 stations par segment sans répéteur

4 Nombre maximal de ND7 à la 4 3 4 4 répéteurs date du 03. 1998 5 Longueur sans répéteur 5 000 m 1 000 m 500 m 1 600 m ? ? (avec répéteurs) (ND) (5 km) (2 km) (7 000 m) 6 Débit du réseau 31,5 kbit/s 1 Mbit/s 2,5 Mbit/s 1 Mbit/s 2,5 Mbit/s 5 Mbit/s Des exemples de circuits de ligne pour le réseau WorldFIP sont les suivants [WorldFIP_URL]. Le circuit de ligne « CREOL » (CREOL Line Driver) avec isolation par transformateur tourne à 1 Mbit/s ou 2,5 Mbit/s et a une interface pour les contrôleurs de communication FIPIU et FIPCO1 (voir aussi le paragraphe 4.5 du chapitre 2). Le circuit de ligne FIELDRIVE fournit une interface entre le médium et un processeur de communication tel que FULLFIP2 sans isolation. L’utilisation du transformateur FIELDTR permet alors une isolation du médium WorldFIP pour des débits de 31,25 kbit/s, 1 Mbit/s et 2,5tMbit/s.

Le codage utilisé pour la transmission des données est le Manchester. Il permet la transmission simultanée de l’horloge et de la donnée. Deux champs ont un codage particulier 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 aussi bien à la synchronisation au niveau de l’élément binaire qu’au niveau du bloc d’information transmis (délimitation des informations en provenance de la couche liaison de 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

7 ND : Non défini.

Synthèse INRETS n° 45 95 Les réseaux de terrain embarqués dans les transports guidés

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 liaison EIA RS-485. Les coupleurs de lignes cibles sont bas coût et peuvent ou non être isolés galvaniquement de la ligne. Des terminaisons de lignes sont nécessaires, en particulier 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 pour des environnements nécessitant une haute sécurité intrinsèque et pour améliorer la compatibilité électromagnétique. Cette version accepte différentes topologies (notamment la topologie arbre). Les coupleurs de lignes consomment moins de courant 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 liaison RS 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 [Profibus 1999] (tableau 10). Tableau 8 : caractéristique de la liaison RS 485 du bus PROFIBUS [Profibus 1997 ; 1999 ; EN_50170_2 1996]

Liaison RS 485 PROFIBUS DP ET FMS 1 Type du médium de Liaison RS 485 : paire torsadée blindée ou non transmission (blindage facultatif selon environnement CEM) 2 Topologie du réseau BUS (« topologie linéaire ») (« dénomination particulière au protocole »), Terminaison active Terminaison de ligne 3 Nombre maximal de 32 sans répéteur stations par segment 127 avec répéteurs 4 Nombre maximal de 3 répéteurs (Lignes de jonctions limitées aux débits ≤ 1,5 Mbit/s) 5 Longueur pour un câble 1 200 m 1 000 m 400 m 200 m 100 m de Type A Longueur pour un câble de 1 200 m 600 m 200 m 70 m Type B 6 Débit du réseau pour un 9,6 kbit/s 187,5 kbit/s 500 kbit/s 1,5 Mbit/s 12 Mbit/s câblage de type A ou B 19,2 kbit/s ou 93,75 kbit/s Câble de type A : impédance 135 à 165 Ω (f = 3 à 20 MHz) ; capacité < 30 pF/m ; résistance de boucle 110 Ω/ 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 non précisée ; section du conducteur > 0,22 mm2. (codage NRZ)

96 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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 une longueur de 1 km. Les valeurs du premier couple « débit longueur » se rapprochent de celles 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 de l’émetteur et du (des) récepteur(s). Par contre, la trame PROFIBUS code ses champs d’information selon le format des caractères UART. Ainsi pour une information utile de 8 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 asynchrone permet une synchronisation octet et évite une trop forte dérive au niveau binaire entre les horloges 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, profil PROFIBUS PA (Transmission CEI 1158-2, application chimie applicatif : et pétrochimie ; elle autorise la sécurité intrinsèque et la téléalimentation des modules via le bus.) 1 Type du médium de Paire torsadée blindée ou non/ transmission Transmission CEI 1158-2 2 Topologie du réseau BUS (« dénomination (« topologie linéaire et arborescente ») particulière au protocole »), Terminaison de ligne passive Terminaison de ligne 3 Nombre maximal de 32 sans répéteur stations par segment 126 avec répéteurs 4 Nombre maximal de 4 répéteurs 5 Longueur sans répéteur La longueur maximale est de 1 900 m Elle 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)

Synthèse INRETS n° 45 97 Les réseaux de terrain embarqués dans les transports guidés

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 sont les 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 de longueur 700 mètres utilisant pour bus train et bus véhicule la technologie CAN. Le train ayant servi pour les essais connectait 22 wagons à une locomotive. La connexion des nœuds du bus véhicule se faisait par l’intermédiaire de relais (figure 27). Le débit choisi pour le bus train était de 10 kbit/s, laissant ainsi une marge par rapport au débit maximal théorique de 70 kbit/s pouvant être obtenu avec un câble de longueur 1 000 m (longueur tenant compte de celle du train et des méandres du câble à l’intérieur du train). Le bus vé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. Le médium de transmission d’un réseau CAN peut ainsi être une paire torsadée, un câble en nappe, le courant porteur ou la fibre optique. Elle accepte par exemple pour la paire torsadée une liaison RS 485. Il existe également dans le commerce des émetteurs récepteurs de ligne spécifiques pour ce même médium. D’après [Paret 1996], des liaisons CAN propriétaires à infrarouges existent également. Les valeurs données dans le tableau 11 sont celles couramment fournies dans les documents CAN pour un médium « paire torsadée différentielle ».

98 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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

1 Type du paire torsadée différentielle médium de 2 Topologie BUS du réseau Terminaison Terminaison : résistance de terminaison de ligne 3 Nombre 30 sans répéteur maximal de stations par segment 4 Nombre maximal de répéteurs 5 Longueur en 10 km 6,7 km 3,3 km 1,3 km 620 m 530 m 270 m 130 m 40 m 10 m mètres 6 Débit du 5 10 20 50 100 125 250 500 1 1,6 réseau (*) kbit/s kbit/s kbit/s kbit/s kbit/s kbit/s kbit/s kbit/s Mbit/s Mbit/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 de 70 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 est dédiée aux applications bas débit, soit inférieure à 125 kbit/s (« Véhicules routiers. Communication en série de données à basse vitesse. Partie 1 : généralités et définitions. Partie 2 : réseau local à commande à basse vitesse (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 de réseau de communication à vitesse élevée (CAN) »). Différents émetteurs/récepteurs CAN, conçus pour l’automobile, peuvent être trouvés dans le commerce, par exemple des transceivers tolérants aux fautes pour des débits inférieurs à 125 kbit/s et un double médium cuivre, des transceivers haut débit pour des débits supérieurs à 125 kbit/s et jusqu’à 1 Mbit/s sur double médium cuivre et enfin des transceivers pour un médium simple fil et des débits également inférieurs à 125 kbit/s.

Les fortes contraintes « débit-longueur » du réseau CAN mises en évidence par le tableau 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 sur l’élément binaire en cours d’émission afin de cesser de suite, en cas de contention, toute transmission avant le temps imparti pour celle de l’élément binaire suivant (voir le paragraphe 4.2 du chapitre 4). Ces contraintes imposent de prendre quelques précautions dans l’utilisation de ré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 de rebouclage immédiat de la sortie vers l’entrée », un retard, généralement de l’ordre de

Synthèse INRETS n° 45 99 Les réseaux de terrain embarqués dans les transports guidés

200 à 300 ns, est introduit pour le passage du ‘0’ au ‘1’ et le plus rapidement possible pour celui du ‘1’ vers ‘0’ [Paret 1996]. Cette introduction d’un retard supplémentaire par le répéteur est à considérer comme une augmentation de la longueur physique apparente du réseau. Cette longueur est de l’ordre de 40 à 50 mètres de fil supplémentaire sur le réseau pour un médium standard où le signal se propage à environ 5 ns/m et pour un retard introduit 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’est pas pour un réseau CAN fonctionnant à 1 Mbit/s, soit dont la longueur maximale du médium est d’environ 40 m. La figure 28, extraite de [Paret 1996] est un exemple d’utilisation de répéteurs avec la technologie CAN. [Paret 1996] attire l’attention sur la « segmentation multiple en plusieurs tronçons, permettant de réduire apparemment l’influence d’un cumul sériel des retards [...] 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érie d’au moins six éléments binaires identiques. Il sert à distinguer cette information d’un signal d’erreur (paragraphe 4.2.2 du chapitre 4) ou d’une fin de trame (sept bits récessifs plus trois bits récessifs de délai inter trame). Il permet également de remédier au manque de 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 également que le protocole CAN définit aussi une plage de tolérance entre les horloges générées et celle de la détection d’un bit. Enfin, le top de synchronisation entre l’émetteur et le récepteur est donné par le champ SOF (Start of Frame) de début de la trame CAN. Ce champ, ainsi que le champ de fin de trame EOF (End of Frame) permettent la synchronisation au niveau du bloc d’information transmis.

100 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

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

Bien que le codage du protocole CAN soit à la base un codage NRZ, le bourrage de bit réalisé enlève au signal NRZ sa composante continue et permet alors une isolation galvanique aussi bien par transformateurs que par optocoupleurs. b. LONWORKS La couche physique n’est pas spécifiée dans le protocole LonTalk du réseau LONWORKS. Par conséquent, le réseau accepte une large gamme de média telle que la paire 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édia de transmission choisis. Par exemple, ceux définis pour la paire torsadée sont les paramètres de terminaison de bus et de « topologie libre ». Les deux topologies incluent une transmission du courant sur le lien. Pour cela, deux types de câble peuvent être utilisés. L’un a cinq fils, deux pour la transmission des données, deux pour l’alimentation et un pour le blindage. L’autre, utilisé dans les systèmes « link power », a seulement deux fils 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 au tableau 12. Le circuit utilisé dans le projet franco-allemand FEBIS du frein électronique est le PLT-10A permettant une transmission sur courant porteur [Grasso et al. 2001]. Ce circuit offrant un débit de 10 kbit/s (tableau 13) n’est plus en fabrication et n’a pas à ce jour de remplaçant. Les émetteurs-récepteurs LONWORKS cités dans les tableaux 12 et 13 (à l’exception du PLT-10 A) sont disponibles chez Echelon Corporation.

Synthèse INRETS n° 45 101 Les réseaux de terrain embarqués dans les transports guidés

Tableau 12 : caractéristique de la paire torsadée LONWORKS [Schickhuber et McCarthy 97a ; 1997b ; Echelon_URL]

1 Type du médium Paire torsadée Paire torsadée transportant de transmission (récepteur/émetteur TPT8/XF-78, TPT/XF- l’alimentation et les données 1250, FTT/FT-10A, RS 485) (LPT-11) 2 Topologie du BUS Combinaison BUS Combinaison réseau Double terminaison BUS et Double BUS, (« dénomination ANNEAU terminaison ETOILE, LONWORKS ») (« topologie ANNEAU Terminaison de libre ») (« topologie ligne libre ») 3 Nombre maximal 64 128 Fonction de la sortie du de stations par sans répéteur sans répéteur « transceiver » LPT-11 : segment 128 si sortie de 5 V et 25 mA 64 si sortie de 5 V et 50 mA 32 si sortie de 5 V et 100 mA 4 Nombre maximal de répéteurs 5 Longueur 2 700 m 130 m 500 m 2 200 m 500 m 6 Débit du réseau 78 kbit/s 1,25 Mbit/s 78 kbit/s 78 kbit/s composant composant composant composant LPT-11 TPT/XF-78 TPT/XF-1250 FTT/FT-10A (codage Manchester différentiel)

Tableau 13 : médium courant porteur [Echelon_URL]

1 Type du médium de Courant porteur transmission 6 Débit du réseau 10 kbit/s à 10 MHz 5 kbit/s PLT9-10 A PLT-22 Technique de DS (Direct sequence spread) BPSK (Binary Phase Shift Keying) transmission spectrum avec un récepteur DSP amélioré Bande de fréquence 100-140 kHz (à 10 MHz) bande primaire : 125-140 kHz bande secondaire : 110-125 kHz

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

102 Synthèse INRETS n° 45 Couche physique des réseaux de communication filaires embarqués

4.3 Conclusion Il est difficile d’effectuer une conclusion générale d’après les informations fournies ci-dessus. Les valeurs données pour les longueurs et débits sont en effet indicatives car se reportant chaque fois à un type de médium particulier. D’autre part, le choix des média utilisés ou testés aujourd’hui dans le ferroviaire varient selon le choix du réseau. On peut citer par exemple les câbles UIC 568 ou UIC 558 en bande de base pour le bus train WTB de 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 ces ré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 de type paire différentielle (tableau 15).

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 le Isolation galvanique codage par transformateur possible MUX G ? ? TORNAD HDB3 Oui, transitions garanties oui Manchester Horloge codée (fibre optique) 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 et NRZ Horloge non codée, mais ? FMS codage des caractères de (oui par optocoupleur) la trame au format UART avec bit start et bit stop, d’où des transitions garanties BITBUS NRZI CAN NRZ avec bourrage Oui, transitions garanties oui de bit par le bourrage de bit

LONWORKS (pour les Manchester différentiel Horloge codée transceivers cités au tableau 12)

Synthèse INRETS n° 45 103 Les réseaux de terrain embarqués dans les transports guidés

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 ; type A : 32 ; (70 m ; 1,5 Mbit/s) (200 m ; 1,5 Mbit/s

CAN 30 ; (10 m ; 1,6 Mbit/s) 30 ; (130 m ; 500 kbit/s) 30 ; (40 m ; 1 Mbit/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 ; UIC 568 : 32 ; (860 m ; 1 Mbit/s) (860 m ; 500 kbit/s) (1 ou 2 nœuds par véhicule, 22 véhicules, extension possible de la longueur du 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; (1200m; 62,5 kbit/s)

104 Synthèse INRETS n° 45 Chapitre 4

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

1. Introduction Le 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 du modèle de référence OSI). Ce contrôle d’accès au médium a pour objectif un partage optimal du canal de transmission entre les abonnés. Les méthodes d’accès au médium sont variées et si quelques couches MAC sont normalisées IEEE, beaucoup de réseaux ont 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])

Synthèse INRETS n° 45 105 Les réseaux de terrain embarqués dans les transports guidés

Dans le cas d’une approche synchrone, une capacité spécifique du canal de transmission est réservée à un nœud. Cette technique, non optimale pour les réseaux LAN et MAN en raison de leur trafic irrégulier, est utilisée dans la commutation de circuit par les techniques synchrones FDM (Frequency Division Multiplexing – technique de partage du canal par multiplexage fréquentiel) et TDM (Time Division Multiplexing – technique de partage du canal par multiplexage temporel). Selon l’approche asynchrone, on peut distinguer les techniques d’accès contrôlés Round 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 au cours duquel il a l’autorisation de transmettre une certaine quantité de données limité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 (Time Division Multiplexing), pour laquelle un nœud souhaitant transmettre des données réserve au préalable des intervalles de temps pour une période étendue voire indé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 de protocoles à compétition). Ici, les nœuds tentent d’émettre indépendamment les uns des autres provoquant parfois des collisions11 qui nécessitent l’existence d’une stratégie de ré-émission ultérieure de l’information. Cette technique repose sur l’algorithme CSMA (Carrier Sense Medium Access) pour lequel tout nœud avant d’émettre doit détecter une non-activité sur le bus pendant un intervalle de temps défini par le protocole du réseau étudié. Cette technique, adaptée au trafic de données événementiel, est efficace pour un trafic normal de données, mais le réseau peut 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 une approche centralisée, un contrôleur central gère l’accès au réseau des autres nœuds. Dans une approche distribuée, les stations réalisent collectivement une fonction de contrôle d’accès au médium pour déterminer l’ordre dans lequel elles vont transmettre. Un avantage 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 les communications 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 plus complexe.

10 Contention : situation qui se produit lorsque plusieurs stations se mettent à transmettre simultanément sur le bus de communication [VAN 1989] ; état du bus lorsque deux stations ou 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 de plusieurs signaux d’origine interne (stations connectées au bus) ou externe (bruit). Synonyme : interférence [VAN 1989].

106 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

Parmi les trois techniques précédemment citées, les protocoles des réseaux de communication filaires adoptés pour les matériels roulants ferroviaires utilisent les techniques 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 ces protocoles d’accès au médium. Ensuite, pour chacun des réseaux concernés par la méthode introduite, des caractéristiques propres à ces réseaux seront expliquées et le format des trames de communication, au moyen desquelles se font les échanges sur le bus, 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 par passage de jeton sont l’anneau (réseau token-ring ou à passage de jeton sur anneau) et le bus (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 servi pour la spécification de la norme IEEE 802.5 du réseau à jeton sur anneau. Cette norme et le réseau token-ring d’IBM ont quelques différences mais restent totalement compatibles, 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 au mé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 par l’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 une station lui donne donc le droit d’accès au médium. Aucune collision ne peut alors se produire. Dans le cas du réseau à jeton sur anneau, l’ordre de circulation est celui défini par la connexion des stations. Dans celui d’un réseau à jeton sur bus, les stations sont organisées logiquement selon un anneau virtuel qui définit la place de chacune [Rolin 1990]. Chaque station a un successeur logique qui ne dépend plus de la connectique mais qui est défini en utilisant les adresses des nœuds.

Synthèse INRETS n° 45 107 Les réseaux de terrain embarqués dans les transports guidés

Figure 2 : jeton sur anneau et jeton sur bus

Deux types de trames sont définis pour ce protocole de communication, la trame jeton et la trame d’information. Une station ayant des données à émettre se saisit de la trame jeton lorsqu’elle lui parvient et modifie (protocole IEEE 802.5) un élément binaire de cette trame qui la transforme en séquence de début de trame [CISCO_URL]. Les informations sont ensuite insérées dans la trame. La trame jeton ne sera ré-émise sur le réseau que lorsque la trame information aura parcouru l’anneau (réel ou virtuel) et sera revenue à la station émettrice. Lorsque la trame arrive à la station destination, celle-ci recopie localement l’information contenue. En fin de tour, la station émettrice la retire et peut vérifier l’intégrité du contenu de cette trame retournée. Elle re-transmet à la place une trame jeton (figure 3).

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

108 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

Il existe des protocoles token-ring dont la gestion du jeton varie légèrement de cette mé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édiatement après la transmission de la trame d’information. Une autre station émettrice peut alors se saisir du jeton et émettre une trame d’information à la suite d’une précédente avant que celle-ci n’ait effectué le tour complet du réseau (figure 4). Conformément à la méthode IEEE 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 de hautes priorités d’accéder plus fréquemment au réseau. Pour cela la trame d’information contient 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 jeton peuvent se saisir du jeton. Après que la trame jeton ait été saisie et changée en trame

Synthèse INRETS n° 45 109 Les réseaux de terrain embarqués dans les transports guidés

d’information, seules les stations de plus grandes priorités que la station émettrice peuvent réserver le jeton pour le prochain tour. Quand le jeton suivant est généré, il contient alors la valeur de priorité la plus haute parmi les stations ayant souhaité le réserver. Les stations qui augmentent le niveau de priorité du jeton remettent l’ancienne priorité après avoir réalisé leur transmission [CISCO_URL]. Des fonctions de maintenance de la boucle sont dupliquées sur chaque station afin de maintenir les communications sur le réseau [Rolin 1990]. Ces fonctions sont celles de l’initialisation de la boucle, de la régénération du jeton, de l’addition d’une nouvelle station 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 de contention exécuté périodiquement. Afin de ne pas bloquer le réseau en cas de perte du jeton et de permettre un accès au réseau équitable à toutes les stations, un délai de retransmission d’une trame jeton, qui tient compte du délai de transmission et de circulation 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 sur anneau [Duhot 1989]. La gestion du réseau TORNAD est assurée par un coupleur contrôleur qui génère le jeton à l’initialisation du réseau et veille à le régénérer en cas de disparition. Lors de l’initialisation du système, un coupleur prend le statut de « contrôleur », un autre celui « d’Equipement potentiellement contrôleur » (EPC) de façon à pallier la dé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 un contrô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 telles que 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 la reconfiguration 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éteur bidirectionnel et mémorise les trames qui lui sont adressées, – « le mode émission » dans lequel un coupleur passe pour émettre sa trame d’information après avoir récupéré celle du jeton qu’il régénérera en fin d’émission du 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 IEEE 802.5. Comme dans le cas du protocole FDDI, le jeton n’est pas gardé après transmission de la trame. Une station en mode émission saisit le jeton, transmet sa trame

110 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données 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 trame d’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 lui revienne 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 transmission ou un court-circuit, le réseau peut être reconfiguré en « mode Ping-Pong » (figures 5 et 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]

Synthèse INRETS n° 45 111 Les réseaux de terrain embarqués dans les transports guidés

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 dynamiquement de la façon suivante. Après une détection multiple de perte de jetons, une tentative de reconfiguration en boucle est effectuée en émettant un jeton trois fois dans un sens, puis trois fois dans le sens opposé. En cas d’échec, les coupleurs de part et d’autre de la cassure de l’anneau sont déterminés. Ils passent alors en « mode extrémité » (de bus). Le nouveau 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 trois types d’adressage, un adressage simple pour la diffusion d’un message auprès d’un destinataire (5 bits permettent d’adresser jusqu’à 32 entités), un adressage de groupe pour la diffusion du message auprès d’un ensemble d’équipements et enfin un adressage général pour une diffusion du message à tous les équipements du réseau (3 bits utilisés pour la définition de 8 groupes) [Duhot 1989]. L’adressage de groupe autorise la définition d’un maximum de sept groupes spécifiés statiquement à l’initialisation ou dynamiquement en cours d’exploitation. TORNAD réserve le mode d’adressage général aux applications de surveillance et de gestion du réseau.

Figure 7 : structure de la trame TORNAD

2.2.2 TORNAD*

Le réseau TORNAD* est un réseau à jeton sur bus. Nous n’avons pas trouvé plus d’information sur ce réseau.

112 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

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 une méthode d’accès par passage de jeton sur bus (figure 8). Le protocole MVB utilise cette méthode pour assurer une redondance de l’administrateur de bus maître, soit du contrô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 par différents maîtres en autorisant la prise de contrôle du bus tour à tour par les maîtres.

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

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. Le contrôle d’accès au médium est géré par une unité centrale (topologie étoile), qui donne la parole à tour de rôle aux stations, ou à un contrôleur unique (topologie bus), qui alloue l’utilisation du bus. Une station (ou nœud) ne peut transmettre des données que sur scrutation 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 communications se font alors sous forme de télégrammes, c’est-à-dire d’un ensemble de deux trames composé d’une trame de requête maître et d’une trame de réponse esclave (figure 9).

Synthèse INRETS n° 45 113 Les réseaux de terrain embarqués dans les transports guidés

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

La transmission des informations sur un bus exploite la capacité de diffusion de la technologie 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 des fonctions de consommation ou de production. A un instant donné, il ne peut exister qu’un unique producteur d’une variable identifiée au moyen du champ d’adresse de la requête du contrôleur. Ce producteur transmet la variable attendue en réponse à la requête. Cette variable 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énomination WorldFIP) invite le producteur d’une variable à la transmettre en utilisant l’adresse logique (l’idendificateur ID) de cette variable. Les algorithmes utilisés lors de la phase pé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 reprise devra alors exister.

114 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

Les réseaux utilisant une technique de polling (scrutation) sont WorldFIP, MVB et WTB du réseau TCN, PROFIBUS et BITBUS. La topologie utilisée pour les applications ferroviaires embarquées est le bus dont les capacités de diffusion sont exploitées par les protocoles 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 à intervalle de temps déterminé ; – un trafic apériodique (sporadique ou événementiel) pour les variables et messages initiés ponctuellement sur demande d’une entité esclave. Pour que ces deux types de trafic soient possibles, le contrôleur du bus12 divise l’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) ou périodes de base (TCN) dont le nombre est fixé en fonction des besoins de l’application et en conformité avec les caractéristiques propre du protocole. Chaque cycle élémentaire ou période de base est décomposé à son tour en deux phases, une première phase affectée au 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.

Synthèse INRETS n° 45 115 Les réseaux de terrain embarqués dans les transports guidés

La durée de chaque cycle élémentaire est identique. Elle est soit imposée par le protocole, soit par les besoins de l’application en conformité avec les contraintes du protocole (tableau 1). Cette durée correspond à la fréquence d’interrogation maximale d’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émentaire Dé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 variables périodiques devant être rafraîchies lors du cycle considéré. Celle de la phase apériodique l’est par la durée du cycle élémentaire restant disponible après la réalisation de la phase pé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 des phases périodiques d’un macro-cycle, est définie par le contrôleur à l’initialisation de l’application. Cette liste définit la table de scrutation du contrôleur (figure 13). Elle est construite en fonction, d’une part, des périodes de rafraîchissement des informations imposées par l’application et, d’autre part, de la durée des échanges nécessaires à la ré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é leurs caractères événementiels, il n’existe pas de table de scrutation pour autoriser la

116 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données 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 de cet échange sous contrôle du maître. La requête d’une entité pour une scrutation de variable ou d’un message apériodique se fait dans le cas du protocole : – WorldFIP Lors de la phase périodique par indication par l’entité source de la variable scrutée au 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 phases apériodiques, le contrôleur maître scrute en séquence les nœuds à la recherche d’une signalisation de messages en attente. Pour raccourcir cette recherche, un nœ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 un transfert de données sporadiques. Le maître le scrutera alors de nouveau lors de la phase 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 est remplacée par une phase d’arbitrage exécutée sur un ensemble de phases apé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 de l’ensemble des entités. Cette interrogation collective peut engendrer des réponses simultanées et provoquer ainsi des collisions destructives. Dans ce cas, une nouvelle interrogation est alors réalisée par l’administrateur de bus maître en réduisant de moitié le groupe destinataire (sous-groupe des stations paires par exemple). En cas de nouvelle collision, ce processus est réitéré jusqu’à obtention d’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 sont utilisées pour (figure 14) : – le transfert de variables de contrôle temps critique (phase périodique et apé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 le service messagerie MMS (Messaging Services) de la couche application. La configuration de la liste de scrutation de l’arbitre de bus se fait à l’initialisation, en fonction des caractéristiques des équipements connectés.

Synthèse INRETS n° 45 117 Les réseaux de terrain embarqués dans les transports guidés

Figure 14 : allocation du médium du protocole WorldFIP

3.2.2.2 Format de la trame WorldFIP Toutes les trames WorldFIP commencent, après un champ de début FSS, par un champ de contrôle d’un octet qui permet aux abonnés de reconnaître la nature de la trame qu’ils reçoivent. Elles se terminent toutes par une séquence de contrôle d’intégrité de la trame (FCS de deux octets) suivie d’un délimiteur de fin de trame (figure 15).

Figure 15 : format de la trame WorldFIP

Plusieurs types de trames, construits sur le format de la figure 15, sont définis afin de réaliser les échanges de variables et de messages selon un trafic périodique et apé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’esclave producteur sont utilisées pour la scrutation des variables lors du trafic périodique et apériodique. Cet échange est initié par l’émission d’un identificateur, adresse logique informant de la nature des données attendues, reconnue par le nœud producteur qui transmet les données et par les nœuds abonnés qui les consomment.

118 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

Tableau 2 : trames de requête-réponse définies par le protocole WorldFIP Utilisation : Type de trafic (périodique / apériodique) Nom de la Trame de Requête ou précédente Nom de la Trame de Réponse O Objet Objet I Champ Information (contenu) Champ Information (contenu) C Champ Contrôle (indication particulière) Champ Contrôle (indication particulière) Utilisation : Trafic périodique et apériodique ID_DAT_id RP_DAT O Transmis à destination d’un producteur de la Transmission des données en provenance de la variable « id » couche application par le producteur de « id » Requête : demande de données au producteur de «id» 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 source de l’identificateur pour un transfert de variable ou de message apériodique, indique également la priorité (normale ou urgente) de cette requête Utilisation : Trafic apériodique ID_RQ_x RP_RQ O Transmis à destination d’une station « x » Emission par « x » d’une liste d’identificateurs ayant réalisé une requête pour un transfert de « id » de variables (de 1 à 64 identificateurs) variable Requête : invite « x » à transmettre les identificateurs « id » des variables requises I Identificateur sur 2 octets C ID_MSG_x RP_MSG_NOACK ou RP_MSG_ACK O Transmis à destination d’une station « x » ayant Réponse sans demande d’acquittement réalisé une requête pour un transfert de message (_NOACK) ou avec demande (_ACK) Requête : invite « x » à transmettre son message à un destinataire identifié I Adresses destinataire et source sur 3 octets chacune Puis message de longueur maximale de 256 octets. C Un bit du champ indique si le message transféré doit être acquitté ou non RP_MSG_ACK RP_ACK O Trame contenant un message à l’attention d’un Trame d’acquittement par le destinataire du destinataire identifié message RP_MSG_ACK Requête : demande d’un accusé de réception à ce destinataire 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 émise par l’émetteur du message, après réception de l’acquittement si demandé. I Vide C Code la fin de transaction

Synthèse INRETS n° 45 119 Les réseaux de terrain embarqués dans les transports guidés

Le champ de contrôle de la trame de réponse RP_DAT peut coder une demande de l’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 liste d’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 interrogation RP_MSG_NOACK ou RP_MSG_ACK transmettra alors des informations de l’esclave source à 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 son message. La transaction sera finalement close par l’esclave source au moyen d’une trame RP_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œud destinataire.

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é à cette architecture, 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 de protocoles 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 Network Management) (figure 12 du chapitre 2). L’utilisation dans une communication TCN d’un réseau ne supportant pas les protocoles RTP nécessite alors une conversion de protocole [ROSIN_URLb]. Les services et protocoles nécessaires à une application pour communiquer 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és dans 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 couches hautes sur lesquelles sont définis les protocoles temps réel RTP, mais aussi au protocole de 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 de donné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 multi destinataires 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 trames seront ensuite considérés.

120 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

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 des variables. Ces variables sont maintenues à jour au sein de mémoires partagées (Traffic_Store) locales à chacun de ces équipements. Chaque mémoire Traffic_Store repré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 RTP aux fonctions utilisateur et gestionnaire de réseau, le service « variable » lorsque la transmission doit être régulière et temps critique et le service « message » lorsqu’elle peut être sporadique et pour une taille de données plus importante. Ces services sont maintenant 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 chaque phase périodique, le maître du bus considéré (MVB ou WTB) initie le rafraîchissement de variables processus en diffusant une trame maître comportant l’identificateur des données processus attendues. En retour, l’équipement esclave éditeur (Publisher) des variables identifiées diffuse la trame de données processus requise. Cette trame peut comporter 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 variables processus au sein d’un ensemble de données transmis sont identifiées dans le réseau TCN par : 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 les nœ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).

Synthèse INRETS n° 45 121 Les réseaux de terrain embarqués dans les transports guidés

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

La configuration de chaque passerelle est dépendante de l’application. Elle est réalisée par le programmeur de l’application à partir de la conception de deux listes de variables : l’une des variables à exporter du bus véhicule MVB au bus train WTB, l’autre des variables à importer du bus train au bus véhicule. La tâche application de la passerelle filtre 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 la vérification de la fermeture des portes du train par exemple) [ROSIN_URLb]. Elle rassemble enfin dans une même trame du bus train (trame WTB) les données processus en 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 un service 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 de diagnostique) ou de messages courts à l’adresse d’un équipement spécifique (tels qu’un message d’ordre de fermeture d’une porte particulière). Les deux applications communicantes peuvent être situées dans un même équipement, dans des équipements différents, dans des véhicules différents. L’échange d’information sur les média se fait par l’intermédiaire d’un télégramme appelé « données messages » (Message_Data) qui est identifié par son adresse destination.

122 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

Contrairement au service variable défini seulement sur la couche 7 de RTP, les services messages sont définis sur ses couches 3 à 7. Un nouveau schéma d’adressage est donc 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 niveaux d’adressage différents : les adresses « équipement » et « réseau ». Les adresses équipement sont les adresses « source » et « destinataire » spécifiques à la couche liaison de 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és communicantes 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 pour l’é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âches courantes d’un système de contrôle (telles que les tâches de contrôle des portes, de l’air conditionné, des freins...). Ces fonctions sont réalisées par des équipements connectés à un bus véhicule ou directement à un nœud du bus train, chaque véhicule du train supportant un certain nombre 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 un système fermé (par exemple le métro), ces « fonctions » sont définies par le gestionnaire et l’opérateur du système.

Synthèse INRETS n° 45 123 Les réseaux de terrain embarqués dans les transports guidés

Pour les applications utilisateur, le réseau est perçu comme un ensemble de nœuds supportant chacun un ensemble de « fonctions » (figure 18). Les applications ne spécifient pas, normalement, la station devant exécuter une « fonction ». L’accès à la fonction se fait par son « adresse utilisateur ». Cette adresse est une concaté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écute localement 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 sa station ou d’une autre station. La perception du réseau par le gestionnaire de TCN est celle d’un ensemble de stations attachées aux nœuds WTB (figure 19). Chaque station est reconnue par son identificateur de station. Il peut y en avoir jusqu’à 254. Le gestionnaire du réseau donne ainsi accès aux équipements lors de la mise en service du système ou de son dé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 de différents nœuds en utilisant une adresse de groupe à la place d’une adresse de nœ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’un accès simultané à plusieurs stations par une diffusion), de l’identificateur de la

124 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

station et, éventuellement, de l’identificateur de la station voisine (si la spécification d’une station routeur ou encore l’accès à un équipement spécifique est nécessaire). Le gestionnaire du réseau accède ainsi aux équipements par l’identificateur de leur station plutôt que par leur adresse équipement. Pour que son schéma d’adressage puisse être indépendant des bus du train, un répertoire des stations effectue une correspondance entre l’identificateur des stations (adressage systè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 sur demande. Ce sont les « messages système », les « messages utilisateur » et les « messages gestion ». 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 « messages utilisateur », identifiés par leur « adresse utilisateur », sont échangés entre des applications utilisateurs. 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 de communication entre les stations distantes « source » et « destinataire » du message est exécuté au sein de chacune de ces stations par un « messager » (Messager). Ce protocole est 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 couche session court-circuite le réseau et évite la segmentation en paquet : il n’y a alors pas d’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 de données qui les transporteront. Elle les transmet ensuite à la couche réseau.

Synthèse INRETS n° 45 125 Les réseaux de terrain embarqués dans les transports guidés

Le protocole de transfert du message entre la couche transport d’un producteur et celle d’un consommateur réalise un contrôle des flux de bout en bout et un recouvrement d’erreur pour éviter une perte ou une duplication de paquets. – Sa couche réseau consulte ses répertoires « fonction » et « station » afin de traduire les 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 de contrôle du message) de bus en bus sans connexion préalable. Les paquets routés par 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 pour chacun 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 ne gère pas le flux de données et ne reconnaît pas les trames perdues. Elle reçoit juste les 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 destination d’équipements situés sur un même bus. Par conséquent, lorsqu’un message est envoyé à destination d’un autre bus, l’adresse destination est celle du nœud de rattachement au bus train. Inversement, lorsqu’un nœud du bus train reçoit un message à 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 destinataire distante en informe l’application concernée qui émet alors un « message de réponse » dans la direction opposée.

126 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

Dans ce paragraphe 3.2.3.1, les deux services « variable » et « message » offerts aux applications utilisateur et gestionnaire de réseau par l’interface application des protocoles temps réel RTP ont donc été présentés. Le service « variable » utilise les propriétés de diffusion périodique des bus train et véhicule et de filtrage des nœuds du bus train pour la 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 et véhicule et de routage des nœuds du bus train pour l’échange, sur demande d’une application à une autre application, de données de tailles importantes ou de messages courts à l’adresse d’un équipement spécifique. Afin de pouvoir supporter ces deux services, nous expliquons ci-après les services offerts par l’interface de la couche liaison de 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 une transmission de données périodique et apériodique et offre d’autre part aux protocoles RTP 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]

Synthèse INRETS n° 45 127 Les réseaux de terrain embarqués dans les transports guidés

Ces données sont : – données processus (Process_Data) Ce sont des données périodiques identifiées par une adresse logique. Elles sont produites par un équipement écrivain (Publisher) et consommées par un certain nombre d’équipements abonnés (Subscriber). Pour chacune des données processus pouvant être reçues ou émises par un équipement, l’équipement dispose d’une mémoire tampon appelée « port », configurée soit en entrée (s’il en est abonné) soit en 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 MVB et les nœuds du bus train WTB. Un équipement d’un bus MVB peut contenir jusqu’à 256 ports configurés ou en source ou en puits. Le nombre maximal de ports sur l’ensemble des équipements d’un bus véhicule est de 4 095. Chaque nœud du bus train WTB possède, d’une part, un unique port source gérant l’ensemble des variables processus éditées par le nœud et, d’autre part, un unique port puits pour la réception des trames de données processus des équipements du bus. La trame de données processus d’un nœud WTB et chacun de ses deux ports peuvent contenir jusqu’à 128 octets. Les données processus transportent l’ensemble des données utilisées par le protocole 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 en sortie, de deux files d’attentes, l’une pour les messages en réception, l’autre pour les messages en émission. Ces données message transportent l’ensemble des paquets utilisés par le protocole RTP 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 sont utilisé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étection des équipements silencieux, le transfert du rôle du maître d’un équipement à un autre, l’inauguration13 du bus train (WTB)... A ces trois services de transmission correspondent trois types de télégrammes qui se distinguent 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 train aux cours desquelles est notamment nommé le maître du bus, sont numérotés les nœuds esclaves du bus train, construites la liste de scrutation... (voir le paragraphe 3.2.3.3 de ce chapitre).

128 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

Tableau 3 : définition des télégrammes des bus de TCN

Télégramme Process_Data (« Données_Processus ») Données diffusées périodiquement identifiées par une adresse source en relation avec la transmission 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 à un • d’une résolution d’événement (suite à une changement de configuration) ; collision 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.

De la même façon que dans le protocole WorldFIP, les maîtres des bus MVB et WTB divisent 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 de supervision à 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 cas du bus MVB (figure 23). Les données périodiques à scruter à chaque période de base sont dé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, à chaque changement 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 à laquelle il 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ées processus indépendants du nombre de nœuds. – à l’initialisation, en fonction des besoins des applications programmées (protocoles WTB et MVB). La phase apériodique permet le transfert de données message et également de données de 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ée constante pour chaque période de base.

Synthèse INRETS n° 45 129 Les réseaux de terrain embarqués dans les transports guidés

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

Après cette présentation générale du réseau TCN, nous nous intéressons dans les paragraphes qui suivent à quelques particularités des protocoles WTB et MVB et au format de leurs trames de communication. Dans le cas du protocole WTB, nous présentons la procédure d’« inauguration » qui répond, pour le bus train, à un besoin spécifique de l’application ferroviaire embarquée. Dans le cas du protocole MVB, nous pré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 le bus train et les bus véhicule. Ils jouent également celui de routeur pour les messages du service « messages » des protocoles RTP. Contrairement aux bus véhicule dont le nombre d’é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 de configuration du bus train qui nécessite en particulier de redéfinir dynamiquement le contrôleur maître du bus et sa table de scrutation pour la réalisation de la phase périodique... Ainsi, suite à un changement de configuration du bus train provoqué par une dé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 la phase sporadique. Le format des trames WTB est ensuite indiqué.

130 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

a. Inauguration du bus train Au cours de la procédure d’inauguration du bus train, les opérations suivantes sont réalisées : – les nœuds connectent électriquement leurs sections de câbles pour ne former qu’un seul segment avec une terminaison de ligne à chaque extrémité, – chaque nœud reçoit une adresse unique qui identifie sa position et son orientation relativement à celle du nœud maître (figure 24) et informe ce dernier de la période de scrutation individuelle qu’il désire avoir, – chaque nœud reçoit un descripteur, appelé topographie, qui lui indique l’adresse, la position et le descripteur des autres nœuds. Chaque descripteur de nœud indique, la taille 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 et 7) et enfin le type et la version du nœud. Ces deux dernières informations caractérisent le format de la réponse du nœud à une requête de données processus. Un descripteur est 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 sont considé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 susceptible de 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 de direction 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 les nœ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émentation d’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équentiellement et par incrémentation d’adresse en commençant par l’adresse 02. Les deux nœuds terminant le bus train (l’un en tête et l’autre en queue de train, soit en début et fin de ré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

Synthèse INRETS n° 45 131 Les réseaux de terrain embarqués dans les transports guidés

Chaque nœud connaît son adresse et sa position relative au maître selon la « direction 1 » ou la « direction 2 » en fonction de la façon dont il a été nommé (façon ascendante ou descendante). 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 ainsi si 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 également connaissance de la topographie du train indiquant l’adresse, la position et le type de tous les 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 leurs portes A lorsqu’ils ont la même orientation que le maître ou leurs portes B lorsque leur orientation 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, la connexion électrique des sections de câbles des nœuds au cours de cette procédure nécessite un temps d’attente de 10 ms au cours duquel le bus est indisponible. Un seul nœud peut donc être configuré à chaque période de base de 25 ms, ce qui signifie une duré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 en compte et résolus par le protocole WTB par une gestion locale de temporisateur et une notion de force (Strength) associée à chaque nœud : – conflit dû à la présence de deux nœuds forts : ce cas est possible, lors du couplage de 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ées et de la taille des trames des nœuds. La période individuelle annoncée la plus longue va définir la macro-période. Pour chaque période de base, le temps non utilisé par la scrutation 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ître doublera la période la plus longue, si ce n’est pas encore suffisant la seconde période la plus longue et ainsi de suite jusqu’à ce que 40 % du temps des périodes de base reste libre en moyenne sur la macro-période. Le maître construit alors la topographie. La topographie est une structure de données contenant pour chaque nœud son adresse, son type et sa version, une « topographie maître » identifiant de façon unique l’inauguration du maître. La période individuelle alors optée pour chacun des nœuds leur est alors communiquée au moyen de requêtes « topographie ». Pendant la phase périodique au cours de laquelle la liste de scrutation est exécutée, un des deux nœuds de fin de bus (figure 25 du chapitre 3) est également alternativement scruté par le maître à chaque période de base. Cette scrutation est réalisée par l’envoi

132 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données 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 la pré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 pas retiré de la liste périodique. Seule une nouvelle inauguration permettra de ne pas le prendre en compte. Un nœud, qui serait l’abonné d’un nœud défaillant, doit être capable de signaler sa disparition à son application, passé un délai de trois scrutations, voire sa ré-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 à la recherche d’une signalisation de messages en attente. Pour raccourcir cette recherche, un nœud esclave a la possibilité, lors de sa scrutation périodique, d’effectuer cette signalisation 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 ou apériodiques par le positionnement des éléments binaires A et C du champ de contrôle LC de la trame de réponse à un télégramme de « données processus » ou de « données message ». Le bit A est positionné pour une requête de « données message » et le bit C pour 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 file d’attente des requêtes « message données » (si bit A) ou « message supervision » (si bit C). 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 par l’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 de requête maître à un esclave et de la trame de réponse de l’esclave adressé. Le format d’une trame WTB est donné à la figure 25.

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

Synthèse INRETS n° 45 133 Les réseaux de terrain embarqués dans les transports guidés

Le type de requête du maître et, par conséquent, la nature de la réponse attendue en provenance d’un esclave sont identifiés par le contenu du champ de huit bits Link_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) de ce champ de contrôle LC permettent à un esclave de signaler au maître un événement lorsque 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 de supervision (Supervisory_Data) permet la détection d’un changement de composition du train et l’inauguration du bus. Plus d’informations sur les trames citées dans le tableau 4 pourront ê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 le Requête Detect (M = 1) / Réponse Detect (M = 0) codage Requête Status (M = 1) / Réponse Status (M = 0) de xxx : 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égrammes de 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 bus train WTB par un nœud WTB jouant le rôle de passerelle. Une particularité du bus MVB réside dans sa façon de gérer les événements sur son bus. Le protocole d’échange mis en jeu se rapproche alors du protocole CSMA/CRCD (variante déterministe du protocole de type contention CSMA/CD). Une seconde particularité du protocole est sa gestion du changement 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 expliquons maintenant.

134 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

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). Ce processus qui comporte la recherche d’événements et leurs traitements va durer sur plusieurs phases apériodiques (il ne fait pas intervenir la phase périodique des périodes de base). Il peut exister jusqu’à 4 096 ports à scruter sur un bus MVB. En l’absence de toute connaissance des ports en attente d’une scrutation spécifique, la station maître va procéder par interrogation successive à l’adresse de groupe de ports. Le début d’un « tour de scrutation des événements » (Event_Round) débute ainsi par une trame de requête d’é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 se produit. La procédure d’arbitrage consiste alors en une recherche dichotomique : le maî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éduits jusqu’à l’obtention d’une réponse individuelle. La trame Group_Event_Request de requê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’une ou l’autre des priorités. A la réception d’une réponse individuelle contenant une adresse à scruter, le maître interroge cette adresse par l’intermédiaire d’une requête de lecture d’évenement (trame Event_Read_Request). L’esclave adressé lui répond alors par une trame Event_Read_Response contenant une information consommée par les équipements en attente de cette donnée. Ces équipements suppriment alors de leur liste d’événements en attente ce dernier événement. La station maître repart ensuite à la recherche d’autres ré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 clore le tour actuel de scrutation des événements Event_Round et pour prévenir des perturbations ayant pu avoir lieu sur le bus, le maître renvoie une trame General_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 encore scrutés de les signaler. Si aucun équipement ne répond, le maître commence un nouveau tour de recherche d’événement Event_Round. Il lit alors l’événement en cas d’une unique réponse ou débute une phase d’arbitrage en cas de collisions. Les figures 26 et 27 illustrent cet algorithme de recherche d’événements.

Synthèse INRETS n° 45 135 Les réseaux de terrain embarqués dans les transports guidés

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

136 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

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

Synthèse INRETS n° 45 137 Les réseaux de terrain embarqués dans les transports guidés

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 un anneau logique. Un algorithme de passage du jeton assure qu’il n’existe qu’un unique maî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 les administrateurs. 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 de scrutation 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ître courant. Le transfert effectif de la fonction de maître se fait par l’intermédiaire du télégramme Mastership_Transfer. Un administrateur maître en attente peut également devenir l’administrateur maître suite à une défaillance du précédent maître. Cette défaillance est détectée par un trop long silence sur le médium. De façon à éviter les collisions entre maîtres en attente essayant de prendre la fonction de maître suite à la mise sous tension ou la perte du maître courant, les temporisations (time-out) de chacun des maîtres potentiels sont échelonnées de façon à assurer que seulement un des administrateurs du bus devienne le maître.

138 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

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 trame de réponse de l’esclave destinataire (figure 29). Trois types de télégrammes, décrit au tableau 3, ont été définis pour permettre l’échange d’informations périodiques et apé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 est identifiée par le code F_code de la trame maître. A chacune d’elles correspond une trame de réponse spécifique en provenance d’une ou plusieurs entités esclaves. Ces requêtes sont décrites au tableau 5.

Tableau 5 : description des requêtes de l’administrateur maître du bus MVB d’après [ROSIN_URLb]

Télégramme Process_Data (« Données_Processus ») F_code : 0 à 7 Trafic Périodique 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 ») F_code : 12 Trafic Apériodique, phase Message

Requête (« Données_Message ») utilisée pour donner la possibilité à une entité Message_Data esclave d’en adresser une autre Télégramme Supervisory_Data (« Données_Supervision ») F_code : 8, 9, 13, 14 et 15 Trafic Apériodique, phase Supervision et Evénement Transfert de la fonction maître d’un administrateur de bus à un autre (Phase supervision) Requête (« Transfert_Maître ») utilisée pour une demande de transfert de la Mastership_Transfer fonction maître à un autre administrateur de bus Recherche d’événements (Phase Evénement) Requête (« Evénement_Général ») utilisée lors d’une recherche des nœuds ayant General_Event des données apériodiques à transférer (soit lors d’une « recherche d’événements »). Cette requête, diffusée à l’ensemble des nœuds du bus est 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 à une collision, causée par l’utilisation d’une précédente requête General_Event ou Group_Event, lors d’une recherche des nœuds ayant des 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

Synthèse INRETS n° 45 139 Les réseaux de terrain embarqués dans les transports guidés

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

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 une méthode d’accès au médium décentralisé selon le principe du passage de jeton ». Cette méthode est elle même « à la base d’une méthode d’accès centralisée selon le principe d’un protocole maître-esclave ». Ce protocole est basé sur la définition d’une station active et de stations passives. Les stations passives sont les stations esclaves qui ne peuvent transmettre que sur requête d’une station active. La station active est la station qui, parmi les stations maîtres du bus, possède le jeton. Elle gère par scrutation les accès au médium d’un ensemble de stations passives durant l’intervalle de temps défini de possession du jeton. Le jeton est transmis sur le bus de station maître en station maître selon le parcours d’un anneau logique (figure 30).

Figure 30 : mode de transmission cyclique du bus PROFIBUS

L’échange de messages entre une station active et un ensemble de stations passives prend place à l’intérieur de cycles. Un cycle message est un ensemble constitué d’une trame d’« action » en provenance d’une station maître (trame de requête – Request – ou d’envoi accompagné d’une requête spécifique – Send/Request) et de la trame

140 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données d’acquittement ou de réponse d’une station maître ou esclave (figure 31). Les trames d’action et de réponses peuvent contenir des données utilisateur. La trame d’acquittement n’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 transmission de jeton d’une station maître à une autre et celui de la diffusion de données à l’ensemble des stations esclaves d’une station maître. Dans ces deux cas, il n’y a ni trame d’acquittement, ni trame de réponse. Toutes les stations hormis l’initiateur (la station active) doivent gérer les requêtes qu’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 au maî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 la transmission des cycles messages à la prochaine réception du jeton est raccourci en conséquence. La séquence temporelle des cycles messages est définie par les modes d’opération de transmission 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.

Synthèse INRETS n° 45 141 Les réseaux de terrain embarqués dans les transports guidés

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 la connaissance de son prédécesseur (Previous Station, PS), la station de laquelle il reçoit le jeton, de son successeur (Next Station, NS), la station à laquelle le jeton sera transmis et enfin 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 de l’initialisation des paramètres d’exploitation. Elles sont par la suite corrigées dynamiquement 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’ordre numérique ascendant des adresses des stations au moyen de la trame jeton, sauf lorsque le jeton arrive à la station ayant l’adresse la plus élevée. Dans ce cas, cette station le transmet à la plus petite adresse pour fermer l’anneau. Si l’anneau ne comporte qu’un seul maître et plusieurs esclaves alors le système PROFIBUS 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ôleur FDL de la station maître initialise ce mode en raison d’une requête locale d’utilisation sur ré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.

142 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

3.3.1.3 Mode « Send/Request » cyclique Lors de la scrutation, la station maître adresse cycliquement les stations avec la requête « send and Request Data flow », selon une séquence prédéfinie dans une liste de scrutation. Cette liste de scrutation est fournie au contrôleur FDL par l’utilisateur local FDL. Toutes les stations maîtres et esclaves à scruter sont marquées dans cette liste. Les stations 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 de priorité haute. Il réalise ensuite le cycle de scrutation en conformité avec la liste de scrutation. Cette réalisation peut être segmentée sur plusieurs intervalles de temps de possession du jeton. Après réalisation complète, les cycles messages de priorité basse sont exécutés. Un nouveau cycle de scrutation peut ensuite commencer. Si exigé, la scrutation est à l’origine de cycles messages de priorité basse additionnels tels 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 son réseau. A cette fin, chaque station maître dans l’anneau logique du jeton maintient en local une liste d’adresses, appelée « GAP List », comportant l’ensemble des adresses des stations du réseau comprises dans l’intervalle d’adresses (le « GAP ») défini par sa propre adresse TS et celle de la prochaine station maître active NS. Chaque station maître est alors responsable de l’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 des adresses 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 jeton en 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 du GAP 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 : des trames de format fixe sans données (trame de requête, d’acquittement ou encore celle d’acquittement court constitué d’un seul caractère) ; des trames de longueur fixe avec des données (trame Send/Request, trame de réponse) ; des trames de longueur variable comportant un champ longueur redondé (trame Send/Request, trame de réponse) ; une trame jeton sans données, sans champ longueur, sans FCS et fin de trame.

Synthèse INRETS n° 45 143 Les réseaux de terrain embarqués dans les transports guidés

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

Les différents formats de la trame sont annoncés par une valeur particulière du ou des champs SD. Le type de la trame, par exemple celle d’une trame d’action Request ou Send/Request, d’acquittement ou de réponse, est identifié par le codage de l’octet de contrôle FC. Signalons encore que chaque trame est constituée d’un ensemble de caractères au format 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 un bit stop. L’utilisation par PROFIBUS de ce type de caractères permet la synchronisation binaire rendue difficile par le codage NRZ (voir le chapitre 3).

3.4 Protocole du réseau BITBUS

3.4.1 Méthode d’accès Nous avons peu d’informations sur le protocole du réseau BITBUS si ce n’est que l’accès au bus se fait selon un protocole d’interrogation mono-maître multi-esclaves. Un esclave n’accède au bus qu’en réponse à une interrogation du maître, une communication entre esclaves ne peut avoir lieu qu’avec l’intermédiaire du maître. L’interrogation des différents esclaves par le maître se fait régulièrement par scrutation selon une séquence programmé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 la trame HDLC pour lequel le champ information est organisé en octet) (figure 34).

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

144 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

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 Sense Medium Access with Collision Detection). Il a été développé et breveté à l’origine par Xerox pour son réseau local Ethernet. Il a par la suite servi de base pour la norme IEEE 802.3 [Lagrange et Seret 1998]. Le principe du protocole d’accès CSMA/CD est le suivant (figure 36). Un nœud souhaitant é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’à ce qu’il soit libre et transmet alors immédiatement. En cas de détection de collision lors de la transmission (par détection d’interférences), il transmet un signal de brouillage de duré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 de tenter de ré-émettre selon le protocole décrit. Ce temps d’attente est tiré aléatoirement de la loi exponentielle binaire dont la moyenne est fixée pour la première ré-émission et est doublé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 report de transmission lorsque le canal est trouvé occupé. La figure 36 illustre trois exemples d’algorithmes : – algorithme Non-persistant : transmission immédiate si le bus est trouvé libre. Sinon ou 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 cas de collision, attente que le canal soit libre puis transmission immédiate (soit une transmission avec une probabilité de collision de « 1 » si plusieurs nœuds sont prêts à émettre). Cet algorithme réduit le temps d’attente.

Synthèse INRETS n° 45 145 Les réseaux de terrain embarqués dans les transports guidés

– algorithme p-persistant : attente de la libération du bus s’il est occupé, sinon transmission avec une probabilité « p » ou attente d’un intervalle de temps avec une probabilité « 1-p » (typiquement intervalle de la durée du délai maximum de propagation). En cas de délai de transmission d’un intervalle de temps, re-tentative conformément à cet algorithme. Les algorithmes CSMA mis en œuvre par les protocoles CAN et LONWORKS sont encore 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 particulier d’utilisation de ce protocole CAN avec la couche application CANopen.

4.2.1 Méthode d’accès Le protocole CAN est un protocole multi-maîtres qui supporte un accès spontané et simultané de plusieurs stations maîtres. Ces accès concurrents sont réalisés selon un protocole CSMA. Contrairement au protocole CSMA/CD, la collision produite est non destructive pour l’information transmise prioritaire. Le protocole a aussi la faculté de fonctionner 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 de ré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 champ d’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 » (niveau logique ‘1’) et l’état « dominant » (niveau logique ‘0’). L’état dominant impose son état sur l’état récessif. Il est celui qui résulte d’une collision entre un état dominant et un état récessif14. Dès détection de collision par une station émettrice d’un état récessif (détection d’un niveau dominant sur le bus), cette station arrête immédiatement sa transmission de sorte à ne pas gêner la transmission des bits de la trame prioritaire (figure 37). Elle retente d’émettre lorsque le bus est libre après un temps T constant. Cette station a perdu la priorité. La définition des deux états est obtenue pour une ligne de transmission en bande de base sur un médium en cuivre par un câblage de type Et-câblé.

146 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

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

Le champ d’arbitrage sur lequel se fait l’arbitrage bit-à-bit est composé du champ d’identification et d’un bit, nommé bit RTR (voir le paragraphe 4.2.2 suivant). Sa longueur est de 12 bits ou de 32 bits si le format étendu est choisi. Ce champ d’identification identifie le contenu de la trame et doit être attribué de façon unique. S’il ne l’est pas, la station émettrice qui détecte une collision en dehors de ce champ bloque toute émission sur le bus par la transmission d’un signal d’erreur (6 états dominants consécutifs) : dès que le bus est de nouveau libre les deux stations vont retenter d’émettre aprè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 non destructif pour la trame prioritaire par arbitrage bit à bit », le schéma de la figure 38 illustrant le protocole CSMA avec arbitrage bit à bit du CAN utilise le même format que le 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

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 un niveau de tension haut. Pour un support fibre optique, l’état dominant est caractérisé par la présence d’émission de lumière (visible ou non) et le niveau récessif par son absence, de même pour un support infrarouge.

Synthèse INRETS n° 45 147 Les réseaux de terrain embarqués dans les transports guidés

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 par un identificateur de 11 ou 29 bits (selon le format choisi pour le réseau). Une telle trame émise sur le médium est acceptée ou refusée en réception par les stations du médium sur filtrage de la valeur de son identificateur. Elle est composée des champs suivants : un champ début de trame ; un champ d’arbitrage sur lequel est réalisé, lors d’accès simultanés de plusieurs stations au médium, l’arbitrage bit à bit donnant un accès prioritaire à la trame possédant l’identificateur de plus petite valeur ; un champ de contrôle spécifiant notamment le 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, de contrô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, le bus est considéré comme libre par l’ensemble des stations. Le champ d’arbitrage comprend un identificateur qui identifie de façon unique le contenu de la trame et un bit RTR au niveau dominant pour une trame de données. Le champ acquittement permet à un récepteur de la trame d’acquitter sa bonne réception par insertion d’un niveau 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 est identifiée de façon unique par la valeur de l’identificateur. De même format que la trame 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 de données est toujours vide (0 octet). – la trame d’erreur Elle est constituée de deux champs, un champ de drapeaux d’erreurs et un délimiteur de champ. Elle peut être une trame d’erreurs actives (émission de six niveaux dominants). Dans ce cas, toutes les stations présentes sur le médium détectent l’existence d’une erreur et transmettent à leur tour une telle trame (la

148 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

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 actives peut ê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 cas de figures, notamment lorsque le récepteur a besoin de plus de temps pour traiter les 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 WorldFIP vont privilégier l’aspect « délai à respecter »15 en définissant une zone de trafic périodique et une autre apériodique, le protocole CAN privilégie les accès événementiels et notamment les accès événementiels prioritaires. Il est alors coutume de dire que si les délais d’accès au médium et les temps de réponse sont calculables pour les messages prioritaires, ils ne le sont pas toujours pour les messages moins prioritaires. Ceci nécessite alors une définition, au niveau de l’application, d’identificateurs adéquats permettant un trafic équitable entre les communications prioritaires et non prioritaires. C’est en partie le rô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 protocole propose un modèle d’équipement composé de trois parties [CANopen 2000]. Tout d’abord, une interface et un protocole logiciel de communication fournissent les services de transmission et de réception des objets communicants à travers le bus. Ils sont situés entre la couche 2 du protocole CAN et un dictionnaire d’objet. Le dictionnaire d’objet décrit ensuite l’ensemble des types de données, d’objets de communication et d’objets application 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’interface aux différentes fonctionnalités des matériels de traitements (soit des entrées/sorties). La partie qui nous intéresse ici est le protocole de communication. Il transmet un ensemble d’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 transfert de données temps réel ; – ceux des objets SDO (Service Data Objects – données services) pour l’accès en lecture et écriture des entrées du dictionnaire d’objets ;

15 Nous n’employons pas, volontairement, le terme de déterministe pour les réseaux de communication, [Thomesse 1999] faisant remarquer d’une part que cette notion « n’existe pas en général si on n’a pas précisé les hypothèses en particulier de bon fonctionnement, de délai supposé, etc. » et d’autre part que « ce paradigme doit s’appliquer d’abord au comportement des applications qui doit être déterministe, quelles que soient les conditions environnementales ».

Synthèse INRETS n° 45 149 Les réseaux de terrain embarqués dans les transports guidés

– ceux des objets Special Function (fonction spéciale) pour le protocole de synchronisation spécifique à l’application cible, le protocole de datation (time stamping) et pour la transmission de messages urgents (Emergency Protocol); – ceux de gestion de réseaux qui fournissent les services d’initialisation, de contrôle d’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èle producteur-consommateur est rendu possible par la diffusion de message et la faculté des stations à l’écoute du réseau de consommer (d’accepter) ou non un message sur reconnaissance de son identificateur. Le modèle client-serveur est utilisé pour le transfert de données de taille supérieure au champ d’information de 8 octets de la trame CAN : les données sont segmentées en paquets émis successivement avec le même identificateur de trame. Pour ce modèle, une trame de confirmation est envoyée par le serveur à chaque requête du client. Enfin, le modèle maître-esclave autorise la diffusion de données sur initiation 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 en conformité avec la définition du profil de l’équipement. Périodiquement, la transmission 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ée par 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 temporelle consécutive à l’objet de synchronisation SYNC. Leur priorité d’accès au médium est supérieure à celle des objets de la transmission asynchrone (i.e. identificateurs prioritaires). La transmission synchrone est divisée en un mode de transmission cyclique et un acyclique. La transmission cyclique est périodique, celle acyclique est déclenchée par une application. Toutes deux ont obligatoirement lieu dans la fenê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 ou dans une fenêtre synchrone, en conformité avec la priorité d’accès des PDO asynchrones associée à la définition de leurs identificateurs. Afin de ne pas gêner la transmission 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 un fonctionnement particulier au protocole CAN de manière à définir des fenêtres temporelles de communication dans lesquelles prennent place des transmissions cycliques et acycliques.

150 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

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

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 couches hautes des réseaux LONWORKS, d’après le standard [ANSI/EIA-709.1-A 1999], en commençant par la partie inférieure de la couche application jusqu’à la couche liaison de données. Le paragraphe suivant présentera alors plus en détail l’algorithme d’accès au médium « CSMA prédictif p-persistant » de la couche liaison de données. Cette présentation rapide de l’ensemble des couches du protocole LonTalk permettra de mieux comprendre l’espace d’adressage du réseau qui sera présenté avec le format de la trame LonTalk dans un troisième paragraphe. Nous verrons à cette occasion que contrairement aux autres réseaux décrits dans cette étude, ce protocole ne dispose pas d’adressage au niveau de la couche 2. Enfin, à titre de conclusion, nous évoquerons un cas particulier d’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érieure de 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 de gestion de réseau et de diagnostics. La mise à jour d’une variable est possible par interprétation de l’unité de protocole application (APDU) conformément aux informations 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 arrangement au préalable. [ANSI/EIA-709.1-A 1999] définit les couches session et transport comme le cœur de la 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étection de duplication. La couche transport est sans connexion et assure une livraison fiable des

Synthèse INRETS n° 45 151 Les réseaux de terrain embarqués dans les transports guidés

messages à destinataires multiples ou uniques. L’authentification de l’identité de l’émetteur est incluse comme un service de la couche transport pour être utilisé lorsque la sécurité le nécessite. Pour accomplir cette fonction, le serveur d’authentification fait seulement appel à la sous-couche contrôle de transaction. Par conséquent, les messages des couches transport et session peuvent être authentiques en utilisant tous les modes d’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édures distantes 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 de livraison en provenance du ou des destinataires distants. Un message de Requête de la couche 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 la segmentation, ni le ré-assemblage des messages. L’algorithme de routage qu’elle utilise pour apprendre la topologie suppose une topologie du réseau en arbre. Cependant, les routeurs qui possèdent des tables configurées peuvent opérer sur des topologies comportant des boucles physiques tant que le chemin de communication logique est organisé selon une topologie arbre. L’utilisation de tables configurées supporte aussi bien un adressage à une adresse donnée (unicast – mono-destinataire) qu’à un groupe d’adresses. [ANSI/EIA-709.1-A 1999] signale que dans de nombreuses applications un simple acheminement par inondation (flooding) de messages à l’adresse d’un groupe est suffisant. Enfin, la sous couche MAC de la couche liaison de données (couche 2) utilise un algorithme d’évitement de collision appelé « Predictive p-persistent CSMA » (Carrier Sense, Multiple Access). La sous-couche LLC supporte un service sans connexion. Ses fonctions sont la mise sous forme de trame, le codage de la trame, la détection d’erreur sans recouvrement par retransmission. L’algorithme « CSMA Predictif p-persistent » est maintenant 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 collision qui rend aléatoire les accès au médium en utilisant la connaissance de la charge attendue du 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 avant toute tentative que le canal de transmission est en veille pendant une durée minimale de

152 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

}1. Après avoir détecté un bus libre, le nœud génère alors un retard de transmission aléatoire comportant un nombre d’intervalles de temps aléatoire de durée }2. Ce nombre d’intervalles varie de 16 intervalles, pour un trafic peu chargé, à 1 008 intervalles, dans le cas d’une charge du bus maximale (figure 41). Si le bus est toujours à l’état de veille après le retard aléatoirement généré, le nœud transmet. Si ce n’est plus le cas, il attend de nouveau la libération du bus, puis laisse passer un nombre aléatoire d’intervalles de temps et, 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 de ses arriérés. Chaque nœud est alors capable de prédire dynamiquement le nombre de paquets par nœuds restant à transmettre et d’ajuster en conséquence le nombre d’intervalles d’attente. Ainsi, un nœud transmet un paquet dans un intervalle de temps alé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é maximale malgré des conditions de surcharge [Schweins et Heffernan 1998]. Le nombre de collisions (la probabilité de collisions) est à cette fin réduit par l’augmentation du nombre d’intervalles aléatoires sur lequel se fait le tirage aléatoire. Cependant, ce protocole n’élimine pas la possibilité que plusieurs nœuds tirent un même nombre d’intervalles de temps aléatoires à un instant donné, ce qui cause des collisions destructives. Le protocole LonTalk offre un « service d’acheminement des données avec acquittement » et un « service sans acquittement ». Par défaut, le mode opératoire repose sur le service réseau avec acquittement. Dans ce mode, l’émetteur d’un paquet attend un acquittement du nœud destinataire informant de la bonne réception du paquet. Si l’attente excède un intervalle de temps déterminé, le paquet envoyé est supposé avoir subi une collision et le nœud émetteur doit le ré-émettre à nouveau. En utilisant le service réseau non-acquitté, le nœud émetteur d’un paquet n’a pas à attendre la réception de l’acquittement. Cette option ne garantit pas le bon acheminement des données, mais permet 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

Synthèse INRETS n° 45 153 Les réseaux de terrain embarqués dans les transports guidés

l’émission d’un message. L’utilisation de cette option permet à la couche MAC de retenter 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 protocole de la couche MAC de LonTalk inclut une « option de priorité » basée sur une gestion des accès. Quand un message prioritaire est généré, il quitte le nœud dans un intervalle de temps prioritaire, alors que les messages non prioritaires du nœud restent en mémoire pour une prochaine transmission. Pour cela, des intervalles de temps prioritaires d’une durée }2 sont définis immédiatement après le délai }1 et avant les 16 à 1 008 intervalles de temps aléatoires qui seront 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 un accès prioritaire. Par exemple, un nœud transmettant avec la priorité quatre transmettra son paquet lors du quatrième intervalle prioritaire et n’aura ainsi pas à attendre un nombre aléatoire d’intervalles. Ces intervalles sont assignés exceptionnellement à des nœuds du canal de communication. Un nœud ne peut être affecté qu’à un intervalle prioritaire, un intervalle 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 intervalle prioritaire a été affecté n’ont pas à l’utiliser pour tous leurs messages. Seuls les messages dont le bit de priorité de l’entête de la trame LPDU est positionné (bit du champ de contrôle de la trame représentée figure 43) sont émis par un nœud « prioritaire » avec la priorité du nœud. Une application peut décider qu’un message a une priorité haute et tenter de l’émettre comme tel. Si aucun intervalle prioritaire n’est assigné à ce nœud, le message est émis selon le protocole courant sans tenir compte de cette priorité, cependant indiquée dans l’entête de la trame LPDU. Si, par la suite, ce message passe par un routeur auquel est affecté un intervalle prioritaire sur le canal destinataire, le message est transmis en utilisant la priorité du routeur. Si le routeur n’a pas d’intervalle prioritaire affecté, il est transmis 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 collision est détectée deux fois de suite par un nœud tentant d’émettre dans son intervalle prioritaire, la prochaine tentative de transmission de son message prioritaire est réalisée selon l’algorithme d’accès au médium non prioritaire.

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

154 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

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 – Physical Protocol Data Unit) est représenté figure 43. Cette trame comporte cinq champs. Les deux premiers champs ne sont pas définis dans la norme ANSI/EIA-709.1-A du protocole LonTalk [ANSI/EIA-709.1-A 1999]. Leur spécification dépend de celle de la couche physique choisie. Ces deux champs servent à la synchronisation émetteur-récepteurs au niveau des éléments binaires et du bloc d’information octet. Un troisième champ, le champ de contrôle, dépend de la couche liaison de données. Il est suivi du champ NPDU qui contient les données de la couche réseau. La trame se termine par un Code de Redondance 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 est défini dans la trame NPDU (Network Protocol Data Unit). Il contient une combinaison d’adresses de niveau 3 et 4 (couches réseau et transport) (figures 43 et 44). Par consé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 sur la 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.

Synthèse INRETS n° 45 155 Les réseaux de terrain embarqués dans les transports guidés

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 les communications sont limitées en son sein. Les adresses destination et source des unités de données de protocole réseau et transport (NPDU et TPDU) appartiennent obligatoirement à un même domaine. La communication entre domaines de tailles différentes n’est possible qu’avec l’utilisation d’une passerelle définie au niveau application. Le domaine est donc, à l’échelle d’un système, considéré comme l’unité de gestion et d’administration. La taille de l’adresse du domaine est variable (0, 1, 3 ou 6 octets). Elle dépend du contexte de l’application étudiée. Si celle-ci est à l’échelle du monde, une adresse sur 6 octets sera nécessaire. Pour une application embarquée sur maté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. Un sous-réseau (Subnet) est un sous-ensemble d’un domaine qui contient de 0 à 127 nœuds et 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 domaines différents ; il a alors deux identificateurs différents. Les nœuds d’un sous-réseau peuvent

156 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

être séparés par des répéteurs et des ponts (bridge). La définition de groupes comportant jusqu’à 63 nœuds à l’intérieur d’un domaine permet de supporter un adressage fonctionnel au sein de ce domaine. Chaque membre d’un groupe est identifié au sein du groupe par son numéro de membre (Member). Un champ d’adresse de 8 bits permet de spé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 leur fabrication. 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 un circuit « Neuron » de façon unique à l’échelle mondiale et, par conséquent, le nœud qui l’intègre. En plus de cette adresse Unique_Node_ID, un nœud peut se voir assigner une ou 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 au médium construit sur une méthode d’accès CSMA qui ne permet pas facilement et toujours de déterminer avec précision les temps d’accès et de réponse du réseau. Les deux exemples suivants présentent brièvement deux utilisations particulières du réseau LONWORKS, l’un non dédié aux applications ferroviaires, l’autre construit à l’occasion de la 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 et expérimental de fonctionnement du réseau LONWORKS auquel ils ont imposé de pouvoir garantir les temps de réponse. Pour cela, ils ont construit un ordonnanceur périodique en combinant des techniques matériels et logiciels (figure 45), pour compenser l’absence d’entrée d’interruption matérielle temps réel des composants « Neuron-Chip ». Cet ordonnanceur transmet périodiquement un signal de synchronisation matériel et logiciel aux nœuds. Sur réception de ce signal, chaque nœud est autorisé à transmettre les messages 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 un intervalle 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 exemple de développement d’un système de communication, devant notamment supporter l’application de freinage électronique, pour des trains de fret de longueur 2 250 m, de 125 wagons au maximum et de 4 locomotives [Tione 2001]. Il est mené par la SNCF et la DB en partenariat avec les industriels SAB Wabco et Alstom. Le protocole de communication 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ès les articles de [Grasso et al. 2001 ; Witte et al. 2001].

Synthèse INRETS n° 45 157 Les réseaux de terrain embarqués dans les transports guidés

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

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 locomotive meneuse et en charge du réseau ; – les unités de contrôle local (LCU – Local Control Unit), nœuds esclaves situés dans tout 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éseau en bus (ECU – End Communication Unit), nœuds esclaves qui ont pour tâche d’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 de 230 VDC, l’autre de 48 VDC). Les nœuds esclaves (LCU ou ECU) sont appelés « serveurs de communication ». Le nœud maître (MCU) abrite la tâche de « gestionnaire de communication ». Nœuds esclaves et nœud maître peuvent accueillir plusieurs applications distribuées. Pour permettre cela, le protocole FEBIS distingue les tâches « maîtres d’applications » de la tâche « maître du réseau » : – les maîtres d’applications sont chargés chacun de coordonner les échanges d’une application distribuée (« DA » – Distributed Application), c’est à dire d’une application dont l’exécution met en jeu plus d’un nœud du réseau de communication. 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 communications sur le bus, soit du partage du canal.

158 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

Des exemples d’applications distribuée sont celles de « contrôle de frein », « traction en unité multiple », « intégrité du train » et « diagnostic du train » [Grasso et al. 2001]. La tâche maître d’une telle application gère les communications entre les différents nœuds en charge 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 identificateur d’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é des applications courantes d’un train avec celles futures, [Grasso et al. 2001] soulève la né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 des tâches de l’unité de contrôle maître (MCU). Elle configure et gère les services de communications synchrones et asynchrones pour chaque application distribuée du bus train. Cette gestion se fait en tenant compte des priorités des applications, de leur périodicité, de la bande passante disponible sur le canal et des échanges de données requises pour ces applications distribuées. L’ensemble de ces informations sont collectées lors de la phase d’initialisation des applications distribuées et sont alors utilisées pour construire chaque période de communication (de 400 ms dans l’exemple donné [Grasso et al. 2001]). Cette phase d’initialisation des applications distribuées prend place après celle de l’inauguration du train qui correspond à l’initialisation du réseau (recherche des nœ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 de communication, chacune dédiée à une application identifiée. La trame de synchronisation spé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ètre transmis avec l’ID de l’application distribuée sert au calcul par le maître de l’application ID du délai d’attente préalable à sa tentative de préemption du bus. Le protocole FEBIS garantit, à 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 lorsque le maître des tâches applicatives mentionnées est localisé dans le même nœud que celui responsable 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, le maître d’une application distribuée ID localisé dans un autre nœud que le MCU transmettra, seulement après préemption du bus, sa liste de commandes à l’adresse des esclaves participant à l’application ID (figure 46). D’après [Grasso et al. 2001], le service asynchrone permet aux applications d’échanger des paquets de données sur le bus train « d’une façon quasi aléatoire », c’est

Synthèse INRETS n° 45 159 Les réseaux de terrain embarqués dans les transports guidés

à dire qui font suite à une demande de ce service par un événement temps réel asynchrone. Ce service n’est pas conçu pour les échanges lors des modes d’initialisation et de maintenance du réseau, mais pour ceux ayant lieu lors du mode de fonctionnement courant (en cours d’exploitation). [Grasso et al. 2001] ne précise pas comment le gestionnaire du réseau CM prend en compte les requêtes des applications distribuées pour ce service et affecte les fenêtres de communication entre les applications distribuées demandeuses. Le service « alarme » permet aux applications distribuées de transmettre des paquets de données hors contrôle du gestionnaire de communications. Ce service utilise les fonctionnalités de compétitions et de priorités du protocole LONWORKS. Il est utilisé pour des 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. Conclusion Dans 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ées dans les matériels roulants guidés. Ces méthodes montrent le choix de solutions algorithmiques très différentes. Toutes les solutions implémentées par la couche 2 des protocoles de ces réseaux, à l’exception de celle du protocole LonTalk, sont implantées en matériel et possèdent un adressage de niveau MAC. Ces solutions sont des protocoles d’accès au médium par passage de jeton, par scrutation, par contention, voire une combinaison de ces protocoles.

160 Synthèse INRETS n° 45 Méthodes d’accès au médium de communication et trames de données

Pour les applications ferroviaires temps critique, les constructeurs cherchent à garantir le déterminisme de leurs applications. Pour cela, la définition de deux types de trafics, synchrone et sporadique, comme les spécifient les protocoles WorldFIP et TCN par exemple, semble intéressant afin de garantir aux variables temps critique des délais d’acheminement connus. Si les protocoles de communication par scrutation ou jeton permettent a priori d’ordonnancer plus facilement les tâches de communication par la dé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é cette décomposition en cycle. Ceci semble un peu plus compliqué avec le protocole LONWORKS [Schweins et Heffernan 1998]. Pour ces deux protocoles, l’ordonnancement des communications se fait par l’émission cyclique d’une trame de synchronisation, qui marque les débuts de transmission, et par une bonne gestion des priorités d’accès au médium.

Synthèse INRETS n° 45 161

Chapitre 5

Quelques mots sur la sûreté de fonctionnement dans le ferroviaire

1. Introduction Le secteur ferroviaire est soumis à de fortes contraintes en terme de sûreté de fonctionnement. Un incident non prévu intervenant sur un train pourrait être générateur d’é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é de fonctionnement, puis celles concernant la sûreté de fonctionnement des communications embarqué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 des systè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 (par exemple un système de signalisation, de contrôle de la vitesse...). Le cas des systèmes qui ne sont pas de sécurité (par exemple un système de climatisation, d’éclairage...) ne font pas l’objet de ces standards. Dans les années 80, chaque pays de la communauté européenne a défini ses propres exigences sur la sécurité des systèmes à partir des recommandations définies dans les codes de l’Union Internationale des Chemins de fer (UIC code 738R) [Hirao et Watanabe 1998]. La Commission Electrotechnique Internationale (IEC – International Electrotechnical Commision), de son côté, a développé un standard (IEC 61508) sur la sécurité pour les systèmes de traitements automatisés non dédiés. Ce standard introduit les cycles de vie de la sécurité et adopte des niveaux d’intégrité qui définissent les mesures à mettre en place pour l’obtention du niveau de sécurité exigé. Sur la base des documents 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 par la communauté européenne, remplacent celles des pays de l’union. Elles sont la référence de base pour le développement des systèmes de contrôle de train et de signalisation [ElKoursi et al. 1998].

Synthèse INRETS n° 45 163 Les réseaux de terrain embarqués dans les transports guidés

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 des prescriptions de sûreté de fonctionnement (fiabilité, disponibilité, maintenabilité et sécurité) pour l’industrie ferroviaire [NF_EN_50126 2000] et les conditions à respecter pour 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 les procédures et exigences techniques pour le développement des logiciels des systèmes électroniques programmables dédiés à toutes les applications de commande et de protection 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éresse aux communications en sécurité pour les systèmes de signalisation, de télécommunication et de traitement. La figure 1 montre les domaines couverts par l’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ées Les 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 de transmission est dit fermé lorsque les conditions suivantes sont réunies : seuls les accès autorisés sont permis, il y a un nombre maximal connu d’entités connectables, le médium de transmission est connu et restera inchangé toute la durée de vie du système. Le système de transmission est dit ouvert quand au moins une des trois conditions précédentes n’est pas remplie. Ces normes ne définissent pas, ni ne font de recommandations sur le choix d’un système de transmission particulier. Elles insistent sur le fait que tout système de transmission est à considérer comme non sûr. La connaissance des propriétés et du comportement du système de transmission est seulement utilisable pour la définition des performances du système. Les aspects de sécurité doivent être couverts par l’application

164 Synthèse INRETS n° 45 Quelques mots sur la sûreté de fonctionnement dans le ferroviaire 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éduire les 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 moyens suivants peut être utilisé : numéro de séquence, horodatage, temporisateur (time-out), retour de message, identificateur de la source et du destinataire, procédure d’identification, code de sécurité, techniques de cryptographie. Notons que, sur le marché, des couches sécurité sont à l’étude pour différents réseaux de communication. On peut citer SafetyBus bus de terrain fondé sur le protocole CAN et le protocole ProfiSafe utilisant PROFIBUS. 4. Maintenabilité d’un système La « 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é et la sécurité). Pour un système de traitement de données, [EuroDicAutom_4] donne les dé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ée conformé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 requises quand l’entretien est exécuté dans des conditions précises en utilisant des procédures et des moyens prescrits. » Les préoccupations concernant ces différents aspects de la maintenabilité sont très fortes aussi bien dans le secteur ferroviaire que pour les concepteurs de réseaux de communication. En ce qui concerne les réseaux, les constructeurs mettent en œuvre et offre dans le commerce des outils d’aide au développement d’applications et au diagnostique. Des liens vers des vendeurs de tels produits sont disponibles sur les pages web des constructeurs (soit [Echelon_URL ; Lonmark_URL] pour le réseau LONWORKS, [CAN_cia_URL] pour les protocoles CAN et les couches application disponibles sur le marché pour la technologie CAN, [WorldFIP_URL] pour le protocole WorldFIP, [PROFIBUS_URL] pour le protocole Profibus). Ces outils permettent généralement d’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.

16 Les partenaires du projet TrainCom sont le co-ordinateur SIEMENS Aktiengesellschaft (Allemagne), les partenaires DaimlerChrysler Rail Systems GmbH, ADTRANZ (Allemagne), et

Synthèse INRETS n° 45 165 Les réseaux de terrain embarqués dans les transports guidés

Ce projet, qui prend en compte les résultats du projet ROSIN, doit notamment permettre une 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 entre les 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 un poste 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’authentification 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]

5. Conclusion Bien 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 le domaine ferroviaire, importance traduite notamment par les différentes normes européennes dans ce domaine. Si chacun des protocoles cherche à mettre en œuvre dans leurs spécifications un certain nombre de mesures pour l’obtention d’une certaine disponibilité et fiabilité, ceci ne suffit pas pour une application sécuritaire donnée. Quel que soit le réseau choisi, la sécurité d’une telle application ne pourra être garantie qu’avec

son partenaire associé italien DaimlerChrysler Rail Systems S.p.A., ADTRANZ, ANSALDO Trasporti S.p.A. (Italie), et son partenaire assistant ATOS S.p.A., les partenaires Construcciones y Auxiliar De Ferrocarriles S.A. (Espagne), FAR SYSTEMS SpA (Italie), FIREMA Trasporti S.p.A (Italie), SC Silogic srl,SILOGIC (Roumanie) ; Deutsche Bahn Reise&Touristik AG (Allemagne) ; Ferrovie dello Stato Società di Trasporti e Servizi S.p.A. (Italie) ; Österreichische Bundesbahnen,OEBB (Autriche) ; Red Nacional de Ferrocarriles Españoles (Espagne) ; Alstom Transport SA (France)

166 Synthèse INRETS n° 45 Quelques mots sur la sûreté de fonctionnement dans le ferroviaire

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

l’implantation de procédures particulières au-dessus du protocole de transmission. A l’occasion des extensions des applications de communication aux communications train- infrastructure, on comprend également qu’une couche sécurité devra également superviser les échanges du nouveau système. Un réseau TCP/IP sécuritaire semble être en développement à l’occasion du projet européen [TrainCom_URL].

Synthèse INRETS n° 45 167

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 avons présenté ci-dessus un état de l’art des réseaux de communication embarqués au sein de matériels ferroviaires guidés. Des discussions préliminaires avec la SNCF ont permis de recenser les réseaux de communication d’intérêt. A partir de ces informations, une recherche bibliographique a pu être menée. Elle a montré très peu voire pas d’informations sur les réseaux propriétaires spécifiquement conçus pour le ferroviaire (liaison MUX G, TORNAD, TORNAD*) et sur l’adaptation de réseaux du commerce aux besoins du ferroviaire (BITBUS, WorldFIP, CAN, LONWORKS). La décision d’étudier l’utilisation de PROFIBUS pour les applications embarquées sur matériels roulants est trop récente pour faire l’objet d’écrit public. Par contre, le protocole TCN fait l’objet de nombreuses publications 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 de réaliser une description progressive et transversale de chacun des réseaux, en privilégiant celle des couches basses du modèle de référence hiérarchique OSI (Open System Interconnection) de l’ISO (International Standardization Organisation). La description des réseaux spécifiques au domaine ferroviaire nous a alors permis également d’introduire progressivement cette problématique. Ainsi, dans le chapitre 1, nous avons introduit la problématique des réseaux de communication embarqués à bord des véhicules roulants guidés. Les applications candidates au 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éhicules d’un train. Un des besoins exprimé est l’interconnexion possible de trains de pays d’origines différents. Ce chapitre a également montré un ensemble de réseaux d’origines trè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, le réseau PROFIBUS, qui a été choisi et est aujourd’hui à l’étude pour les applications de contrô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é dans le 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 sont généralement très développées a ensuite fait l’objet du paragraphe suivant. Enfin, après un rappel des différentes méthodes d’interconnexion de réseaux, une comparaison des repré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

Synthèse INRETS n° 45 169 Les réseaux de terrain embarqués dans les transports guidés

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éveloppement de passerelles pour permettre l’interconnexion de ces solutions et donc de véhicules ferroviaires de pays d’origine différents. Les chapitres 3 et 4 ont été l’occasion d’une étude des différentes couches physiques de 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éhicule pour l’interconnexion d’équipements à bord de chaque véhicule et celle d’un bus train pour 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 des dé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 chapitre 4. Les techniques utilisées par les réseaux considérés sont des techniques round robin ou des techniques de contention CSMA (CAN, LONWORKS). Parmi les techniques round 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 de scrutation sont souvent combinées. Outre les méthodes d’accès au médium de transmission, les accès aux réseaux TCN et LONWORKS définis sur les sept couches du modèle de référence OSI ont été considérés. Pour des applications temps critique ferroviaire, des réseaux de types scrutation qui définissent un trafic périodique pour les variables temps critique et un trafic apériodique pour les autres variables ou des messages semblent être privilégiés. Cette méthode est parfois associée à la technique du passage de jeton qui permet 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, les exemples du protocole CANopen et de [Schweins et Heffernan 1998] ont montré l’existence (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 utilisateur ([Schweins et Heffernan 1998]). La solution expérimentée pour le protocole LONWORKS nécessite une adaptation matérielle. Le protocole CANopen est un exemple d’une couche application pour le protocole CAN disponible dans le commerce. Les systèmes ferroviaires étant soumis à de fortes perturbations électromagnétiques et mé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 ferroviaires y ont été rappelées. Quelles que soient les mesures particulières prises dans les protocoles 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é soit construite au-dessus du système de communication pour les applications de sécurité. La

170 Synthèse INRETS n° 45 Conclusion sûreté de fonctionnement des systèmes ferroviaires intégrant des communications ne va cesser de prendre de l’importance avec l’extension des communications embarquées et des é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, TORNAD et TORNAD* ne sont plus embarqués dans les nouveaux matériels ferroviaires, il est aujourd’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éveloppement des passerelles adéquates qu’à celui des composants des réseaux qui, à l’exception du réseau TCN, sont des réseaux largement utilisés dans des applications d’automatisation.

Synthèse INRETS n° 45 171

Références bibliographiques

Abou, Malville (1997). – « Le Bus VAN – Vehicle Area Network – Fondements du protocole », 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ème MITRAC, 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 Industries Alliance), 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 transports terrestres », Marion Berbineau, Yves David et Marc Heddebaut, Rapport final de 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 concernant l’Utilisation de systèmes de Télécommunication Existants ou Emergeants dans le domaine des transports guidés », Marion Berbineau, Rapport de contrat PREDIT. Berbineau (2001b). – « Synthèse INRETS n˚ 40 – Les systèmes de télécommunication existants ou émergeants et leur utilisation dans le domaine des transports guidé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 Bosch GmbH, 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 des locomotives à la SNCF », Jean-Claude Boutonnet, Michel Chateaureynaud, Chemin de Fer, n˚ 397, juillet/septembre 1989. Boutonnet, Chateaureynaud (1989b). – « Multiplexing und Fernsteuerung von Lokomotiven bei des SNCF », Jean-Claude Boutonnet et Michel Chateaureynaud, Hestra-Verlag – Darmstadt, ETR 38 (1989), H.5, p. 265-269, mai 1989.

Synthèse INRETS n° 45 173 Les réseaux de terrain embarqués dans les transports guidés

Brisou (2002). – « Quelques notions sur le frein pneumatique AAR », Florent Brisou, http ://perso.wanadoo.fr/florent.brisou/Freinage%20AAR.htm, disponible le 30.10.2002. Brun et al. (1994). – « Les rames EUROSTAR », Daniel Brun, Marc Provoost et Claude Pujol, 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, sur le site www.can-cia.de/ de CAN in Automation, page mise à jour le 29 septembre 2000. CANimpl (2000). – « CAN Implementations », fichier « CANimpl.pdf », 33 pages, sur le site www.can-cia.de/ de CAN in Automation, page mise à jour le 29 septembre 2000. CANopen (2000). – « CiA CANopen », fichier « CANopen.pdf », 125 pages, sur le site www.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, Bernard Macor, 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 LonWorks Control Networks », Alex Chervet, www.lonmark.org/solutiontrans/ train5.pdf, 10 pages. Ciame (1999). – « Réseaux de terrain – description et critères de choix », Groupe de travail 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 », Documentaion disponible 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 Conformance and Interoperability Concepts. A Proposal of a Test Bed », G. Corradi ; G. Fadin ; G. Cau ; A. De Curtis, Proceedings 16th conference on Transport Systems Automation in Transportation’96, p. 92-95, Split, Croatia, 27-29 novembre 1996. Dang, Wahl (1994). – « Rapport d’expertise sur les notions d’identificateur et d’arbitrage bit à 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-speed Guided Transport, Dictionnaire Technique des Transports Guidés à Grande Vitesse, DEUFRAKO, Dornier GmbH & INRETS-Arcueil. DeLinares, VanCaeyseele (1989). – « Equipements de communication – Micropanorama n˚ 53 », Bénédicte de Linares et Alain Van Caeyseele, Minis & Micros n˚ 320, 17 avril 1989.

174 Synthèse INRETS n° 45 Références bibliographiques

Desgeorge (2000). – « Le journal des réseaux », Guillaume Desgeorge www.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 des Chemins de Fer, n˚ 12, pages 657 à 662, décembre 1985. Duhot (1989). – « Le réseau informatique ferroviaire TORNAD », Denis Duhot, Revue RTS (Recherche Transport Sécurité), n˚ 22, Dunod, juin 1989. Duquesnoy, Kieken (1986). – « Microprocesseurs et automatismes sur les rames du TGV Atlantique », J.-N. Duquesnoy et J.-P. Kieken, Revue Générale des Chemins de Fer – 105e année, vol. 105, n˚ 12, p. 719-730. EB161 (1993). – « LONTALKTM Protocol », LONWORKS÷ Engineering Bulletin, Echelon Part 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 with LONWORKS Technology », www.echelon.com/Solutions/Markets/trans/ rail.htm, Echelon Corporation, 26 pages. ElKoursi et al. (1998). – « Certification des automatismes numériques dans les transports guidés : projets européens CASCADE et ACRuDA », El Miloudi El Koursi, Philippe Meganck, Bao Le Trung, Swapan Mitra, Henrich Krebs, Recherche Transports 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 » ; Terminology and Computer Applications, European Commission ; Réf. : NF Z 70- 001(1, 2, DF) et Dict. du multimédia, AFNOR, 1994 (1, 2, NT) ; Recherche sur 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 sur EuroDicAutom : europa.eu.int/eurodicautom/login.jsp.

Synthèse INRETS n° 45 175 Les réseaux de terrain embarqués dans les transports guidés

EuroDicAutom_4 – « maintenabilité » ; Terminology and Computer Applications, European Commission ; Réf. : Z 61-000, décembre 1980, Vocabulaire international 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 : the ROSIN 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 du groupe 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 – ABEUG Recommandation », Frank J. Furrer, 8 pages, July 21. GESPAC_URL. – « FILBUS, BITBUS, WorldFIP, Profibus and CAN Fieldbus comparison 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 Railway Research (WCRR), Cologne, novembre 2001. Heffernan (1997). – « A Technical Overview of Fieldbus Developments from Origins to Present Day Standards », Donal Heffernan, Keynote Adress ETCI Conference, Dublin, Ireland, 8 octobre 1997. Hirao, Watanabe (1998). – « Safety Guidelines for Computerised Train Control and Protection 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 Aboard Trains », 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 Computer Communications 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-speed controller area network (CAN) », 52 pages, 1994 ; « Part 3 : Vehicle area network (VAN) », 104 pages, 1994 ; « Part 4 : Class B data communication network interface (J1850) ».

176 Synthèse INRETS n° 45 Références bibliographiques

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 », Hubert Kirrmann (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 Dominique Seret, 361 pages, ISBN 2-86601-698-X, Ed. Hermes (Collection pédagogique de 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 : Edition Terrain, n˚ 3, p. 15-17, mars-avril. Lozac’h et al. (1998). – « Etude d’une commande électronique de frein et d’un système de communication embarqué pour le Fret – Cahier des charges fonctionnel », Jean-Philippe Lozac’h, Alain Bonnet, Dietmar Gralla, Marc Guigon, Carsten Dorn, 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 », Yves Machefer 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) », Lewis M. 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 », Yvon Madec, Techniques de l’Ingénieur, Traité Electronique, 19 pages, référence E7430. McGean (1999). – « Communications Protocol Interface Proposal » preparée par Tom McGean, www.tsd.org/rsc/CPIProposal.doc (TSD – Transportation System Design Inc.), 5 pages. Menoux (1993). – « Les voitures à deux niveaux V2N », Jean Menoux, Revue Générale des Chemins de Fer – 112e année, n˚ 1, p. 13-20, janvier.

Synthèse INRETS n° 45 177 Les réseaux de terrain embarqués dans les transports guidés

Misic (1999). – « COMP 361 Computer Communication Networks – Spring 1999 », Jelena MISIC (Professeur Assistant de l’Université de Belgrade), cours disponible 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 de la 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 de EN 50126 : 1999, norme CENELEC, 80 pages, janvier 2000. NF_EN_50128 (2001). – « Applications ferroviaires – Systèmes de signalisation, de télécommunication et de traitement – Logiciels pour systèmes de commande et 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, de télécommunication et de traitement – Partie 1 : Communication de sécurité sur des systèmes de transmission fermés », indice de classement F74-159-1, version française de EN_50159-1 : 2001, norme CENELEC, 16 pages, août 2001. NF_EN_50159-2 (2001). – « Applications ferroviaires – Systèmes de signalisation, de télécommunication et de traitement – Partie 2 : Communication de sécurité sur des 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 », Katia Obraczka, 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, Manuel Technique », PROFIBUS Brochure, n˚ 4.003-FR, 40 pages, octobre. PROFIBUS_URL. – http ://www.profibus. com/.

178 Synthèse INRETS n° 45 Références bibliographiques

Rolin (1990). – « Réseaux locaux – normes et protocoles », Pierre Rolin, 3e édition revue et augmentée, 581 pages, ISBN 2-86601-234-8, Ed. Hermes (Traité des Nouvelles 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 data communications – 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 – SAE J1850 », 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 des locomotives 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 », Heinz Scheinder et Dr Janis Vitins, ABB Daimler Benz Transportation (Switzerland) ltd (Zurich), 12 pages. Schickhuber, Mc Carthy (1997a). – « Distributed Fieldbus and Control Networks Systems », Gerald Schickhuber et Olivier Mc Carthy, IEE Computing and Control Engineering Journal, février. Schickhuber, Mc Carthy (1997b). – « Distributed Fieldbus and Control Networks Systems », Gerald Schickhuber et Olivier Mc Carthy, LonUsers International Proceedings, Santa Clara, USA, mai. Schweins, Heffernan (1998). – « Retrofitting a Deterministic Access Control Policy to a Non-deterministic Control Network », Hubertus Schweins et Donal Heffernan, Irish Signal and Systems Conference, Dublin, juin. Selectron (1999). – « The control system for mobile automation – SELECONTROL MAS 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.

Synthèse INRETS n° 45 179 Les réseaux de terrain embarqués dans les transports guidés

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, ’ 1999 LonMark Interoperability Association ; Railway Age : p. 63-74, Aug.. Summers (2000). – « Communications and Systems Software – Lecture notes », Wayne Summers, www.cs.waikato.ac.nz/~312/lectures/. Tanenbaum (1997). – « Réseaux », Andrew Tanenbaum, Texte français de Jean-Alain Hernandez 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 site www.labs.it/rosin/tcnstand/, version de septembre 1998. Thomesse (1998). – « A review of the fieldbuses », Jean Pierre Thomesse, Annual Reviews in Control 22 (1998), p. 35-45. Thomesse (1999). – « Histoire, état de l’art et perspectives des réseaux de terrain », Jean Pierre Thomesse, Colloque Européen sur les Réseaux de Capteurs et communications 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éen n˚ IST-1999-20096, date de début : 1/12/2000, www.traincom.org/. TSD_URL. – « TSD’s Rail Standards Page, Transportation Systems Design, Emerging Standards », Inc., http ://www.tsd.org/standards/index.htm. UIC556. – « Projet de fiche UIC 556, Transmission d’information dans le train – bus de train », 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 du 31 octobre présentée à Tokyo.

180 Synthèse INRETS n° 45 Références bibliographiques

VAN_URL. – « Vehicle Area Network », www.van-mux.org. Wahl (1999). – « Réseaux de terrain embarqués et problématique ferroviaire », Martine Wahl, 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 de l’Electronique et de la Physique 1999 (SEP 1999), Parc des Expositions, Paris, 6 octobre. Witte (1998). – « CAN in Güterzügen ; Feldbus-Technik – grundstock der Automatisiereung in der Bahntechnik », Stefan Witte, Elektronik, vol. 47, n˚ 20, p. 86-93. Witte et al. (2001). – « FEBIS system aspects », Stefan Witte, Alain Launay, Roberto Tione, Christian Coulange, World Congress on Railway Research (WCRR), Cologne, novembre 2001. WorldFIP_News (1995). – « WorldFIP News », Issue 7 : sept. 1995, disponible sur www.worldfip.org/, septembre. WorldFIP_News (1999). – « WorldFIP News », Issue 23 : sept. 1999, disponible sur www.worldfip.org/, septembre. WorldFIP_URL. – www.worldfip.org/. XP_ENV_50129 (1999). – « Applications ferroviaires – Systèmes électroniques de sécurité pour la signalisation », indice de classement F74-129, XP ENV 50129 1999,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.

Synthèse INRETS n° 45 181 Imprimé en France - Jouve, 11, bd Sébastopol 75001 PARIS N° 332735T - Dépôt légal : Février 2004